A colleague forwarded me a slide deck last quarter titled “TOGAF is dead in the age of AI.” Two slides later it recommended replacing the framework with a governance board, an iterative delivery cycle, and a central repository of architecture decisions. I wrote back: congratulations, you have reinvented TOGAF and removed the parts that were already working. That exchange is this whole article in miniature.

The interesting question is not whether TOGAF survives agentic AI — frameworks do not die, they get quietly ignored — but which parts of it still earn their keep when systems start changing themselves faster than your governance cycle can meet. I have spent the last eighteen months running an EA function through exactly that transition. Here is the honest audit: what holds, what strains, and where you have to supplement the framework rather than defend it.

What still holds

The ADM as an iterative loop

Strip the ADM of its accumulated ceremony and you are left with a control loop: establish where you are, decide where you want to be, work the gap, govern the change, feed what you learned back in. That loop does not care whether the change is delivered by a project team over six months or by an agent reconfiguring a workflow overnight. If anything, agentic systems make the loop more relevant, because the cycle time collapses and you need a disciplined way to keep up rather than react.

The mistake people make is reading the ADM phases — A through H — as a waterfall. They were never meant to be one, and the 10th edition is unusually clear about this. Read it as a loop you run continuously at different altitudes and it ages well. The framework’s own guidance on iteration and on applying the ADM at different levels of the enterprise is the part I lean on most now. If you want the version that actually says this out loud, it is in

The TOGAF Standard, 10th Edition

— and I have written at length about why the 10th edition is defensible in a way earlier ones were not in my full review.

Architecture governance

This is the part the AI-is-coming crowd reinvents without noticing. The moment you have systems making changes without a human reading every diff, you need a named way to reason about who is accountable, what the guardrails are, and how exceptions get raised. That is architecture governance, and TOGAF has had a serviceable model of it for two decades. The Architecture Board, the compliance review, the dispensation process — these are not bureaucracy for its own sake. They are the human-accountability scaffolding you need precisely because the machine moves faster than you do.

What changes is the cadence and the object of governance. You are no longer reviewing a solution design once before build. You are governing a system that keeps changing, which means governance has to become continuous and partly automated. More on that below — but the concept survives intact.

Capability-based planning

Capabilities are deliberately technology-agnostic, and that is exactly why they outlast the technology underneath them. “We need a fraud-detection capability” is a sentence that survives the shift from a rules engine to a model to an agentic pipeline; “we need a rules engine” does not. Planning at the capability level is the cleanest way I know to talk to a leadership team about AI investment without getting dragged into a tooling argument. It is the layer where the business conversation actually lives.

The repository idea

The notion that your architecture knowledge should live in a queryable, versioned repository rather than in slideware and tribal memory has gone from nice-to-have to load-bearing. When agents are participating in change, they need a machine-readable source of truth about constraints, standards, and current state — and so do the humans governing them. TOGAF’s repository concept is under-implemented in most shops, but it was directionally right, and the AI era makes the gap expensive.

What strains

Heavyweight up-front artefacts

This is where the framework creaks. The instinct to produce a complete set of baseline and target architecture documents, fully cross-referenced, before anything ships, was always in tension with iterative delivery. Agentic systems break it outright. By the time you have finished the target-state document, the system has changed under you. Any artefact whose value depends on being complete and current is now a liability, because completeness and currency are no longer compatible at the speed change arrives.

The fix is not to abandon documentation. It is to invert it: capture intent and constraints as durable artefacts, and let current state be generated from the running system rather than maintained by hand. A target architecture you hand-maintain is fiction within a quarter.

Big design up front

Closely related, and worse. The honest case for big design up front was always that change was expensive, so you wanted to get it right before committing. When an agent can reconfigure a workflow in an afternoon, the economics flip: the cost of being wrong drops, and the cost of deciding slowly rises. The discipline that pays off now is making decisions reversible and observable, not making them perfect in advance. TOGAF does not forbid this, but its centre of gravity still tilts toward up-front rigour, and you have to consciously lean against it.

The assumption that change is human-paced

This is the deepest strain, and the one the framework cannot fully absorb. Every governance cadence in classic TOGAF — the board meeting, the review cycle, the dispensation request — assumes a human decides, at human speed. Agentic systems that act between your governance meetings violate that assumption at the root. You cannot govern a Tuesday-afternoon change with a board that meets monthly. This is not a flaw you can document your way out of; it is a structural mismatch, and it is where supplementation stops being optional. I have argued the cadence problem on its own terms in when the review board becomes the bottleneck: the short version is that synchronous human review in the path of every change cannot survive change that arrives faster than humans can read it.

