Every architecture-governance model I have ever worked inside assumes one thing so deeply that nobody writes it down: that change is slow enough to inspect. The Architecture Decision Record assumes someone will read it before the decision matters. The review board assumes a cadence — fortnightly, monthly — at which proposals arrive and verdicts are returned. The approval gate assumes that holding a change for two days is a rounding error against the weeks it took to build.

Agentic delivery dissolves that assumption. When an agent can refactor a service, swap a dependency, and open a pull request before the fortnightly board has finished its coffee, the board is no longer the thing that keeps architecture coherent. It is the thing standing in the way of work that has already happened. The gate has become the bottleneck.

This is not a complaint about agents being too fast. It is a claim that our governance machinery was built for a tempo that no longer exists, and that bolting a faster human onto the same machine does not fix it.

The bottleneck nobody planned for

The mismatch is structural, not cultural. Human-authored change arrives at human cadence: a developer can produce, optimistically, a handful of meaningful architectural changes a week. A governance function sized for that flow — one board, a few architects, a queue measured in days — is comfortably provisioned. The numbers work.

Now put three or four agents on the same codebase, each capable of producing architecturally significant change in minutes. The arrival rate jumps by an order of magnitude while the service rate of the governance function stays flat. Queueing theory has only one thing to say about a system whose arrival rate exceeds its service rate: the queue grows without bound. In practice that means one of two failures. Either the queue becomes real and delivery stalls behind it, or — far more common — the queue is quietly bypassed and governance becomes fiction. Changes ship un-reviewed, and the ADR log becomes an archive of decisions nobody waited for.

I have watched the second failure mode set in. It does not announce itself. It looks like velocity.

Why the gate model fails

The gate model has a hidden premise: that the bottleneck resource — architect attention — is the scarce thing worth rationing. For thirty years that was true. Architect judgement was expensive and slow, code was expensive and slow, and a gate that spent a little of the former to protect a lot of the latter was a good trade.

Agentic delivery inverts the economics. Code is now cheap and fast. Architect attention is still expensive and slow, and is now the only slow thing in the pipeline. A gate that rations the slow resource by making everything else wait for it is no longer protecting the expensive thing. It is converting the one genuinely scarce resource into a global speed limit.

You can see why “just review faster” cannot work. The problem is not that any individual review is too slow. It is that synchronous human judgement in the critical path of every change is structurally incompatible with change that arrives faster than humans can read. The gate is in the wrong place. It is not a tuning problem; it is a topology problem.

From gates to fitness functions

The way out is to stop expressing architectural intent as a decision to be checked and start expressing it as a property to be enforced. This is exactly the move that Building Evolutionary Architectures (Ford, Parsons and Kua) spent a whole book making, years before anyone needed it for agents. A fitness function encodes an architectural characteristic — layering rules, latency budgets, dependency direction, coupling limits, data-residency constraints — as an automated, continuously evaluated test. The book did not write itself for the agentic era. It did not need to. The framing transfers without modification, and it is the single most useful tool I know for this problem.

The shift is from review to invariant. A board says “this change looks acceptable to me, this once.” A fitness function says “no change, by anyone or anything, may violate this property — ever, and the build goes red the moment one does.” The first scales with architect hours. The second scales with nothing; it runs at the speed of the pipeline. An agent that produces a change violating an architectural invariant gets the same instant red build a human would, with no architect in the loop and no queue to join.

This is the only governance mechanism I have found that runs at agent speed, because it is the only one that does not put a human in the synchronous path. Architects still do the expensive, slow, valuable work — deciding which properties matter and encoding them — but they do it once, ahead of time, not once per change.

Who is accountable when the agent decides?

Automated invariants handle the what. They do not answer the who. When an agent makes a change that is technically within every fitness function but strategically wrong — a defensible local choice that quietly erodes a boundary you cared about — someone has to own that outcome. Invariants are a floor, not a conscience.

This is where Team Topologies (Skelton and Pais) earns its place in an essay about AI. Its real contribution was never the four team types; it was insisting that every part of a system have a team that unambiguously owns it, with a clean interface to the rest. That insistence becomes load-bearing when agents enter the picture. An agent does not absorb accountability. It acts inside a boundary that a team owns, and that team owns the consequences of what the agent does there, exactly as it would own a junior engineer’s commit. If a capability has no owning team, putting an agent on it does not create accountability — it launders its absence.

The governance question quietly changes shape. It stops being “did we approve this change?” and becomes “is every part of the estate owned by a team that has encoded what it cares about as enforceable invariants?” The agent-as-actor framing that Enterprise Architecture in the Age of Agentic AI (Dahdour) reaches for lands here: the agent is a participant operating inside a boundary, not a thing you govern one decision at a time.

A governance model for agent speed

Put together, the model is unglamorous and, I think, correct:

  • Move intent left, into invariants. Anything you would otherwise catch at a review gate, try to express as a fitness function that fails the build automatically. The architect’s work moves from judging changes to authoring and curating properties.
  • Make ownership total. Every capability, service and boundary has a team accountable for it. Agents operate strictly inside owned boundaries. Unowned territory is the real risk, not fast agents.
  • Reserve human review for the irreversible. Keep a board, but point it only at decisions that genuinely cannot be encoded and cannot be cheaply undone: a new external dependency, a data-residency boundary, a public contract. Let everything reversible flow through invariants. This is the agentic restatement of the old “one-way vs two-way door” instinct.
  • Govern the invariants, not the changes. The new review artefact is the set of fitness functions itself. That is what the board argues about, version-controls and signs off — slowly, deliberately, at human cadence — because it changes far less often than the code does.

None of this is a downgrade of the architect’s role. It is a promotion. The job stops being a turnstile attendant in the critical path and becomes what it always should have been: deciding which properties the system must always hold, and making those properties impossible to violate quietly. The review board does not have to keep up with the agents. It has to make sure it never needed to.