Key facts.
- The Berkeley Function-Calling Leaderboard's multi-turn evaluation shows leading models completing roughly half or fewer multi-step tool tasks, so iteration regressions are easy to introduce. source
- WebArena (arXiv:2307.13854) found the best agent completed about 14% of realistic web tasks versus roughly 78% for humans, showing how far behavior can vary across changes. source
- The OpenTelemetry GenAI semantic conventions, still in experimental status as of 2026, give a stable instrumentation schema that lets the agent change while the monitoring stays consistent. source
Why do iteration and governance pull against each other?
Because they optimize for opposite things. Iteration wants to change the agent often, since that is how prompts get better, tools get added and models get swapped for stronger ones. Governance wants the agent to be stable and predictable, since that is what lets the enterprise trust it. Left unmanaged, one wins: either governance freezes the agent and the program stalls behind a competitor that kept improving or iteration runs unchecked and a fast change introduces a regression that becomes an incident. BFCL and WebArena are why the regression risk is not hypothetical, model behavior on multi-step and realistic tasks is far from saturated, so a change that improves one path can quietly break another. The tension is structural and pretending it does not exist just lets one side win silently.
A more capable model does not dissolve the tension, it pushes harder on the iteration side, because a better model is a reason to change the agent, which raises the value of having stable controls to change against. The resolution most shipping teams converge on is a two-layer structure: a fast layer where prompts, tools and model choices iterate freely and a slow layer of boundaries, approval gates and monitoring that changes only through deliberate review. The OpenTelemetry GenAI conventions illustrate the slow layer's value: a stable instrumentation schema means the agent can change underneath while the monitoring keeps reporting in the same terms, so iteration does not blind you. Speed lives in the fast layer; trust lives in the slow one.
How do shipping teams hold both?
By deciding what is allowed to move fast and what must move slowly and enforcing the split. Prompts, tools and model versions go in the fast layer, where iteration is cheap and changes are common. Boundaries on what the agent may do, gates on sensitive actions and the monitoring schema go in the slow layer, where changes require review because trust depends on them. A change in the fast layer is validated against the stable controls before it ships, so a regression is caught rather than discovered. And the monitoring stays consistent across iterations, which is exactly what a stable convention like OpenTelemetry's gives you. The result is an agent that keeps improving without the controls shifting under it, which is how a program moves fast without breaking the trust it needs to stay in production.
| Layer | Changes | Governs for |
|---|---|---|
| Prompts and tools | Fast, frequent | Quality and speed |
| Model version | Fast, validated | Capability |
| Boundaries and gates | Slow, reviewed | Trust and safety |
| Monitoring schema | Stable | Consistent visibility |
The Pattern Intelligence Layer is where the fast and slow layers meet. A fast change to prompts, tools or model is validated against stable boundaries and monitoring at the pattern level, so iteration keeps moving while the controls hold steady. Reliability at the pattern level is what lets a team move fast on the agent without the governance moving under it.
Frequently asked questions
Does a better model let you skip the stable-controls layer?
Best agents finished about 14% on WebArena against humans' 78%, so a change that helps one case regresses another; a more capable model only speeds iteration, which is why a fast layer over slow boundaries wins. (arXiv:2307.13854)
Can't strong governance just slow everything down safely?
It can and that is the failure mode where the program stalls. The goal is not to slow iteration but to give it stable controls to move against, so speed and trust coexist.
Why validate every fast change against the controls?
Because behavior is not saturated. BFCL and WebArena show changes can regress other paths, so validating against stable controls catches the regression before it ships.
What belongs in the slow layer?
Anything trust depends on: boundaries, approval gates and the monitoring schema. These change only through deliberate review, so the agent can iterate without the controls shifting.