Your System Prompt Has a Shelf Life: Maintaining Prompts as Models Improve

Anthropic removed over 80% of Claude Code's system prompt for Claude Opus 5 and Claude Fable 5, and measured no loss on their coding evaluations.

Those instructions were not wrong when they were written. They were load-bearing. Somewhere between the model they were written for and the model running today, they stopped carrying weight and started adding noise.

That is the part worth generalizing. A system prompt is not a thing you write. It is a thing you maintain, and every line in it has a shelf life set by the model underneath it.

Most of us have never run the maintenance pass. The prompt from last November is still in production, still growing, because adding a line when something breaks is easy and nobody ever schedules the deletion.

What this article covers

1. The five reversals — what Anthropic's new rules of context engineering actually reverse, and which of the older advice they revise.
2. The scope nobody states. This is frontier-model guidance. On a Haiku-class model much of it inverts, and the source never says so.
3. The maintenance pass. A checklist you can run against your own prompt, with the prerequisite that makes it safe.
4. A worked audit on Cameron, a real finance agent with a real 100-line prompt.

If you have not read The Art of Agent Prompting, start there. It covers the principles that still hold: heuristics over rigid rules, thinking like your agent, designing for the loop. This article is about what happens to those prompts eighteen months later.

The clearest example: rules become judgment

Anthropic's own before and after says it better than a summary can. The old instruction:

In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks, one short line max.

The new one:

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

The first is a rule. It exists because a weaker model, left alone, wrote too many comments. The fix was a hard cap, and the hard cap worked.

The second is judgment. It assumes the model can look at a file, infer the local convention, and match it. That assumption was false in 2024 and is true enough now to ship. The rule was scaffolding around a capability gap, and the gap closed.

That is the shape of every reversal below. Not "we were wrong," but "the model got good enough that the workaround costs more than it returns."

The five reversals

Repetition stops paying

Repeating the critical constraint near the end of a long prompt was real advice, and it worked because attention over long contexts was genuinely lossy. It is now closer to a tax: the same instruction twice invites the model to wonder whether the second one means something the first did not.

Examples give way to interface design

The advice used to be: show the agent a worked example of calling the tool. The replacement is to make the tool's own signature carry the information. As Anthropic puts it, think about "what parameters does Claude have and how can they be more expressive?"

An enum of pending | in_progress | completed teaches the usage pattern without a single example. The parameter is the instruction, and unlike an example it cannot drift out of sync with the code.

Front-loading gives way to progressive disclosure

Everything the agent might need, loaded up front, was the safe default when models were bad at going to find things. Now the better structure is a small prompt that knows where to look. Anthropic ships tools whose full definitions the agent must search for before use. The same logic applies to your CLAUDE.md and your skills: a tree of files loaded at the right moment beats one document loaded always.

One home per instruction

This is the one with the clearest test. If a rule about how to use a tool lives in both the system prompt and the tool description, delete the system prompt copy. The tool description travels with the tool, appears only when the tool is in play, and cannot fall out of sync with the schema. The system prompt copy is a second source of truth that ages independently.

Rules give way to heuristics

The direction the playbook already pointed. It argued that showing agents exact processes "may limit their ability to leverage their full capabilities," and that heuristics beat rigid templates. The frontier finished that arc rather than reversing it. What changed is the dosage: how much scaffolding a capable model needs before heuristics are enough on their own.

Not every agent runs a frontier model

Here is what the source leaves implicit, and it matters more than any single reversal.

That 80% deletion was measured on Claude Opus 5 and Claude Fable 5. Haiku and Sonnet are not mentioned. Absent, not exempted.

Plenty of production agents run smaller models on purpose. Classification, routing, extraction, anything high-volume where latency and cost dominate and the task is narrow enough not to need a frontier model. On those, the instruction you are about to delete as an over-constraint may be the only thing keeping the task on rails. Terseness that reads as trust on Opus 5 reads as ambiguity to a model with less headroom to resolve it.

So the pass is not "delete instructions." It is:

