Somewhere in your system prompt there is probably a line like this. When a user asks about AT&T, do not pull Verizon.
It got there because the agent did exactly that once, someone got frustrated, and the fastest fix was a rule. The tool that caused the original problem has probably since been rewritten or deleted. The rule is still there. It will still be there in six months, quietly making your agent worse.
We see this in nearly every stalled agent build we look at, and the teams that own them are usually surprised, because each individual rule looked reasonable on the day it was written.
Negative instructions do the opposite of what you intend
The mechanism is simple enough. A model is a statistical machine predicting the next expected token. Every concept you introduce into the context becomes a candidate, including the ones you introduced specifically to forbid. Write “do not pull Verizon” and you have now put Verizon in front of the model in a conversation about AT&T. Most of the time nothing happens. In the edge cases, which are the only cases that matter, the model reaches for exactly the thing you named.
There is a second-order version of this that is worse. A tool description that said do not store conclusions or judgments sounds like sound governance. Now a user says their phone has a piece of fruit on the back. The model reasonably concludes it is an Apple, then reads a rule telling it not to store conclusions, and now it is stuck between the goal you gave it and the guardrail you gave it, with no way to resolve the two. The fix is not a better-worded prohibition. The fix is two separate fields in the schema, one for facts and one for inferences, so that storing the wrong thing in the wrong place is structurally impossible rather than forbidden by instruction.
That distinction is the whole post. Constrain by structure, not by scolding. It is the same argument we make about why written policy fails as an agent control and the runtime has to enforce it instead.
The four patterns that rot a prompt
Prompts do not degrade randomly. They degrade in four recognizable ways, and once you know the shapes you can find them in an afternoon.
Negative assertions are the direct prohibitions above. Every one of them names a failure mode you would rather the model never consider.
Narrow cases are rules written for one specific input that break every other input. A rule that handles a Verizon typo does nothing for the seventy other carriers, and worse, it teaches the model that carrier handling is a special-case business rather than a general one.
Band-aids are patches applied where a root cause belongs. A tool misfires, so a rule is added telling the model not to misfire. The tool is still wrong. Now there is also a line of prompt permanently defending against a bug.
Mechanical steps are the subtlest. Hard-coding a sequence like always start by asking for the provider feels like it buys you consistency. Then a user opens with a question about unlocking their phone, and the model has a real conflict between the instruction and the conversation in front of it. What happens next is anyone’s guess. Guide the model toward a goal and let it invent its own mechanics. State the outcome you want, not the keystrokes.
Here is the pattern that produces all four. Agents almost always prefer adding to removing. Ask a coding assistant to fix a misbehaving prompt and it will append a rule, because appending is the safe move. Do that thirty times across a few weeks and you have fourteen thousand characters of accumulated caution, mixing conversational style, behavioral goals, and tool guidance in no particular order. That is not a prompt anymore. That is sediment.
Words carry more weight than teams expect
A widely circulated incident involved an agent destroying someone’s work despite explicit instructions to the contrary. The instruction had a typo. “Real only mode” instead of “read only mode.” One character shifted the semantic meaning of the constraint and the model behaved accordingly, without flagging anything, because from its position nothing was wrong.
Your prompt is not configuration. It is the primary interface to a system that interprets meaning rather than executing statements, and it deserves the same review discipline you would give production code. We have written up a related incident where an agent deleted two hundred emails despite operating inside what its owner believed were clear limits.
How to actually clean this up
Do not delete your prompt and start over. What is in there is data, a record of every failure your system has produced, and that is worth something.
Take the whole thing to the highest-tier model you have access to, along with a description of the end-to-end goal of your software, and ask it to identify negative assertions, narrow cases, band-aids, and mechanical constraints. Then ask it to restate each one as a goal. Instead of a rule saying not to pull the wrong carrier, you get an instruction to confirm the correct provider before searching.
The model tier matters here more than anywhere else in the build. Mid-tier models are not reliable at this task, because they tend to flip-flop and add the same category of band-aid you are trying to remove. Prompt auditing needs the strongest model available, and it is one of the few places where the expensive option is clearly correct.
Two rules for the rewrite. Give the agent context about what happened before a tool call rather than instructions about what to do if it fails. And keep specific data values out of the prompt entirely, because they leak into unrelated conversations and create confusion the model cannot explain to you. Reference data belongs in a structured knowledge base the agent can query, not pasted into instructions.
You will not notice most of this while running a frontier model, which is exactly why it survives. Drop a tier and the accumulated rules start actively fighting the smaller model’s limited capacity, and the whole mess becomes visible at once. That relationship between model tier and architectural clarity is the subject of its own piece on why we tell teams to build on the smallest model that works.
If your prompt is growing and your agent is not improving
That is the signal. When every fix makes the file longer and the behavior no worse but no better, the problem is no longer in the wording. The agent is being asked to hold too much, and no amount of prompt editing solves a composition problem.
When that happens, the fix is structural, and we have laid out what that restructuring looks like in your agent has a cognitive load problem.
If you want someone to look at yours, that is a large part of what our AI strategy and architecture work covers, and you can bring it straight to the founders.
