We wrote a rule into an AI agent's instructions. The rule was specific, unambiguous, and sat in the section of the prompt that governed exactly the situation it described: when the request is ambiguous in this particular way, ask one clarifying question before proceeding.
Four separate arms, across three different model families, hit precisely that ambiguity.
None of them asked.
Nothing errored. Nothing logged. From the outside it looked like four frontier models ignoring a plain instruction. What had actually happened was more interesting, and it changed how we build agents.
TL;DR: A mandated clarifying-question rule fired on 0 of 4 arms. Removing the broader instruction it was losing to restored the behavior on 4 of 4. Changing one tool's error message cut agent steps from 28 to 17 and credits from 870 to 540. Structure beats instruction because an artifact changes the starting state, while a rule must win an argument on every generation. Build on structure →
Why Do AI Agent Prompt Rules Fail?
A prompt rule fails because it has to win an argument nobody told it it was in. Three separate instruction sites bore on that one ambiguous situation: a broad global rule favoring action over questions, a narrower rule for that specific kind of task, and the tool's own description. They disagreed. The model resolved the conflict silently, and the most general instruction won.
This is the failure mode we now call instruction-site conflict, and it is invisible by construction. There is no error, no log line, and no signal that a rule was even considered. You observe an absence.
Then we did the obvious experiment. We kept our clarifying-question rule exactly as written and removed the broader, competing instruction rather than strengthening ours.
The clarifying question returned on 4 of 4 arms, verbatim.
Our rule had never been the problem. The conflict was. And the fix was subtraction.
What Is the Difference Between a Prompt Rule and an Artifact?
A prompt rule asks the model to behave differently. An artifact makes the desired behavior the path of least resistance. Artifacts come in two kinds, and the difference matters: some are enforced by the system, and some are still read and interpreted by the model.
| Prompt rule | Enforced artifact | Model-read artifact | |
|---|---|---|---|
| Examples | "Always ask before X", "Never assume Y" | A schema, a permission, a fixed order of operations | A seeded example file, a tool response that explains the real shape |
| Mechanism | Persuasion at inference time | The system rejects the wrong thing | Changes what the model sees when it acts |
| Must defeat competing instructions | Yes, on every call | No | Less often: it is evidence, not another rule to rank |
| Cost | Input tokens on every generation, at full price on a cache miss | A schema usually travels with each request; a permission check costs no tokens | Tokens only on the calls that read it |
| Reliability | A probability | Deterministic | Still a probability, but a better-placed one |
| Failure is visible | No — you observe an absence | Yes — the wrong call is rejected | Usually yes |
The asymmetry compounds. A rule must win every argument on every generation forever, and you pay input tokens for the privilege each time. An enforced artifact does not argue at all. A model-read artifact still costs tokens and still has to be interpreted, but it shows up at the moment it is relevant instead of sitting in every call.
What Happens When You Change a Tool Message Instead?
Agent steps drop by 39 percent. We tested this directly, and it is the cleanest result we have.
The agent kept guessing wrong file paths and retrying. The instinctive fix is a prompt rule: check the directory listing before you guess. We did not do that. We changed only what the tool returned on a wrong-path error, so that instead of reporting a generic failure it explained the actual shape of what was there.
Nothing else changed. The prompt was not touched.
| Measure | Before | After | Change |
|---|---|---|---|
| Tool errors | 7 | 3 | −57% |
| Total steps | 28 | 17 | −39% |
| Credits consumed | 870 | 540 | −38% |
The agent learns from the environment's response, not from being told in advance.
This is worth sitting with, because it inverts the usual instinct. The agent did not need to be told the rule. It needed the world to answer honestly when it got something wrong. That is a much cheaper thing to build and a much more reliable thing to rely on.
Does Adding More Context to the Prompt Help?
Not measurably, in the largest test we ran — and there is now independent research explaining why not.
We gave the agent a structural map of the app it was working on — exactly the kind of "give the model more grounding" intervention that sounds obviously correct.
Every difference landed inside the noise floor. We did not promote it.
This sits alongside a finding from Chroma's context rot study, which ran 18 models across 194,480 LLM calls and reported something genuinely counter-intuitive: a coherent, well-structured document is harder for a model to search than the same content shuffled into random order — consistently, across every model tested.
Read those together and the naive model of context breaks. More context is not more grounding. Better-organized context is not automatically easier to use. Both are interventions that need measuring rather than assuming, and the field mostly assumes.
Anthropic frames the same constraint as an attention budget: every token you add competes with every other token for a finite resource. A rule you add is not free even when it is correct. It is spending attention that something else was using.
That result only means something because we had measured the floor first. Running the same prompt, on the same model, through the same evaluation twice produces a gap of 10.5% to 50.0% per task type, with a mean of 29.6%. Aggregate totals are far tighter at 5.2%.
So "did not promote" is not a polite way of saying it failed. It is a precise statement: the effect, if any, was smaller than the measurement could resolve. We wrote up that noise floor and the three other things that did not work in A Year of Agent Memory Experiments.
Has Anyone Else Found the Same Thing?
Yes, and independently, in a completely different domain.
In September 2026 a team from Google, Google DeepMind, the University of Maryland and the University of Virginia published Dream-RSI, a framework for long-horizon automated discovery. One of their analyses tested precisely this question. From the paper:
"A natural alternative for utilizing history is to abstract prior trajectories into high-level directional insights, which are directly injected into the prompt as explicit semantic guidance for subsequent rounds. […] explicit directional guidance consistently underperforms its unguided counterpart across both paradigms under equivalent discovery budgets."
Their proposed mechanism is that strong semantic bias about where to look next over-constrains the search space and suppresses diverse exploration. Their domains were algorithm engineering, mathematical optimization, and GPU kernel work — nothing like app generation.
Two honest caveats, because the corroboration is worth more if it is stated carefully:
- This is the same direction, not the same finding. Their failure mode is diversity collapse in a massively parallel search. Ours is instruction-site conflict in a single chat. Those are different mechanisms that happen to point the same way.
- Neither team knew about the other. That is the only kind of corroboration worth anything. Two groups working on unrelated problems hit the same wall from opposite sides.
We wrote a plain-English walkthrough of what else that paper does, because the main idea is genuinely useful: Replay Simulators Explained.
And From People Shipping Agents
The clearest practitioner account is from the Manus team, who rebuilt their agent framework four times and published what broke each time. Their conclusions are not controlled experiments — they say so themselves — but they point the same way, and the third one is the most counter-intuitive advice in this entire field:
| What they tried | What happened |
|---|---|
| Loading and unloading tools dynamically mid-task | Broke the cache and confused the model when earlier steps referenced a now-absent tool |
| Aggressively compressing context | Irreversible loss — they could not predict which dropped detail would matter later |
| Hiding tool errors from the model | Removed its ability to self-correct. They now keep failures in context on purpose |
| Heavy few-shot examples inside the agent loop | The model fell into a repetitive rhythm and overgeneralized |
Note what row three is really saying. The instinct is to clean up the agent's context so it sees a tidy history. Doing that removes the signal the agent was learning from. The mess is the teacher.
The Rule: Ask What Artifact Would Make the Rule Unnecessary
Here is the whole thing in one sentence, and it is the only part of this article you need to remember.
Before writing a rule into a prompt, ask what artifact would make the rule unnecessary. If an artifact exists, ship the artifact. A prompt rule is the fallback for constraints no artifact can express.
Applied as a decision path:
You want the agent to behave differently.
│
├─► Can a FILE that already exists make this the default?
│ └─► yes ──► seed the file. stop.
│
├─► Can a TOOL RESPONSE teach it at the moment of the mistake?
│ └─► yes ──► fix the tool message. stop.
│
├─► Can a SCHEMA or TYPE make the wrong thing unrepresentable?
│ └─► yes ──► ship the schema. stop.
│
├─► Can the ORDER of operations make it structurally impossible?
│ └─► yes ──► reorder. stop.
│
└─► none of the above ──► NOW write the prompt rule,
and expect to defend it
against every other rule, forever.
What Prompt Rules Are Still Genuinely For
This is not an argument that prompts do not matter. Some constraints have no artifact form, and for those the prompt is the correct and only place:
| Constraint | Artifact available? | Where it belongs |
|---|---|---|
| Tone, voice, persona | No | Prompt |
| Refusal and safety boundaries | Partially | Prompt, reinforced by tooling |
| Output format | Usually yes — a schema | Structured outputs |
| "Always check X first" | Usually yes — a tool response | Tool layer |
| "Never touch file Y" | Yes — permissions | Agent permissions |
| Domain knowledge | Yes — a knowledge source | Agent knowledge |
| Worked examples | Yes — a seeded file | The workspace itself |
Notice how much of a typical bloated system prompt lives in the right-hand rows. That is the opportunity.
How Do You Audit Your Own System Prompt?
Delete in slices and re-run your anchors after every slice. Judge by behavior, never by reading.
When we did this we removed a sizable block of accumulated instruction and found no capability loss on the anchor cases we re-ran. That qualifier is load-bearing and we are not going to drop it: we re-ran the anchors we had, not every possible input.
You will find three populations, and the middle one is the surprise:
- Inert instructions. Never fired. Cost you tokens on every call for nothing.
- Instructions that were actively losing. Deleting them improves behavior, because they were creating the conflict. This population is larger than anyone expects.
- Genuinely load-bearing instructions. Keep these. There are fewer than the file length suggests.
How This Changes What You Build
If structure beats instruction, the architecture follows from it. An agent's memory should be structure rather than a paragraph telling the agent to remember things.
That is why in Taskade the durable context lives in the workspace: projects hold what the team knows, and workspace memory holds why things are shaped the way they are. Both are ordinary projects with the same views, editing and sharing, so an agent is grounded on something a person can open and correct, and an automation watches the same object rather than a copy of it.
None of that is a prompt. It is all starting state — which is the entire point.
▲ ■ ● Memory, Intelligence, Execution. Structure first, instruction last.
Build an agent grounded on structure →
Deeper Reading
The measurement series
- A Year of Agent Memory Experiments — the noise floor, and three other things that did not work
- Replay Simulators Explained — how to evaluate a change without paying to rerun it
- Why AI Agents Forget and How to Fix It — persistent, structured agent memory, explained
- Which AI App Builder Remembers Why? — 10 builders checked for persistent decision rationale
Context and prompting
- Context Engineering: The Complete Field Guide — the five context layers and the anti-patterns that break them
- A History of Prompt Engineering — magic words to context to environment
- AI Agents vs Copilots vs Chatbots — where agents differ in kind
- Multi-Agent Systems in Production — what survives contact with users
- The Execution Layer — why generated interfaces outrun their foundations
Concepts
- System Prompt · Prompt Engineering · Context Engineering
- Context Window · Context Rot · Prompt Caching
- Agent Harness · Agent Loop · Tool Use
- Evals · Non-Determinism · Agent Evaluation
- Structured Outputs · Function Calling
Frequently Asked Questions
Why do prompt rules fail even when the model clearly reads them?
A prompt rule fails most often because it has to win an argument it was never told it was in. Large agent prompts accumulate instruction sites, and when two of them bear on the same situation the more general rule usually wins silently. In one of our rounds a specific workflow rule required the agent to ask a clarifying question in a defined ambiguity. Four arms across three model families hit exactly that ambiguity, and none asked, because a broader global rule favoring action over questions outranked it. Nothing errored, and nothing logged.
What is the difference between a prompt rule and an artifact?
A prompt rule is an instruction the model must read, prioritize against every other instruction, and act on correctly, on every single generation, forever. An artifact is a change to the environment the agent operates in, such as a file that already exists, a seeded example, a schema, or a tool response that explains what went wrong. A rule tries to change behavior by persuasion at inference time. An artifact changes the starting state, so the desired behavior becomes the path of least resistance.
Does deleting parts of a system prompt improve agent performance?
It can, and in our audit it did. We removed a sizable block of accumulated instruction and re-ran every anchor case, and found no capability loss on the cases we re-ran. A clarifying-question rule that fired zero times out of four started firing four times out of four once we removed the broader, competing instruction it had been losing to. Prompt length is not free, and instructions that never win are worse than absent because they read as coverage.
What is instruction-site conflict in an AI agent prompt?
Instruction-site conflict is what happens when the same situation is addressed by more than one place in an agent's instructions, and those places disagree. A global rule, a workflow rule and a tool description can all bear on one decision. The model resolves the conflict silently and usually in favor of the broadest, most frequently reinforced instruction. From the outside this looks like the model ignoring your rule, when what actually happened is that your rule lost.
Do tool error messages change agent behavior?
Substantially, in our measurements more than any prompt rule we tested. We changed only what a single tool returned when the agent guessed a wrong file path, so that the response explained the actual shape of the filesystem instead of reporting a generic failure. Tool errors fell from 7 to 3, total steps from 28 to 17, and credits consumed from 870 to 540. The prompt was not touched. The agent learned from the environment's response rather than from advance instruction.
Has any independent research found that injecting guidance into prompts hurts?
Yes. In September 2026 a team from Google, Google DeepMind, the University of Maryland and the University of Virginia published Dream-RSI, which tested abstracting prior run history into high-level directional insights and injecting them into the prompt as explicit semantic guidance. Their reported finding is that explicit directional guidance consistently underperformed its unguided counterpart across both of their paradigms under equivalent budgets, on algorithm engineering, mathematical optimization and GPU kernel tasks.
When should you still write a prompt rule?
Write a prompt rule when the constraint cannot be expressed as an artifact. Tone, persona, refusal boundaries, output format when no schema is available, and safety constraints are all genuine prompt work because there is no file, schema or tool response that encodes them. The test is simple: ask what artifact would make the rule unnecessary, and if you can name one, ship the artifact instead. If you cannot name one, the prompt is the right place.
How do you audit a bloated agent system prompt?
Collect the anchor cases your agent must handle, record current behavior on each, then remove instructions in reviewable slices and re-run every anchor after each removal. Judge by behavior on the anchors, not by reading the prompt and forming an opinion. Expect a portion of your instructions to be inert, a portion to be actively losing conflicts, and a small portion to be load-bearing. Keep the load-bearing ones and convert everything else into an artifact or delete it.
Why is a prompt rule more expensive than an artifact?
A prompt rule is paid for on every generation. It occupies input tokens on every call, and on a cache miss you pay full input price for it again. It must also win against every competing instruction on every call, forever, which means its reliability is a probability rather than a guarantee. Artifacts are not all free after creation: a schema usually travels with each request, a file costs tokens when the agent reads it, and a tool response costs tokens when it returns. The difference is what you pay for. An enforced artifact, such as a schema or a permission, is checked by the system rather than argued with. A file or tool response is paid for only on the calls that actually use it.
Does this mean prompt engineering is dead?
No, it means prompt engineering is the fallback rather than the first move. The field has been moving this way for several years, from magic words to structured context to environment design. The practical reordering is to ask what artifact changes the starting state first, reach for a tool response second, and write a prompt rule only for constraints that no artifact can express. That ordering is what the measurements support.
How large a measured improvement counts as real for an AI agent?
Larger than your noise floor. We measured run-to-run variance on identical inputs at 10.5 to 50.0 percent per task type with a mean of 29.6 percent, so we do not treat a per-arm magnitude change below roughly 50 percent as attributable at one sample. Categorical outcomes are different, because whether a run produced a working artifact at all is a fact about the artifact rather than a sampled magnitude.