An Agent Follows a Fraction of What You Tell It

An autonomous agent reads its entire standing instruction layer on every run, and acts on only part of it. That layer is the block of natural-language direction a system carries into every invocation: the persistent instructions behind a served assistant, or the policy prompt that governs an autonomous workflow. Whatever the system, those instructions load on each request, they compete for the context window against everything else the run needs, and the agent follows some of them and quietly skips the rest.

The lines it skips are not evidence of a disobedient model. They are evidence of a design failure in how the instruction was written and what it was made to compete with. The distance between an instruction that gets read and one that gets followed is the real subject of instruction design, and closing that distance is a discipline rather than a matter of phrasing things more forcefully.

The discipline has three moving parts. An instruction has to be written so it can be acted on at all. It has to earn its place against a fixed budget it cannot grow, which means most candidate instructions should never be written down. And it has to be checked against what the agent actually does, because nothing about reading the file tells you whether the agent obeys it. Get those three right and the instruction layer does real work. Get them wrong and you accumulate a document that looks authoritative, reads well, and silently fails to steer the system.

The gap between read and followed

Every persistent instruction an agent carries is loaded into its context and, in that mechanical sense, read. Whether it changes behavior is a separate question with several possible answers. An instruction can be too vague to act on, so the model reads it, agrees with it, and has no concrete behavior to produce. It can be buried inside a paragraph of rationale, where under the pressure of a full context window it competes for attention with everything else and loses. It can restate something the model already does by default, in which case following it and ignoring it look identical. Or it can contradict another instruction the model weighs more heavily, and lose that contest without anyone being told.

None of these are the model refusing to comply. They are the predictable result of treating the instruction layer as a place to record intentions rather than a place to produce behavior. An intention like “handle errors gracefully” is read and approved and then does nothing, because there is no single action it names. The fix is never to repeat it louder. It is to write the instruction so that following it is unambiguous and skipping it is visible.

Three properties of an instruction that gets acted on

An instruction the agent reliably follows is specific, actionable, and unambiguous, and those three words carry more weight than they first appear to.

Specific is the property that closes off inference, and inference is where variance enters. Tell the model to keep the responses tidy and it will decide what tidy means, differently on different runs; state the exact shape every response has to take and there is nothing left to decide. A line that names the precise thing the system requires leaves no gap to fill. The moment a directive makes the agent reconstruct what you meant, its behavior drifts, because that reconstruction is not deterministic.

Actionable is the property that keeps a directive from smuggling in a decision. If following the line requires the agent to first settle something you left open, the line has quietly delegated that call, and the outcome will track however the model resolves it on a given run. A directive is actionable only once the judgment is already made and the result is what the line states.

Unambiguous is the property that survives a full context window. A sentence open to two readings will be read both ways across enough runs, and the two behaviors will look like inconsistency when they are in fact faithful obedience to an underspecified rule.

One test subsumes all three. If the agent’s output cannot tell you whether a line was followed, the line is not precise enough to keep, because you have written something you can neither confirm nor enforce. Make compliance observable, or drop it.

The instruction layer spends a budget you cannot refill

The standing instructions are loaded fresh into the context window at the start of every run, and they occupy the same space as the request, the retrieved context, the tool output, and the model’s own working reasoning. Every token spent on instruction is a token not available for the task. This turns instruction design into a budgeting problem, and budgeting problems are decided by what you leave out.

A bloated instruction layer is expensive twice over. It shrinks the working room available for the actual problem, and it dilutes the instructions that matter by surrounding them with instructions that do not. A model under context pressure is more likely to miss a genuinely important rule when that rule sits inside a hundred lines of also-ran directives than when it sits in a short, dense list. Volume works against reliability, not for it. The instinct to be thorough, to write down everything that might help, produces exactly the document least likely to steer the agent, because the signal is buried in its own completeness.

So the operative question is never whether an instruction is true or would be nice to have. It is whether the instruction is worth the space it costs. Most candidate instructions are not, and recognizing that is the core of the craft.

Encode only what the model cannot already know

One distinction decides what earns a place: either the model could reach this on its own, or it could not, and only the second kind is worth the space. A capable model arrives already knowing an enormous amount: how common languages and protocols behave, what standard patterns look like, how well-known formats are structured. Encoding any of that spends budget to tell the model something it will do anyway. It is the equivalent of a code comment that restates the line beneath it.

