How to Structure System Prompts for Claude in Enterprise Deployments

System prompts tend to grow. They start with a few sentences and, after months of fixes, turn into thousands of words that nobody fully understands. People stop removing old rules because they don't know which ones still matter.

A consistent structure keeps the prompt manageable.

Step 1: Use labeled sections

Claude works well with XML-style tags, and tags make prompts easier to read and compare between versions:

<role>
You help Acme's field engineers troubleshoot industrial pumps.
</role>

<context>
Users are technicians on site, often on a phone, with little time.
</context>

<rules>
- Recommend only procedures from the maintenance manual.
- Before any high-voltage step, remind the user to follow lockout procedures.
</rules>

<output_format>
Short numbered steps. End with the manual section you used.
</output_format>

Step 2: Explain the reason for each rule

"Never guess part numbers, because a wrong part delays a repair by days" works better than "NEVER GUESS PART NUMBERS". When Claude knows why a rule exists, it applies it sensibly to situations the rule didn't mention. Capital letters don't add anything.

Step 3: Put stable content first

Instructions, policies and reference material go at the top. Request-specific details, such as the user's name, account data or today's date, go at the end or in the user message. Keeping the beginning identical between requests is what makes prompt caching work.

Step 4: Keep instructions and data apart

Wrap documents, tickets and emails in their own tags, like <ticket>...</ticket>, and state that the content inside is information to use, not instructions to follow. This doesn't make prompt injection impossible, but it reduces the risk.

Step 5: Include examples of difficult cases

Two or three short examples of tricky situations, such as a request outside the assistant's scope or a missing document, teach more than a long list of rules. You don't need examples of easy requests.

Step 6: Manage the prompt like code

• Keep it in version control with a change log.
• Give each section an owner.
• Run your evaluation suite before any change goes live.
• Remove rules that no longer make a difference, and use the evaluations to confirm it.

Common problems

• Contradictory instructions build up over time. "Be concise" in one section and "explain thoroughly" in another leads to inconsistent answers.
• Pasting an entire policy wiki makes the prompt slow and expensive. Retrieve the relevant sections for each request instead.
• Testing only with the examples written in the prompt hides problems. Test with real user messages.

When the customer's engineers take over the system, a prompt with clear sections, owners and tests is something they can maintain. A long block of unexplained text is not.