Notes on TOGAF in the Era of Agents.

What the method quietly assumed

The Architecture Development Method is a cycle. Vision, then business architecture, then information systems, then technology, then opportunities and migration planning, then implementation governance, then change management, with requirements management sitting in the middle and feeding every phase. It is a good cycle. It has survived thirty years of practice because it encodes something true about how large organisations actually change.

Underneath it sits an assumption so ordinary that it was never worth stating. The behaviour of the thing being architected is decided in advance, by people, and written down.

Phase B says what the business does. Phase C says which applications and which data support that. Phase D says what it runs on. Every artefact describes intended behaviour, and the job of implementation is to be faithful to the description. Architecture compliance review is, at bottom, a comparison between a specification and a build.

An agent breaks the comparison. Not because it is unreliable, and not because it is poorly engineered, but because it is doing precisely what it was built to do. Its behaviour at any given moment is a function of a model, an instruction, the tools within reach, the context it retrieved, and the state of the world when it acted. Nobody wrote down the sequence of calls it will make next Thursday. Nobody could have.

An agent is not an underspecified system. It is a system specified at a different altitude.

What still holds, and holds well

Quite a lot, and it is worth being specific rather than generous.

Capability-based planning holds. A capability is described by the outcome it produces rather than by the mechanism that produces it, which is exactly the level at which an agent can be governed. An organisation that already thinks in capabilities has somewhere to attach an agent. An organisation that thinks only in applications does not.

The separation between architecture building blocks and solution building blocks holds, and becomes more useful than it was. The abstract block says what must be true. The solution block says what currently satisfies it. When the solution block is a model that will be replaced twice this year, the value of having kept the two apart stops being theoretical.

The architecture repository holds. So does the idea that governance is a standing function rather than a project gate, which is the part of the method most organisations skipped and are now discovering they needed.

Requirements management at the centre holds too, though what counts as a requirement shifts. For a static system, a requirement describes what the system will do. For an agent, the durable requirements are the ones describing what it must never do, what it must record, and where it must stop.

Where it breaks

The static solution architecture document is the first casualty, and the most emotionally difficult one, because it is the artefact the profession is proudest of.

A solution architecture document describes components, interfaces and a set of sequences. The sequence diagram is the part that ages fastest. It describes one path through a space of possible paths, chosen because it was the path someone had in mind during design. Signed off in one quarter, it describes behaviour that may not recur in the next. It is not wrong. It has stopped being a description of the system, and a document that is treated as authoritative after it stops being descriptive is worse than no document, because it produces confidence without providing information.

The point-in-time compliance review is the second casualty. Reviewing an agent once, against a design, tells you about the design. It tells you very little about the thing that has been running since.

The third is subtler. Architecture principles are written for human readers, and are directional by design. A principle such as "customer data is held only where it is needed" is a useful instruction to an architect, who will interpret it with judgement. It is not an instruction an agent can be held to, because there is nothing in the sentence a system can evaluate. Principles that cannot be expressed as a check are principles that agents will not observe, however carefully they were drafted.

The artefacts that take the weight

Three artefacts move from supporting cast to load-bearing.

The capability contract. TOGAF already has the architecture contract, an agreement between the architecture function and those delivering against it. The move is to push that idea down to the level of a single capability an agent may exercise. What it may do. What data it may see. What it may change without asking. What it must escalate. What evidence it must leave behind. Who owns the consequence when it is wrong. That is not a description of behaviour. It is a boundary on behaviour, and a boundary survives emergence in a way that a sequence does not.

The trust tier. Not every agent warrants the same treatment, and pretending otherwise produces governance that is either theatrical or unaffordable. Tier by the consequence of being wrong: an agent that only advises, an agent that acts within reversible bounds, an agent that acts irreversibly on records the organisation is answerable for. The tier then determines the evidence required, the review cadence, and whether a named human signs. Inside a regulated lender, an agent that drafts an internal credit memo and an agent that updates a customer record are two different governance objects even when they run on the same model behind the same interface.

The repository, read by machines. In classic practice the repository is a library, kept for people, consulted occasionally, and quietly falling out of date between reviews. If capability contracts and trust tiers are expressed in a form a system can read, and if they sit in the execution path rather than beside it, the repository stops being a record of decisions and becomes the place where decisions are enforced. The architecture repository is not a library. It is a control plane, the moment its contents become machine-readable.

The board changes job

An architecture board that reviews proposals is reviewing intentions. With agents, intentions are the least informative thing available.

What a board can usefully approve is the envelope: the contract, the tier, the escalation path, the evidence obligation. What it should then review is the record of what agents actually did inside that envelope, which is a different meeting with different inputs and a different rhythm. Change management stops being the phase that runs after everything else and becomes the phase that runs continuously, because the estate now changes when a model is swapped, when a tool is added, or when a prompt is edited by someone who did not think of it as an architectural act.

This is also the honest answer to the regulatory question. The EU AI Act exists and phases its obligations in over time, and other jurisdictions are moving in the same direction at their own pace. Whatever the specific requirements turn out to be, every regime is asking an organisation to state what a system was permitted to do, why, and on what basis, at the moment it acted. That is an architecture question before it is a legal one. The organisations that will answer it cheaply are the ones whose statements of permitted behaviour already exist as artefacts rather than as recollection.

What this asks of the practice

Contracts bound behaviour. Boundaries make evidence meaningful. Evidence makes governance something other than assertion.

None of this requires abandoning the method. It requires being honest about which of its outputs were ever the point. The diagrams were an aid to human agreement, and they remain useful for exactly that. The contracts, the tiers and the repository were the substance, and they are now the parts that carry weight, because they are the parts that still describe something true after the system starts behaving in ways nobody wrote down.

Enterprise architecture was never about the documents. It was about deciding, deliberately and in advance, which decisions would not be left to whoever happened to be implementing. That question became more important, not less, the moment the implementer stopped being a person.

© 2026 Nabeel Khan. Notes on TOGAF in the Era of Agents is published under CC BY-NC-ND 4.0. Quote it, cite it, do not repackage it.