Where you have to supplement

This is the part the framework genuinely does not give you, and where the newer literature earns its place on the shelf.

Fitness functions. If you are going to let systems change continuously, you need automated, executable checks that the architecture’s important properties still hold — latency budgets, data-residency rules, cost ceilings, autonomy boundaries. This is the single most important addition to architectural practice in the last decade, and it transfers almost without modification to agentic systems. The reference is Building Evolutionary Architectures, 2nd ed, and I would read it in full before you try to bolt continuous governance onto a TOGAF practice. Fitness functions are how governance becomes continuous rather than quarterly — they are the missing mechanism the ADM’s “human-paced change” assumption left out.

Agentic patterns. TOGAF will not tell you how to structure a multi-agent system, what a verifier loop is, or how to bound autonomy at the design level — nor should it; that is solution architecture, not enterprise framework. But you need a shared vocabulary for it. The first serious catalogue I have found is

Agentic Architectural Patterns

(review here). The Verifier pattern in particular is the design-level answer to the governance-cadence problem: you push some of the checking down into the system itself.

Autonomy and compounded risk. The discipline-level question — what does the EA function become when agents are first-class participants in change — is not something TOGAF was written to answer. The best treatment I have read is Enterprise Architecture in the Age of Agentic AI, which I gave an honest first reading earlier this year. It is uneven, but its treatment of compounded-autonomy risk — what happens when autonomous components make decisions that feed each other — is the part TOGAF has no vocabulary for at all.

Using TOGAF pragmatically now

If you already run on TOGAF, you do not need to rip it out. You need to use it with a lighter hand:

  • Run the ADM as a continuous loop, not a programme. Shorten the cycle, run it at multiple altitudes, and stop treating phase completion as a gate.
  • Keep governance; change its clock. Push routine checks into automated fitness functions and reserve the board for the exceptions and the genuinely irreversible decisions.
  • Make capabilities, not solutions, the planning unit. It is the layer that survives the next tooling shift, and there will be one.
  • Treat current-state documentation as generated, intent as authored. Stop hand-maintaining target-state diagrams that are wrong within a quarter.
  • Adopt the cert vocabulary if your org runs on it, but don’t mistake it for the job. If you are working toward OGEA-101/102, the self-study path is the efficient route, and Mastering TOGAF 10 (review) is the study companion I’d pair with the standard. The exam teaches you the language; this article is about using it without being used by it.

TOGAF and AI — quick answers

Is TOGAF still relevant in the age of AI and agentic systems?
Yes, but selectively. The ADM as an iterative loop, architecture governance, capability-based planning, and the repository concept all hold up well. The parts that strain are heavyweight up-front artefacts and big-design-up-front, because agentic systems change faster than those documents can stay current. Use the durable parts and supplement the rest.
What parts of TOGAF break down with agentic AI?
Three things strain: the instinct to produce complete target-state documents before shipping, big design up front, and the built-in assumption that change happens at human pace. Governance cadences that assume a human decides at human speed cannot govern a system that acts between your board meetings.
Do I still need TOGAF certification if I work on AI systems?
It depends on your organisation. If your enterprise runs on TOGAF, the OGEA-101/102 vocabulary is worth having so you can speak the governance language. But certification teaches you the framework, not how to apply it to systems that change themselves — for that you need fitness functions and agentic patterns the standard does not cover.
What should I read alongside TOGAF to cover the AI gap?
Building Evolutionary Architectures for fitness functions (the mechanism that makes governance continuous), Agentic Architectural Patterns for the agent-system vocabulary TOGAF lacks, and Enterprise Architecture in the Age of Agentic AI for the discipline-level framing and compounded-autonomy risk. None of those topics is in the standard.

Bottom line

TOGAF is neither dead nor sufficient, and the people selling you either story are both wrong. What survives agentic AI is the framework’s spine — the ADM as a loop, governance, capability-based planning, the repository — because those are ideas about how to stay in control of change, and control matters more, not less, when the change is automated. What strains is the ceremony — the up-front artefacts and the assumption that you have time to design before you commit.

Use the standard for the spine, read the 10th edition charitably, and supplement it deliberately with fitness functions and agentic patterns for the parts it was never written to cover. The skill the AI era actually demands is knowing which half of your framework is load-bearing and which half is habit. TOGAF will not tell you that. Eighteen months of running it through the transition will.