Your policy file is not a control

Every team automating with agents eventually writes the document. It is called AGENTS.md or the SOP or the house rules, it grows every time something goes wrong, and it feels like safety. Three findings from the past week say it mostly is not.

The benchmark that should change how you write guardrails

A new agent benchmark puts a standard operating procedure into the context window (20 to 124 pages of it) and then asks the model to do 65 realistic tasks under those rules. The tasks are not trivial: roughly 17 reasoning steps and 30 tool calls on average.

No frontier model gets above a 25 percent pass rate. That number is bad enough. The detail that matters more is where the failures sit: models also miss the clauses that simply say stop. Not the subtle trade-offs, not the ambiguous escalation rules. The hard prohibitions.

If you have been treating a long policy file as the thing that keeps an autonomous process inside the lines, that is the finding to sit with. Compliance was never a property of the document. It was a hope about the reader.

The opposite move points the same way

In the same week, Anthropic reported deleting more than 80 percent of the Claude Code system prompt for its newest models, with no measurable drop on coding evals. The reasoning was that constraints written to prevent old worst cases had become contradictory instructions and token ballast.

Put the two results next to each other. One team added policy and got 25 percent adherence. Another removed 80 percent of its policy and lost nothing measurable. The volume of prose in the context window turns out to be close to orthogonal to how the system actually behaves.

Claims about the environment are not the environment

There is a sharper version of this, and it came out of an eval program rather than a benchmark. During capture-the-flag security evaluations, a configuration mistake gave several models real internet access while their prompts stated they were offline. The earliest cases date from April; it surfaced in late July during a transcript review. Two of the three affected organizations had no idea.

Nobody checked the network layer, because the prompt said there was nothing to check. That is the whole failure mode in one sentence: a statement inside the context window was treated as a fact about the system.

The memory research from the same week rhymes with it. One benchmark measured 14.4 percent retrieval accuracy when an agent had to actively pull a stored fact, against 84 percent when the same fact was already sitting in the context window. Increasing the embedding dimension eightfold barely moved it. What the model can reach and what you have written down are different objects, and the gap is not small.

What a control actually looks like

Three properties, and prose has none of them.

• It runs outside the model's context: in the client, the gateway, the runtime, the scheduler. Something the model cannot argue with, reinterpret, or fail to recall.
• It fails closed. When the check cannot complete, the action does not happen. A sentence in a policy file has no closed state; it is either read or it is not.
• It leaves an artifact. A timestamp, a log line, a written file that a second, dumber system can inspect afterwards to ask whether the thing actually happened.

Concretely, in an automation stack: not "never re-trigger more than five executions at once" in a markdown file, but a counter in the API client that refuses the sixth call. Not "do not block on long calls", but a runtime timeout that moves the call to the background. Not "always write a summary", but a freshness check that looks at the output directory and alerts when it is older than a week.

What I got wrong

My own weekly pipeline went quiet for three weeks earlier this summer. It never crashed; a blocking call in an unattended session simply waited forever, and the schedule reported a successful run each time. My first fix was to write a guard paragraph into 19 task files explaining exactly what not to do.

That paragraph is a record of an incident. It is not a defense against one. The fix that actually holds arrived later and one layer down: a runtime setting that pushes any call past a threshold into the background, so a hanging tool can no longer take the session with it.

I did not delete the prose, and I would not. Written rules are how a human picks up the system in six months and understands why it is shaped this way. They just should not be load-bearing. Keep the document as an explanation, and move every rule you actually care about into something that runs.

The useful audit question is not whether your policy is complete. It is which of your rules would still hold if the model never read a word of it.