Let me be careful. This post is not about exploiting leaked material or jailbreaking systems. I'm not interested in either, and neither should you be if you're running a real company. What I'm interested in is what the structure of a deeply thought-through production system prompt teaches us about giving AI agents instructions that actually work in the real world — under pressure, at scale, with real users trying to break things.
Anthropic has actually published much of the relevant material themselves — see their official system prompt release notes — and Simon Willison has been the best public chronicler of how these prompts are structured and what they reveal. The leaked prompts are valuable not because they reveal secrets. They're valuable because they show, at serious production scale, how a team that actually knows what it's doing writes instructions for a powerful model. And almost nothing about how they write instructions looks like what most founders and operators do when they prompt an agent.
Lesson one: structure is the instruction
The first thing that hits you reading any serious production prompt is the amount of structural scaffolding. Sections with headers. Numbered rules. Explicit role definitions. XML-like tags for different categories of instruction. This is not stylistic. This is the instruction.
When you dump a wall of text at a model, the model has to infer what the different parts of your prompt mean and how they relate to each other. When you give the model explicit structure — "this section is about safety, this section is about tool use, this section is about when to refuse" — you've done half the work of prompt engineering by the time you've written the headers.
Most founders I know write prompts that look like email. A greeting, a paragraph, a request, a sign-off. That works for a smart intern who knows your company. It does not work for a model operating under adversarial conditions at scale.
Lesson two: rules beat examples. Examples beat abstractions.
A serious production prompt uses a very specific layering. Hard rules at the top ("never do X"). Concrete examples in the middle. Abstract principles at the bottom as a fallback. The leaked Claude Code prompts follow this pattern almost perfectly.
What most operator-written prompts do is the opposite. They lead with vague abstractions — "be helpful and accurate" — and never provide a hard rule or a concrete example. The model does its best, but it has no anchor. So its behavior drifts in ways you can't predict, can't reproduce, and can't debug.
My takeaway after reading carefully. Every instruction I give an agent should include at least one concrete example of what the right output looks like. If I can't write that example, I don't understand what I want well enough to ask for it — and the agent definitely won't.
If you can't show the agent a good example of what you want, the agent can't build one for you. The example is the spec.
Lesson three: refusal behavior is a design problem, not a safety problem
A huge portion of the prompt is about when and how the model should decline to do something. Not just "illegal stuff." A whole taxonomy of when to refuse, when to push back, when to ask clarifying questions, when to go ahead. That taxonomy is engineered, not assumed.
If you're building an agent product for your company, the "refuse" behavior is not an afterthought. It's the single highest-leverage part of your prompt. Because every time the agent says "I'll do my best" when it should have said "I need more information" — or says "I can't help with that" when it should have tried — you're burning trust with the user and training them to work around your agent. Do what you say, say what you do applies to agents too. If the agent can't draw a clear line around what it will and won't do, it will say yes to things it shouldn't and no to things it should.
Design your refusal taxonomy before you design your happy path. It's the adult move.
Lesson four: tool-use instructions deserve more words than task instructions
In the prompt, the instructions about how and when to use tools are significantly longer than the instructions about what tasks to perform. That's not an accident. Tool use is where agents fail in the real world. Calling the wrong tool. Calling the right tool with the wrong arguments. Calling tools in the wrong order. Calling a tool when they should have asked a clarifying question first.
If your company's agent has access to any tools — a database, an API, a file system, a search index — you should be spending at least 60% of your prompt engineering time on the tool-use instructions. Not the personality. Not the tone. The mechanics of when to reach for each tool and how to verify it did what it said it would do.
Lesson five: the prompt is a policy, not a conversation
The single most important shift in thinking that reading a real production prompt gave me. The system prompt is not a message. It is a policy. It is the written constitution the agent operates under. It should be written like a legal document — precise, unambiguous, with explicit priority between conflicting rules, with specific language about edge cases.
Most founder-written prompts are conversational. They read like a Slack message to a new hire. The resulting agent behaves like a new hire who got a five-minute onboarding. Enthusiastic. Mostly helpful. Occasionally disastrous. Inconsistent across days.
Rewrite your agent's system prompt as if a lawyer is going to read it. Not because you want your agent to sound like a lawyer, but because the precision required to write it that way is precisely the thing your agent needs to behave consistently when a thousand users are hammering it simultaneously.
What I did after reading it
Three practical changes I made to how I write prompts for my own tooling:
- I now start every new agent prompt with a structural outline — role, hard rules, tool-use instructions, examples, refusal taxonomy, edge cases — before I write a single sentence of content.
- I force myself to write at least three concrete examples for every major instruction. If I can't, the instruction isn't well-defined yet. That's a signal to me, not a defeat.
- I treat the prompt as versioned policy. Every change gets a commit message. Every change gets tested against the same set of scenarios. No cowboy edits at 1am.
You don't need to read any leaked prompt to adopt these habits. But if you ever do get your hands on a serious production prompt — read it once, carefully, with an open mind. It will teach you more about how to instruct an AI agent than any blog post on prompt engineering, including this one.
Here's the challenge. Pull up whatever system prompt is powering your most important agent right now. Read it like you're a lawyer auditing a contract. Every sentence, ask: is this rule concrete, is there an example, does the priority order survive a contradiction? If your answer is no to any of the three, rewrite it this week. The gap between an agent that works and one that embarrasses you on a Tuesday afternoon is almost always in the prompt, not the model.
For how I actually wire all of this into day-to-day operations, see AI inside the operator's cockpit.