Architecture Review Can't Keep Up With Agent Speed. Decide What Never Gets Reviewed.

Most enterprise architecture functions were designed around a quiet assumption: change arrives slower than architects can review it. That assumption is gone. When delivery teams, copilots and task-specific agents all generate change at machine cadence, a review board sized for forty submissions a quarter becomes the single longest queue in the organisation. The reflex is to hire more architects or add a triage meeting. Both are wrong. The real work in an AI-first operating model is deciding, up front, which categories of change never touch a human reviewer — and accepting the risk that decision implies.

The bottleneck moved, and it moved toward you

The evidence from software delivery is blunt. Research covered by CIO and others on AI-assisted engineering has consistently found that generation speed rises while throughput does not, because the review stage absorbs the gain. A widely cited Harvard study of teams using AI coding agents found output rose roughly 30% while the time to get code through review stretched by nearly half — finished work barely moved. Architecture governance is the same mechanism one level up. If agents and AI-accelerated teams propose integrations, data flows and service changes faster, and approval capacity is fixed, the queue grows and shadow work routes around it.

Gartner's prediction that 40% of enterprise applications will embed task-specific AI agents by the end of 2026 — up from under 5% in 2025 — tells you the volume is not a spike. It is the new baseline. You cannot staff your way past it.

Classify by reversibility and blast radius, not by size

The useful question is not "is this change significant?" but "what does it cost to undo, and who feels it if it's wrong?" That gives you three lanes:

• Pre-approved by pattern. Changes that stay inside an existing contract, use a sanctioned integration pattern, and touch data the team already owns. No review. Conformance is checked by pipeline, not by meeting.
• Reviewed asynchronously, with a clock. New consumers of existing data, new third-party endpoints, changes that cross a team boundary. A named architect responds within a published SLA — and if they don't, it proceeds. An expiring review is more honest than an indefinite one.
• Blocking review, deliberately rare. Irreversible commitments: new systems of record, data leaving a jurisdiction, anything granting an autonomous agent write access to financially material records. Keep this list short enough to recite from memory.

The discipline is the inverse of what most boards do. They review what is large and visible; they should review what is hard to reverse. A €4m platform licence signed with an exit clause is less dangerous than a quietly added retrieval path over HR data.

Publish the paved road, or you're just a gate

Every change you exempt from review has to be absorbed by something. That something is the paved road: reference patterns, pre-wired integration templates, approved model endpoints, data contracts with owners attached, and automated conformance checks in CI. If the sanctioned path is slower than the improvised one, teams will improvise — and with agents in the loop, they will improvise at volume.

This is where SAP-heavy landscapes get interesting. Clean-core discipline, extension patterns and event contracts are exactly the kind of pre-approved surface that lets you stop reviewing individual extensions one at a time. We've seen this pay off repeatedly in SAP Commerce and CX programmes, where the architecture effort moves from approving developments to curating the small set of ways a development is allowed to happen.

Assure by sampling, not by gate

Once most change flows unreviewed, your assurance model has to change with it. Gates give you certainty about a shrinking fraction of reality. Sampling plus telemetry gives you a defensible picture of the whole. Pull a random set of changes each month and audit them against the pattern catalogue. Instrument the drift you care about: unapproved egress, orphaned data consumers, agents operating outside their permission envelope, services with no owner on call. Report escape rate — changes that bypassed the paved road and caused an incident — as the headline metric of the EA function. If it's near zero, you are reviewing too much.

The architect's new scorecard

In an AI-first operating model, the architect who personally approves the most designs is the one creating the most delay. The valuable ones are measured differently: percentage of change flowing through pre-approved patterns, median time-to-decision on the exceptions, number of irreversible commitments caught before they shipped, and the decommission count behind them. That is a very different job description — closer to a policy designer and systems auditor than a reviewer, and it needs the operating model to be redesigned alongside it.

The organisations that get this right over the next two years will not be the ones with the strictest governance. They will be the ones that can say precisely which decisions they have chosen not to make — and can prove, with telemetry rather than minutes, that the choice was sound.