What the model cannot know is everything specific to your system and your decisions. Which of several defensible conventions this system actually uses. The policy your organization settled on after a real incident. The interface contract another service expects. The approach your team has already ruled out and does not want re-proposed. These are choices, not knowledge, and no amount of training data reveals which choice you made. A served support agent needs to be told your refund policy, not what a refund is. A data-extraction agent needs the schema your downstream consumers depend on, not what structured data is. A coding agent needs to be told which test command this particular repository uses, not how testing works in general.

The same filter has a subtractive form. Delete a candidate line and ask whether any output you care about would come out differently. If nothing would change, the line was decoration; if something would, it was carrying weight and stays. Applied honestly, that pass empties most instruction layers by half, and the half that remains is the half that was steering anything.

Do not restate what a deterministic layer already guarantees

Some behavior in a system is enforced by a deterministic control rather than by the agent’s cooperation. A validator that rejects malformed output, a formatter that normalizes structure, a pipeline stage that refuses to proceed on a failed check. When such a control already guarantees a property, encoding the same property as a natural-language instruction adds no safety. It adds a second source of truth that can drift out of step with the first, so that one day the instruction says one thing and the enforcement does another, and it spends context budget to create that liability.

The useful move is to split the work by what each layer can guarantee. Let the deterministic layer enforce everything it can enforce, because a guarantee that holds mechanically does not depend on the model choosing to honor it on a given run. Reserve the instruction layer for what only natural language can express: the judgment calls a validator cannot make, the domain conventions no formatter encodes, the anti-patterns that are not checkable but are still real. An instruction that duplicates a hard guarantee is worse than redundant. It implies the guarantee is soft, invites the two to diverge, and takes up room that a non-enforceable instruction could have used.

Directives outperform documentation

A model will read both a terse directive and a paragraph of prose that contains the same rule, but it follows the terse directive more reliably, and the reason is mechanical rather than stylistic. A rule stated as its own line is hard to miss. The same rule embedded three sentences into an explanation of why the rule exists is easy to miss, precisely when context is full and attention is stretched. Narrative buries the signal it is trying to convey.

Treat the instruction layer the way you would a checklist rather than a piece of exposition. One rule per line, grouped so that related rules sit together and the model meets a whole category at once instead of a scattered handful. This is a reliability choice before it is a readability one. Grouping and brevity reduce the chance that a rule is overlooked, and they make the whole layer auditable, which matters for the verification that has to follow. Rationale is not forbidden, but it earns its place only when an instruction genuinely cannot be understood or applied without it. The default is the bare directive, and prose is the exception you justify.

The only proof is observed behavior

An instruction layer cannot be verified by reading it. Reading tells you what you intended; it tells you nothing about what the agent does, and those are different things, which is the entire premise of this problem. The one way to know is to run the system and watch. Does the agent actually produce the behavior each directive describes, in a real invocation, on real input?

This matters because the failure modes are silent by nature. An instruction may not be loading at all, and a rule that never reaches the model is indistinguishable, from the outside, from a rule the model chose to ignore. An instruction may be present but overridden by a higher-authority directive, so it applies in your mental model and not in the run. An instruction may be read and quietly skipped because it was vague. None of these announce themselves. Each one looks, from the output, like an agent that simply did not do the thing, and you cannot tell which without exercising the behavior deliberately and checking the result against the directive.

Verification is therefore not a final QA step bolted onto instruction design. It is part of the design loop. You write a directive, you run the system, you confirm the behavior changed in the way the directive intended, and only then do you trust the line. A directive you have never seen take effect is a hypothesis, not a rule, and an instruction layer full of untested hypotheses is exactly the document that reads as authoritative and steers nothing.

A smaller instruction layer is a stronger one

The through-line of all of this is subtractive. The instruction layer that works is not the one that anticipates every case and records every preference. It is the one where every line is specific enough to act on, every line survives the test of changing behavior the model would not have produced on its own, nothing duplicates a guarantee a deterministic control already provides, and every directive has been observed to hold in a real run. That layer is smaller than the one most systems accumulate, and it is stronger for being smaller, because its signal is not competing with its own volume.

The temptation always runs the other way, toward writing more, on the theory that a longer instruction layer is a more careful one. It is the opposite. In this domain the shorter layer wins without exception, because the agent’s attention and its context are both finite, and every instruction that does not earn its place spends both to accomplish nothing. Design the layer as a curated set of decisions the model could not have reached alone, keep it short enough that no rule hides behind another, and prove it against behavior rather than trusting it against intention. What remains is the part the agent will actually follow, which was the only part that was ever doing any work.