Your Architecture Diagrams Are Missing the Most Important Actor

How do you draw a diagram for a component that exercises judgement?

I raised it at the end of the last post and didn't answer it , because I didn't have a clean answer yet. What I had was a growing sense that the diagram problem wasn't really about diagrams. It was about something more fundamental shifting in how architecture works when the system starts making decisions rather than following instructions.

Then I watched a vendor demo of an AI-assisted case management product. Slick presentation. The workflow looked clean — intake, agent processing, case officer review, resolution. Someone on the call asked the question I'd been circling: if the agent recommends an action the case officer disagrees with, what happens?

"The case officer overrides it," the presenter said. Confident. Reasonable answer. The demo moved on. But my thinking didn't.

Because the follow-up never came , not from anyone on the call, not from the presenter. What if the case officer isn't available? I sat with that quietly for the rest of the session. The product was polished and yet the most important design question had just passed by unanswered, what does the agent do in the space between its recommendation and a human decision? Who designed that space? What are its walls?

That's the question traditional architecture wasn't built to answer.

Why the Diagram Can't Capture What Matters

Enterprise architecture, at its best, is about making the invisible visible. You draw the map so the organisation can navigate. Boundaries between systems. Data flows. Integration points. Responsibilities. The diagram is a contract — here is what the system does, here is where it ends, here is how you reason about it when something goes wrong.

That contract holds when the system is deterministic. Given the same input, it produces the same output. A bug is a bug — something broke, you find it, you fix it. The diagram is a reliable map of production behaviour.

Agents break all three assumptions.

The same input can produce different outputs, depending on context the diagram doesn't represent. There is no single "bug" when an agent starts drifting toward behaviour you didn't intend — it degrades gradually, often invisibly. And the diagram can be technically accurate while completely failing to capture what the system is actually doing in production, because what it's doing depends on decisions being made at runtime that no one specified at design time.

This isn't a failure of the agent. It's a failure of fit. The tools we reach for when we think "architecture" were built for a world where the system follows the script. Agents don't follow scripts. They exercise judgement. And the architecture discipline hasn't fully caught up with what that requires.

The Shift: From Organised Change to Bounded Emergence

Here's the reframe that changed how I approach these engagements.

Traditional EA governs organised change You define the target state, map the path to get there, identify the risks along the route. The system moves from A to B according to a plan. Your job is to make sure the plan is sound and the transition is controlled.

Agentic EA governs bounded emergence The system doesn't move from A to B. It operates continuously, making real-time decisions within a space you've defined. The responsibility of the architect is not to plan the path , it's to define the walls. What is this agent allowed to decide? What is outside its authority? What constitutes a decision that requires escalation? What evidence do I have that the agent acted within its mandate?

Those are different architecture problems. One is about designing a system. The other is about designing an environment for an actor that has its own behaviour.

The practical consequence: in a traditional design review, you're asking "does this system do what we want?" In an agentic design review, you're asking "have we defined what this agent is authorised to do, and can we prove it stayed within that?" The second question requires things the first one never needed — explicit authority models, runtime audit capability, escalation paths that weren't the result of a failure but a designed feature of normal operation.

The case management example: the workflow diagram told us what happened to a case when the agent was confident. It told us nothing about what happened when it wasn't. That gap — the undesigned space between "agent acts" and "agent stops" — is where agentic systems fail in production. Not with a crash. With a slow drift into behaviour nobody intended.

The Seven Primitives — A Constitutional Physics for Agents

I came across a framing in my KB research that I keep returning to for this: constitutional physics — the idea that governing agents requires something closer to a constitution than a policy document. Not rules about what to do in known situations, but structural principles that hold regardless of what situation the agent encounters.

This framing draws on work by enterprise AI practitioners thinking about what governance actually means when the governed party is making its own decisions. Seven primitives, each of which needs to be explicitly designed rather than assumed:

Intent — What is the agent actually trying to achieve? Not the task it's been given. The goal it's optimising toward. In the case management example, is the agent trying to resolve cases faster, or correctly, or both? When those conflict, which wins? If you can't answer that question in one sentence, the agent's intent hasn't been designed — it's been assumed.

Authority — What is this agent legally and organisationally permitted to do? Not "what can it technically do," which is a capability question. What has it been authorised to do, by whom, in what context? The distinction matters because agents will reach the edge of their authority in ways you didn't design for. If authority hasn't been explicitly bounded, the agent will operate in that gap without knowing it's a gap.

