The Seam: Where Classical EA Meets Agentic Governance

A few days ago I spent an afternoon with the lead AI architect at a major financial institution. On paper it was a partnership conversation: their AI initiatives, their architectural patterns, their core design principles, and where our teams might work together better. What I actually walked out with was the seed of this post.

They had every artifact you'd expect from a mature architecture team. A reference architecture. A platform stack diagram that had been through several rounds of refinement. Design principles any senior architect would nod at. And underneath all of that, an honest acknowledgement that none of it was really keeping up with how fast their agentic systems were moving in production. The architecture they could draw was a snapshot. The thing they were operating was a river.

That gap, between the architecture you can describe and the runtime you're actually operating, is the problem this post sits with. It isn't a failure of any single team. It's a failure of the frameworks we've inherited. TOGAF, Zachman, the whole BDAT lineage, all built on a quiet assumption that the thing you're architecting will eventually stop changing long enough for you to finish the diagram. Agentic systems don't rest. The model gets retrained. A new tool joins the registry. A planning pattern that worked last quarter is quietly replaced by a reflection loop. There isn't a to-be state. There's just what's running right now, and how fast it's changing underneath you.

That isn't really an engineering problem. It's a framework problem. The frameworks we have were built to describe systems that hold still. The systems we now run, don't.

Why Pace Layering Is the Right Foundation

In 1994, Stewart Brand published a book about buildings that reads today like a manifesto for AI infrastructure. He noticed buildings aren't single artifacts; they're six layers evolving at radically different speeds (Site, Structure, Skin, Services, Space Plan, Stuff) running from geological time down to days. His central point was that robust buildings let fast layers change without disturbing slow ones. When you hang a painting, you don't crack the foundation.

Brittle buildings ignore that separation, and every change cascades. This is roughly what happens when you try to govern agentic AI with classical EA. A prompt tweak wants an architecture review. A new tool wants a twelve-month integration programme. Meanwhile the technology moves in weeks, and the gap between governance cadence and technology cadence keeps widening until someone ships around it.

The fix isn't a better target architecture. It's separating layers by the speed at which they legitimately change, and making the boundaries between them into contracts rather than entanglements. That principle is what the rest of this post extends.

Several Teams Are Arriving Here Already

A field is forming around this problem. Pace-layering for AI is established. Runtime governance for agentic systems is established. What I want to add is the join between them. That join is the part the field has not yet drawn deliberately.

Pace-layering for AI is established. Sean J. Savage's AI Pace Layers (October 2025) extended Brand's framework directly into AI product design. Runtime governance is established too. MI9, an arXiv paper from researchers at Barclays, formalises agentic runtime governance into six coordinated mechanisms with all the rigour you would want from peer work in this space. And Gartner's older Pace-Layered Application Strategy named the underlying principle for traditional enterprise applications more than a decade ago, which is part of why the seam matters: this isn't a brand-new vocabulary on the EA side either.

So a rough consensus is taking shape. Pace-layering for AI is settled. Runtime governance is settled. Continuous evaluation as a first-class layer is becoming settled, at least in principle. What is not settled, and what I want to spend the rest of this post on, is the seam where this emerging substrate meets the classical enterprise architecture disciplines we already have.

Six Layers, Six Cadences

Here is the layered model I have found most useful for thinking about agentic systems in an enterprise context. It is a synthesis, not an invention. Each layer has its own cadence, change cycle, and governance posture. Slower layers set the constraints for faster ones. Faster layers cannot reach down and rewrite the substrate. That last rule is the one that matters most.

If I'm honest about where this is still rough, it's L5. Evaluation and telemetry is easy to describe as a layer and much harder to operate. Most teams resource it like MLOps plumbing, when what it really needs to be is a runtime layer with the authority to gate promotions across every other layer. The industry doesn't have a clean pattern for this yet.

Fast Layers Cannot Break Slow Layers

One rule makes the layered model work, and one rule quietly breaks it when you're not paying attention:

A prompt rewrite at L4 cannot bypass a tool-scope constraint at L2, just as a new cognitive pattern at L3 cannot override the constitution at L0, or a shiny new model at L4 quietly escalate its own delegation scope at L1. Every layer exposes a versioned contract upward and consumes versioned contracts downward. When those contracts are honoured, the fast layers iterate freely. When they're not, something in the bank ends up emailing the CFO.

I keep coming back to this as the single decision that separates systems you can actually operate from systems that turn into governance wreckage by week six.

Four Operating Principles

Pace layers describe the structure. These four describe how you actually change things without breaking them.

• Contract-First, Implementation-Volatile

  Interfaces between layers are stable and versioned. Everything behind them can be replaced on a Tuesday.
