Architecture at agent speed

What the paper argues

When an agent implements against a design, it makes hundreds of small structural decisions: where a boundary sits, how a contract is shaped, which assumption to hold and which to relax. Together they accumulate into a system that has quietly moved away from the document that describes it. The high-level design is the single point where every domain meets, so when it drifts it does not fail in one place. It becomes unreliable across all of them at once. It cannot be allowed to drift, and it cannot be frozen. It has to become live, and the real question is whether its evolution is governed.

The answer is not to abandon governance but to move it: from approval before the work to evidence during it, and from a document that describes the past to one that keeps pace with the present.

Key points

• Enterprises are left with two poor options: hold the design static, so it describes what was meant rather than what was built, or let it evolve without control and lose the traceability that made it worth having.
• Governing the governance is a trap. A policy taken through committee and multi-domain review is obsolete on arrival, because the agents shipped features while it was in review. A policy that takes three months and is wrong when it lands only looks safer.
• Most enterprise architecture governance lives on the documented side of the theatre gap: complete, configured and logged, but not changing behaviour at the point of action.
• The rigour moves from one heavy approval gate to three lighter places: detection at the point of authoring, evidence captured as the change happens, and fast review afterwards that judges the call rather than reconstructing what changed.
• Architecture decision records, drift detection and versioned contracts already work in isolation. The move is to unify them, so the high-level design, the low-level design and the decision records follow the same lifecycle as code: version control, diffs, review at the point of change and the ability to roll back.
• The gap is conceptual, not technical. The answer is an operating model an organisation can adopt on its own terms, using tools it already has, not a product.