Re-fit instruction density to the model you are actually running.

Which has a consequence people miss: a model downgrade triggers the audit exactly as much as an upgrade. Route a step from Opus to Haiku to cut costs and you have changed the amount of judgment you can assume. The prompt that got leaner for the frontier model may need some of that scaffolding back.

To be clear about sourcing: this is our reading, not Anthropic's published position. Their prompting best practices note that newer models may need behaviors requested more explicitly, but that is a point about generations, not tiers. We have found no Anthropic guidance stating that Haiku needs denser instruction than Opus. The mechanism above is the argument; treat it as reasoning to test against your own evals rather than a vendor claim.

The maintenance pass

Step 0: you need evals before you delete anything

The 80% figure is only meaningful because of the four words attached to it: no measurable loss on our coding evaluations. Strip those and the claim is "we deleted most of our prompt and it seemed fine," which is worth nothing.

Deleting on intuition is how prompts get bloated in the first place. Something breaks, you add a line, you never check whether it helped, and eighteen months later the prompt is 100 lines and nobody knows which ten are doing the work.

You do not need a large suite. The 3-Test Rule applies here as much as anywhere: the larger the effect size, the smaller the sample you need. Five realistic tasks, run consistently, will tell you whether a deletion moved anything.

There is a second reason to write them first, beyond measuring the deletions. Evals are also how you find out that the thing you were about to fix was not broken. Writing evals that prove you wrong is a field report on exactly that: a red run that killed a prompt slice written for a bug that did not exist, and a case that passed for entirely the wrong reason. Both are the same failure mode as deleting from a prompt on instinct, reached from the other direction. Its rule is the one to carry into this audit. Green is not the same as correct, and a passing case is evidence only if you know why it passed.

For the rest: the eval frameworks roundup covers the tooling landscape, and testing tools covers the deterministic layer underneath, which catches what is mechanically checkable before evals are worth running.

Baseline first. Then delete. Then re-run.

The checklist

Each item finds candidates. The eval decides.

1. Instructions stated twice. Search for any rule that appears in both the system prompt and a tool description. Keep the tool description.
2. Rules that are now judgment calls. Any hard cap or absolute prohibition written to stop a behavior the current model may no longer exhibit. Remove it and see if the eval moves.
3. Examples that could be parameters. Worked examples of tool calls, where a better schema, an enum, or a sharper parameter description would carry the same information.
4. Detail that is situational. Long procedures only relevant to one workflow. These belong in a skill or a reference file, loaded when that workflow starts.
5. Over-constrained heuristics. The classic is the unbounded pursuit: "keep searching until you find the best source" with no permission to stop. Give the agent an exit.
6. Density mismatched to the model tier. As above, in both directions.

A worked audit: Cameron's system prompt

Cameron is a personal finance agent, built in public across this series. Its system prompt is a single exported string, currently 100 lines, and it was written the way most production prompts are written: by adding a paragraph every time something went wrong.

It is a good subject precisely because it was written carefully. Every line in it was added for a reason that was valid at the time.

Finding 1: the same rule in two places

Cameron's CSV import rule about copying column headers exactly appears in the system prompt:

Use the exact header string from `inspect_csv` for every mapping value — copy it
verbatim, including accents, spaces, and capitalization (e.g. `Catégorie`, never
`Category`; `Revenu/dépense`, not a translation). A mapping value that isn't an
exact header is rejected and nothing imports.

And, already, in the inspect_csv tool description itself:

IMPORTANT: when you build the mapping, copy each header string EXACTLY as returned
here — including accents, spaces, and capitalization (e.g. 'Catégorie', not
'Category'). Do NOT translate or normalize header names; a value that isn't an
exact header is rejected by the import.

Same rule, same example, two sources of truth. The tool description is the one that survives: it appears exactly when the agent is holding the CSV, and it lives next to the schema that enforces it.

The same duplication covers the truncation rule (in the prompt and in query_transactions), the "use run_sql for totals, do not page through rows" rule (both places), and the approval requirement on import_transactions_csv (both places).