• Shadow-Before-Promote

  New models, new tools, and new cognitive patterns run in parallel against real traffic, evaluated by L5, before they replace anything in production. Promotion becomes a gated event, not a deploy. It's the only honest answer to "how do we know the new model is better?" that I've seen actually work in a regulated environment.
• Reversibility by Default

  This is the one I get the most pushback on, and I've come to think the pushback is wrong. Every promotion carries a pinned rollback. Irreversible real-world actions, the payments and outbound emails and production writes, require human confirmation regardless of the agent's nominal autonomy tier.
  
  The argument against is always some version of "but then we don't have real autonomy." I don't agree. You don't get to call it autonomy if the thing can take actions you can't undo. You can't roll back an outbound SWIFT message, so you don't let the agent send one unsupervised. That isn't a limitation; it's a feature. I'd rather have a slightly less autonomous agent that a regulator will let you run in production than a more autonomous one that lives in a demo for three years waiting for risk to sign off.
• Runtime Introspection

  Agents can query their own architecture at runtime: which tools exist, what authority they hold, what's been deprecated. The framework has to be machine-readable by the thing it governs, which is a constraint most framework authors don't think about until late.

The Seam Is Where the Real Work Lives

Here is what the prior art does well, and where I think it leaves work undone. The pace-layered writing treats the agentic stack mostly in isolation. The runtime-governance writing treats the agent population mostly in isolation. Both bodies of work are necessary. Neither addresses the structurally hardest problem: the interface between the agentic substrate and the rest of the enterprise.

That interface is what I call the seam. It is where your agent's identity meets your IAM. Where its tool registry meets your service catalog. Where its data access meets your data product contracts. Where its audit trail meets your existing observability stack. Where its deployment promotions meet your change advisory board. Every one of those crossings is a contract. In the enterprises I've worked with, most of them are currently held together by careful people doing careful manual work, and most have not even been named yet inside the organisations operating them.

The reason the seam is hard is the asymmetry. On the classical EA side you have decades of vocabulary, governance maturity, audit muscle memory, and stable contracts versioned by project. The cadence is annual. On the agentic side you have weekly prompt revisions, monthly cognitive pattern shifts, and the constant background drift of model providers. The two sides do not share a clock. So when an agent calls a system of record, writes to a regulated data store, or revokes its own delegation, the contract governing that crossing has to absorb the velocity mismatch on its own. That is what designing the seam actually means.

For what it's worth, I've taken to calling this pattern the Substrate-Enterprise Agentic Model, or SEAM¹. The substrate is the agentic layer running at its own cadence. The enterprise architecture is what you already have: TOGAF or Zachman, the data estate, the identity fabric, the change advisory board. The model is the contract surface that connects them, sized to absorb the velocity mismatch without either side breaking the other.

This is where the conversation I opened with actually landed. That team had a solid substrate, a mature identity fabric, and capable agentic systems sitting on top. What they did not have was a deliberate design for the seam between them. The contract surface had grown organically, decision by decision, held together by the engineers who happened to be in the room when each crossing was first made. That is where most enterprises are right now, and it is where the existing frameworks leave you. Each is doing useful work on one side or the other. None are doing the join.

The most interesting architectural work I have seen in a decade is happening at this seam, and almost nobody is resourcing for it deliberately. If your enterprise is building agentic systems on top of a mature classical estate, the seam is the work.

If You're Building This Today

A few takeaways, depending on where you sit.

If you're a CIO or CTO: stop asking for a to-be architecture for your agentic estate. Ask instead what your agentic layers are, what the contracts between them look like, and what the contracts at the seam to your existing classical estate are. If you can't answer all three, you don't have an architecture. You have a collection of demos that work on a good day.

If you're an enterprise architect: your TOGAF and Zachman muscles are not obsolete. They handle half of the problem. The other half is a runtime architecture that evolves faster than your governance board meets, and your real job is to design the seam between the two. It's the most interesting architectural work I've seen in a decade.

If you're a platform engineer: L5 is the work. Evaluation, telemetry, reasoning-trace capture, drift detection. It sounds like MLOps and gets funded like MLOps. It is neither. It's the layer that makes every other layer's velocity possible, and if you don't build it first, every promotion becomes a gamble you can't quantify.

I should be honest about what's still rough. The contracts at the seam will change as MCP matures and as the AI-specific regulation now piling up actually lands. The shape of L5 inside the agentic stack will likely look different in a year. The whole synthesis assumes your organisation can operate a continuous-evolution discipline without the governance process collapsing back into a waterfall, which is not a safe assumption everywhere. But it is where I've landed for now, and I'd rather put it out and be argued with than sit on it.

If you have built something at the seam, or tried to and hit a wall, I'd genuinely like to hear about it.