A study posted to arXiv in July 2026 delivers an uncomfortable number to any organization that has put AI agents into production. The researchers measured what happens when you try to control an AI agent using policy documents of varying length. The result ran counter to intuition: the thicker the rulebook, the less often the agent actually followed it.
Tracing backward from that result — asking why it happens — leads to a full audit of how organizations operate their agents in the first place.
How a Rulebook Gets Fat
There's almost always one trigger for adding a new rule to an agent: it made a mistake before.
If a customer-service agent was supposed to say refunds are good for 14 days and said 7 instead, you add a paragraph on refund policy. If a contract-review agent missed a liability clause, you spell out that clause type explicitly. If legal turns up a new exception, that gets added too. Every mistake deposits one more rule meant to keep it from happening again.
Six months in, the rulebook has become a document running dozens of clauses.
What's easy to miss in this process is that conflicts pile up far faster than rules do. It's a matter of combinatorics. With 10 rules, there are 45 possible conflicting pairs. With 20, it's 190. With 30, it's 435. When an input the agent is handling matches two rules at once, deciding which one wins becomes a fresh source of error in itself. An error triggers another rule. The cycle doesn't move toward fewer conflicts.
Part of the cause also lies in how large language models process long text. Multiple evaluations have found that rules placed earlier in a document carry more weight in the actual output than rules placed later. A rule buried somewhere in the middle ends up existing only on paper. Looking at a 50-rule policy document alone won't tell you how many of those rules are actually, consistently enforced.
When You Try to Fix It by Adding More Rules
When an agent keeps making the same mistake, the natural response is to add a rule aimed directly at it. If that doesn't work, you word the rule more forcefully, attach detailed exceptions, or add a meta-rule — something like "you must always defer to the rules stated above."
A meta-rule looks like it reinforces the existing rules, but functionally it's just one more rule added to the pile. And if the rules it refers back to are already in conflict, the meta-rule simply hands the agent the job of deciding which side of that conflict to take.
The same goes for emphatic prohibitions like "never do this." For a statement like that to actually work, no other rule in the document can implicitly permit the prohibited action. Guaranteeing that across dozens of rules is the job of whoever wrote the document — the agent doesn't interpret the document as a whole. It processes whichever rules it judges most relevant to the input in front of it.
What the Output Logs Tell You First
To check whether this paradox is actually at work, you have to look at the agent's output logs, not the rulebook itself.
If errors are scattered across many different rules rather than clustered around one, the length of the document is probably the cause. If one specific clause were the problem, fixing that clause would fix it. But if the agent breaks rule A this week, rule B next week, and rule C the week after, the load of the entire document is the cause — and no amount of tweaking individual rules will change the pattern.
Another telling signal is an explicit prohibition simply going unheeded. When an agent keeps repeating an action the document says not to do, it's rarely because that rule was worded too weakly. It's because other rules in the same document are competing with it. Making the prohibition sound more emphatic won't help here. What actually works is cutting the number of competing rules or explicitly assigning priority between them.
This runs in the opposite direction from how SOP documents managed by HR or operations teams behave. An SOP gets more complete as you fill in its gaps. An agent's rulebook can see the share of rules actually being followed shrink the more you fill it in.
Why Trimming a Rulebook Is Harder Than Padding It
In the arXiv researchers' experiments, agents complied with rules at a higher rate when given shorter, more focused policy documents. That shows cutting length down is a task requiring genuine design judgment — deciding priority between rules ahead of time and eliminating potential conflicts before they arise.
The starting point is checking whether each rule in the document has an actual documented violation behind it. A rule with no violation history was probably added "just in case." Deleting rules like that doesn't hurt the agent's performance, and it raises the odds that the rules left standing actually get processed.
It also helps to split the rulebook by the type of task the agent handles. Instead of stuffing customer-service, contract-review, and data-cleanup rules into one agent, running a separate rulebook per task structurally cuts the odds of rules colliding within any single document. The more tasks an agent takes on, the more splitting the rulebook — rather than continuing to expand one giant one — helps preserve the compliance rate for each individual rule.
There's a common assumption behind putting AI agents into real operations: that patching the instructions every time the agent slips will eventually add up to stable control. This research shows that path doesn't converge. The relationship between rulebook length and agent reliability isn't monotonic. Past some point, it reverses.
The capacity to convey a complex intention to an agent comes from the work of compressing that intention into simple language. That's a judgment call for the person deploying the agent to make — not something that can be handed off to the agent itself. If a rulebook has grown thick, that isn't a sign enough rules have been added. It's a trace of that judgment having been deferred.