Candidate: roughly 25 lines of the "What you can do" section, which re-narrates tool behavior the tools already describe.

Finding 2: formatting rules the model no longer needs

Eight lines instruct Cameron to use Markdown, bold important figures, use headers, use tables for structured data, and make responses scannable. Then a ninth line repeats the instruction to use Markdown.

Frontier models format like this by default in a chat surface. This is scaffolding for a capability gap that has closed.

Candidate: the entire Response Formatting block, replaced by one line of intent if anything: lead with the figures, keep it scannable.

Finding 3: generic tool-use advice

- Only use tools when you genuinely need current, specific, or specialized information
- Do NOT use tools for information you already know with confidence
- Use tools efficiently — don't make unnecessary calls
- Follow the exact function signatures provided

None of this is Cameron-specific. It is a description of how tool-using models already behave. "Follow the exact function signatures" in particular instructs the model not to do something it structurally cannot do.

Candidate: all four lines.

What stays, and why

This is the half of the audit that matters more, because the failure mode of this whole exercise is deleting something load-bearing.

The hard rules stay, verbatim. No moving money without explicit human approval. Every capability through the same gate. Data stays on infrastructure the owner controls. These are not model-capability workarounds, they are product invariants and Cameron's stated identity. No model improvement makes them redundant. Length is not the enemy; unnecessary length is.

The approval-mechanics paragraph stays. It explains that the gate is enforced by the system, so calling the tool is the proposal, and asking in prose first double-prompts the user. That is non-obvious information about the harness which the model cannot infer from the tools. It is the opposite of the deletions above: it encodes something true about the environment, not something the model already knows.

The domain conventions stay. Amounts in positive minor units, direction in the type column, JOIN category for names. Facts about the data, not instructions about behavior.

The pattern: delete what the model can infer, keep what only you know.

Expected result

Roughly 45 of 100 lines are candidates for deletion, none of them among the invariants. That would be a 45% reduction, well short of Anthropic's 80%, which is what you would expect for a prompt where a real fraction of the content is genuine product policy rather than model scaffolding.

Whether those 45 lines can actually go is a question for the evals, not for me.

When to run the pass

Put it on the model upgrade path. Every time you change the model underneath an agent, in either direction, the assumptions your prompt encodes have shifted.

The order matters:

1. Run the existing evals on the new model, with the prompt unchanged. Baseline.
2. Run the audit and mark candidates.
3. Delete in batches, re-running evals between them, so you can attribute any regression.
4. Keep whatever the evals say to keep, whatever your instinct said.

The habit worth building is the one that runs counter to instinct: on a model upgrade, the first move is to look for what to remove.

One thing to watch for while you do it. If some behavior refuses to respond to prompt changes at all, you may be fighting the model's priors rather than its instructions, and no amount of editing fixes that. Running the same suite across two model versions makes the difference visible quickly; a single-model suite hides it, and you spend the afternoon rewording a prompt that was never the problem. The eval field report has a worked case: an older serving model volunteering two-year-old model names in its own voice, unprompted, which no prompt slice was going to correct.

Get the playbook as a skill

The prompting principles this article builds on are packaged as agent-prompt-engineering, an agent skill in agentailor/skills, with worked agent prompts and a reference list of anti-patterns:

npx skills add agentailor/skills --skill agent-prompt-engineering

Additional Resources

• The new rules of context engineering for Claude 5 generation models — Thariq Shihipar, Anthropic. The source for the reversals above.
• Effective context engineering for AI agents — the broader frame: curating the whole context window, not just the prompt.
• A harness for every task: dynamic workflows in Claude Code — where the context goes once it leaves the system prompt.
• The Art of Agent Prompting — the principles this article maintains rather than replaces.
• Writing Effective Tools for AI Agents — tool design, which now carries load the system prompt used to.
• How to Write AI Agent Evals That Prove You Wrong — the measurement layer this audit depends on, and what it looks like when the evals overrule you.