How do you design governance that grows with the agent instead of capping it?

Governance sized for a read-only pilot strangles a production agent, and governance sized for full autonomy crushes an experiment. The teams that scale tie the control level to the capability level.

B

Balagei G Nagarajan

4 MIN READ


A staircase where each step up in agent capability is matched by a step up in control strength
Even the strongest agent gets realistic tasks right only about one time in seven.
— from “How do you design governance that grows with the agent instead of capping it?”

Key facts.

  • On WebArena, the best agent completes about 14% of realistic web tasks versus a 78% human baseline, so capability and the failure rate it carries rise together.source
  • Moffatt v. Air Canada (2024 BCCRT 149) held a company liable for its chatbot's wrong answer, raising the stakes of each rung an agent climbs and the controls each rung needs.source
  • The CSA and Google Cloud State of AI Security and Governance survey found only about 26% of organizations have full AI security governance and that maturity predicts readiness, so the control most agents actually carry today is proportional and still thin.source
  • Controls should track blast radius, light while read-only, heavier with authority, because a more capable model still misses, WebArena's best at 14%, so each permission is risk. (arXiv:2307.13854)

Why does fixed-level governance fail at both ends?

Because the right amount of control depends on what the agent can do and that changes. Govern an early experiment as if it had production authority and you bury a read-only prototype under approval queues nobody needs. The experiment never produces the learning it was for. Govern a production agent as if it were still a sandbox demo and you hand real authority to a system with no gates. Is how the incident happens. A fixed level is wrong for everything except the one capability level it was sized for and agents do not stay at one level. The design that works is staged: the controls are defined as a ladder and the agent climbs from one rung to the next only when it has earned the authority and the matching controls are in place.

The WebArena number is why the ladder has to tighten as it rises. Even the strongest agent gets realistic tasks right only about one time in seven. The moment you grant authority over a real system, you are granting it to something that is wrong far more often than a person doing the same job. A more capable model raises the success rate but not to a level where unsupervised authority over high-stakes actions is safe. Each rung up in capability needs a matching rung up in control: more approval depth, more audit detail, tighter boundaries. Governance that scales is not more governance, it is the right governance for the rung the agent is on.

A radial chart with concentric rings, inner ring light controls for read-only, outer rings heavier controls as authority expands

What does a governance ladder look like In practice: ?

Rung one: read-only, low-stakes. Light logging, no approval gates, broad freedom to explore, because the blast radius is near zero. Rung two: writes to non-critical systems. Structured audit logs, scope boundaries, alerting on anomalies. Rung three: irreversible or high-value actions. Approval gates, full reasoning capture, least-privilege enforcement, named owner accountable. The agent moves up a rung only when it has demonstrated reliability at the current one and the next rung's controls are live. The result is governance that never strangles an experiment and never under-protects a production system.

Capability rungMatching controls
Read-only, low stakesLight logging, broad freedom
Writes to non-critical systemsAudit logs, scope boundaries, anomaly alerts
Irreversible / high-value actionsApproval gates, full trace capture, least privilege, named owner

The Pattern Intelligence Layer is where the ladder is defined and enforced. The control level can rise with the agent's capability without rebuilding governance from scratch at each step. Approval depth, audit detail and boundary tightness are set at the pattern level per rung. Is what lets a program scale an agent's authority safely instead of choosing once between too much governance and too little. Reliability at the pattern level is what makes the climb controlled.

Frequently asked questions

Why not just apply strong governance from day one?
Because it strangles the early experiments that produce the learning. Read-only prototypes do not need approval queues; production authority does.

When does an agent move up a rung?
When it has shown reliability at its current level and the next rung's controls are live. Capability and control advance together, never one without the other.

Doesn't this add complexity?
It replaces one wrong fixed level with the right level per stage. The complexity is in the ladder design, paid once, not in fighting mismatched governance forever.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.