Policy — What constraints must it obey regardless of its goal? This is where regulatory requirements, risk thresholds, and ethical guardrails live. The difference between policy and instruction: policy holds even when following it conflicts with achieving the goal. If your agent will sacrifice a policy constraint to complete a task, you haven't designed a policy — you've designed a preference.

Scope — What is the boundary of the agent's influence? What systems can it read? What can it write? What can it trigger? Scope defined too loosely is a security and liability problem. Scope defined too tightly produces an agent that can't do the job. The right scope is defined by the authority and policy together, not by what the engineers found convenient to expose.

Meaning — Do all parts of the system share the same understanding of the concepts the agent is working with? In the case management context: does "high risk" mean the same thing to the agent as it does to the case officer as it does to the compliance team as it does to the downstream reporting system? Semantic drift between agents in a multi-agent system is one of the most common failure modes nobody designed for.

Proof — Can you replay what the agent decided, why it decided it, and what authority it used? Not logs. Forensic records. The standard for proof in an agentic system is closer to the legal standard than the engineering standard — you need to be able to demonstrate, to a regulator or an auditor, that the agent acted within its mandate and that you can show your working. Most enterprise AI deployments I've reviewed couldn't do this on day one.

Effects — Have you measured the impact of the action before releasing it? Especially for irreversible decisions. The discipline of staging effects — computing what will change before committing it — is something most engineering teams understand conceptually and don't build by default.

None of these primitives are new to architecture. Authority models, audit trails, scope boundaries — we've always needed them. What's different is that in a deterministic system, these were implicit in the design. A system that follows a script can't exceed its authority because it can't act outside the script. An agent can. Which means every one of these primitives has to be explicit — designed, tested, and verified — rather than assumed.

The Two-Layer Enterprise

Here's how I've started thinking about the architecture landscape as a result of all this.

TOGAF, and traditional EA more broadly — doesn't go away. The vast majority of enterprise capability is still deterministic. Core systems, integration layers, data pipelines, reporting infrastructure. These are governed by capability mapping, portfolio prioritisation, business alignment. The existing discipline applies and it's still valuable.

But there's now a layer on top of that. An Agency Layer. Everything in the enterprise that exercises judgement rather than following a script. Agents, copilots, AI-assisted workflows where the AI is making a call rather than executing a rule. This layer needs the seven primitives. It needs runtime governance — not review boards, which are too slow for systems making millisecond decisions, but a governance spine embedded in the infrastructure itself. Policies enforced at the speed of the agent's decision cycle, not at the speed of a quarterly architecture review.

The practical implication for any design review: you need to know which layer a component lives in before you know how to govern it. A document classifier that routes with 95% confidence to one of five categories is still deterministic enough for traditional governance. An agent that reads a case, weighs ambiguous context, and decides on the next action is not. Treating them the same way is where most enterprise AI governance failures start.

The case management diagram I was reviewing had components in both layers. The mistake wasn't that the team hadn't built the agent well. The mistake was that the Agency Layer components were being governed with Layer 1 tools — a design document, a test plan, an approval process that happened once before deployment. That's not sufficient for something whose behaviour continues to emerge after it goes live.

What Changes in Practice

A design review for an agentic system looks different now than it used to.

I'm asking questions the review process never needed before: What is this agent authorised to decide, and by whom? What does the audit trail look like for a decision the agent gets wrong six months into production? If the agent's confidence degrades — because the data it's operating on starts to drift from its training distribution — how will we know, and what's the designed response? What's the escalation path for a decision that's at the edge of the agent's scope, and is that path a failure mode or a feature?

In a vendor PoC, I'm looking for something the demo never used to need to show me: not just that the agent produces the right output in the happy path, but that I can interrogate how it made the decision, that I can define the boundaries of its authority and have them enforced, and that it degrades gracefully when it hits the edge of its competence rather than proceeding confidently into terrain it wasn't designed for.

These aren't exotic requirements. They're what production-grade systems have always needed. Agents just make them harder to assume and easier to skip.

The diagram problem from that design review has a partial solution now. Not "add more boxes." Add a different kind of representation — one that shows not just what the agent does, but what it's allowed to decide, what it defers, and what evidence it produces of having stayed within its mandate. That's not a technical diagram. It's a constitutional document. It just happens to live in the same repository as the architecture.

---

The next question in this series is the one that follows naturally from this: if every agent needs this kind of constitutional design, and your organisation is deploying dozens of them — through Copilot Studio, through vendor platforms, through internal teams who found a low-code tool and ran with it — how do you govern the fleet, not just the individual? That's the portfolio problem. And it's coming faster than most governance teams are ready for.