2026-09-17Gunner Technology

Governance Has to Run at Agent Speed

If an agent can make ten consequential moves before a person finishes reviewing the first one, adding another approval meeting is not governance. It is a queue the machine will outrun.

Speed breaks review as the default

Traditional oversight assumes work arrives slowly enough for a person to inspect it before the next decision lands. Agent-run delivery breaks that assumption. One worker can edit, test, open a change, respond to feedback, and start the next task while the reviewer is still reconstructing what happened. Put more agents on the line and the gap becomes the operating model.
You can answer by forcing every move through a human. That may reduce immediate risk, but it also throws away the reason to build a software factory. The person becomes a manual switchboard, the agents wait, and throughput collapses into availability. The control technically exists because production barely does.
The other answer is worse: let the agents move quickly and promise to audit the trail later. By then, a bad assumption may have crossed repositories, environments, and release boundaries. A record of the damage is useful for recovery. It is not a substitute for preventing the move that caused it.

Put policy in the path

Governance has to execute where the work executes. The factory should classify the task, issue the narrow credential, expose the permitted tools, demand the required evidence, and refuse the next transition when a condition is not met. Those controls run at machine speed because they are part of the route, not instructions waiting for someone to remember them.
A policy document can explain why production data needs protection. It cannot stop a tool call. A working boundary can. The same distinction holds for spending, model selection, code ownership, test coverage, deployment authority, and rollback. If the consequence matters, turn the rule into something the system can observe and enforce.
This does not mean encoding every judgment as a boolean. It means separating repeatable classification from real uncertainty. Known conditions should route mechanically. Novel consequences should escalate with the evidence already assembled, so the person decides the hard part instead of spending an hour proving that routine checks happened.

Govern the whole chain, not one agent

An agent's permissions are not the full boundary. It can ask another worker to act, trigger an automation with broader authority, or place an artifact where a later system trusts it. The original agent may never hold the dangerous credential and still cause the dangerous outcome. Governance that stops at the worker's identity misses the chain that turns its request into a consequence.
Bind authority to the task and verify every consequential handoff. The build worker may propose a release, but the release path should independently confirm the exact revision, the required proof, the target environment, and the approval appropriate to that risk. A delegated action inherits the task's limits; it does not gain whatever authority the next tool happens to possess.
That chain also needs recovery state. If an external action succeeds and the run fails afterward, the next attempt must know what already happened. Otherwise a retry can repeat a payment, notification, migration, or deployment while every individual step still looks permitted. Good governance controls transitions and remembers effects.

The controls need feedback too

Static rules decay. Products change, models change, and yesterday's sensible threshold becomes today's loophole or bottleneck. The answer is not to let the executing agent quietly rewrite its own standard. A worker that can lower the bar after seeing its result is not adapting. It is grading itself.
Treat control changes like production changes. Record which workflow, context, model, permissions, gates, exceptions, and final decision shaped each run. Replay representative work before promoting a new rule. Give the change a version and a rollback path. Let agents propose improvements and gather evidence, but keep acceptance with the authority that owns the consequence.
The same evidence should remove controls that no longer earn their cost. A warning nobody acts on is noise. Two rules that block the same failure create confusion. A gate that cannot explain what it protects becomes ritual. The goal is not maximum friction. It is the smallest set of controls that reliably changes unsafe routes.

Move people to the consequences

Human judgment still decides what the business is willing to risk, which outcomes deserve pursuit, and when an exception is worth owning. But people should not spend their days checking routine facts a machine can verify more consistently. Put them at the points where the consequence is genuinely ambiguous, not at every mechanical transition on the way there.
That shift will remove jobs built around forwarding approvals, restating policy, and manually sampling predictable work. We should say that plainly. Organizations that turn those duties into executable controls will operate faster with fewer coordinators than organizations that preserve a human checkpoint for comfort.
Our position is simple: autonomy and governance are not opposing forces. Weak governance limits autonomy because nobody can trust the route. Strong governance makes more autonomy defensible because authority stays narrow, proof survives the worker, and unusual consequences reach the right person. The factory can move at agent speed only when its controls can move with it.