Key facts.
- MAKER (arXiv:2511.09030) demonstrates that errors compound across long task decompositions unless corrected at each step, so expanding an agent's scope adds failure surface. source
- METR (arXiv:2503.14499) finds the reliable task-completion horizon for frontier models is doubling only about every seven months, so reliability lags behind scope expansion. source
- WebArena (arXiv:2307.13854) found the best agent completed about 14% of realistic multi-step web tasks against roughly 78% for humans, showing how far real-world scope outruns current reliability. source
Why does governance go stale on its own?
Each new tool, model swap or scope change shifts how the agent fails, and MAKER shows errors compound across a long sequence; a more capable model does not stabilize it, so re-review on every change. (arXiv:2511.09030)
Because the agent changes underneath it. The governance you wrote described a specific agent: these tools, this model, this scope, these boundaries. Then you added a tool and now the agent can reach a system the boundaries never mentioned. You swapped the model and now its behavior on edge cases differs from what you tested. You expanded the scope and now the agent runs longer sequences where, as MAKER shows, errors compound in ways the original controls did not anticipate. None of these changes update the governance document by themselves. So the documented agent and the running agent slowly diverge and the space between them is exactly where the controls you think you have do not actually apply.
A more capable model does not make this self-correcting. The temptation with each model upgrade is to expand what the agent does, but METR's measurement shows reliable long-horizon performance rises slowly, so scope expansion routinely outpaces the reliability that should gate it. WebArena makes the gap vivid: on realistic multi-step tasks, the best agents finished a small fraction of what humans did, so an agent handed a broader real-world job is operating well past where it is dependable. Governance is what keeps scope tied to reliability and it only does that if it is re-reviewed when the agent changes, not left as the artifact that was true at launch.
What changes should trigger a governance re-review?
A new tool or integration, because it extends what the agent can reach and act on. A model swap or upgrade, because behavior and failure modes shift even when the task does not. An expanded scope, because longer or broader jobs add the compounding surface MAKER describes. A change in data sources, because new inputs are new injection and error paths. And a change in volume, because patterns that were rare become common at scale. Each of these is a moment to ask whether the boundaries, gates and monitoring still fit the agent that now exists. The teams whose agents stay reliable are the ones who made governance re-review a step in the change process, so the documented agent never drifts far from the running one.
| Change | Static governance | Re-reviewed governance |
|---|---|---|
| New tool added | Boundaries unchanged | Reach re-scoped |
| Model swapped | Old behavior assumed | Edge cases re-tested |
| Scope expanded | Controls unchanged | Compounding surface re-gated |
| Result | Doc drifts from reality | Doc tracks the real agent |
The Pattern Intelligence Layer is where a changing agent stays governed. Behavior, reach and failure patterns are tracked at the pattern level as the agent evolves, so a new tool or expanded scope shows up as a change in the patterns you watch rather than a silent divergence. Reliability at the pattern level is what keeps governance describing the agent that is actually running.
Frequently asked questions
Can't I just write governance broadly enough to cover future changes?
Not reliably. A new tool or model introduces specific failure modes you cannot anticipate generically. Broad governance becomes vague governance, which enforces little.
Why re-review on a model upgrade if the task is the same?
Because behavior and edge-case failures shift with the model. METR shows reliability changes are real, so the controls tuned to the old model may not fit the new one.
Isn't re-reviewing on every change too slow?
It is faster than the incident a stale control lets through. The review scales to the change, a small change gets a small review, but the trigger is the discipline.