Enterprise Architecture Has Four Domains. Agentic Enterprises Need a Fifth.

The White Space

Every mature enterprise architecture framework answers a version of the same question: how do we describe what the organization builds and operates so we can govern it deliberately? TOGAF gives us domains and an architecture development method. Zachman gives us a classification grid. FEAF gives the public sector a reference model. SABSA gives security a layered, business-driven structure. COBIT governs IT. NIST frames risk and control.

Every one of them models the same subject: the systems, data, processes, and technology the enterprise builds and runs. Not one of them models a non-human actor that holds delegated authority and acts on its own.

That actor now exists in production. An agent is given credentials, granted scopes, handed a goal, and left to decide which tools to call and in what order — at machine speed, without a human in the loop on every step. No established framework has a domain for it. The category is unclaimed. Enterprise Agent Architecture is the discipline that claims it.

The instinct in most organizations is to file agents under the application layer, as if they were another deployed service. They are not. A service does what it is told; an agent decides what to do. A service has a fixed call graph; an agent assembles its own at runtime. Treating a decision-making, tool-composing actor as an application is a category error — and it is the reason agent incidents land in the gaps between security review, IAM, and platform ownership, where no single framework was ever responsible for them.

The Framework

The fifth domain

Classic enterprise architecture has four domains — Business, Information, Application, and Technology — with Security running across all of them as a cross-cut. EAA does not replace that spine. It extends it. It adds the one domain the others never needed: the agent workforce itself.

The fifth domain is not a single layer. A workforce of autonomous actors has to be described at four altitudes — from the agents themselves, down through what they can touch, to where policy is enforced at runtime, up to who is accountable for the whole. EAA structures the fifth domain in these four layers:

Read top to bottom, the four layers answer a single chain of questions every architect already knows how to ask of people and systems: who is this actor, what can it touch, what stops it in the moment, and who answers for it. EAA simply asks them of a worker that happens to be software.

Why This Practice, From This Architect

Evidence, Not Theory

The framework is not a whitepaper waiting for a reference implementation. The reference implementation came first, and the framework is the account of what it took to make it work.

• A live, fully-governed autonomous organization HRAO-E runs a workforce of autonomous agents under a written constitution, with gate enforcement, delegated authority, and audit trails operating in production — a working reference implementation of the four-layer model. See the work on GitHub.
• The runtime-enforcement primitive The constitutional-agent package on PyPI is the control-plane primitive extracted from that system — policy enforced at runtime, not documented and hoped for. View the package on PyPI.
• The full body of work, and where to start Published research, the runtime, and the governance framework are open and traceable. Start at the GitHub profile and start-here repo to follow the thesis end to end.

Each of these is a falsifiable artifact you can read, install, and run. That is the standard the practice holds itself to: evidence over assertion.

Where To Begin

The first architectural question for any agentic enterprise is not which model to deploy. It is: do you know what your agents are, what they can touch, what stops them at runtime, and who answers for them? Most organizations cannot yet answer all four. Knowing which layer is weakest is where the work starts.

The Series

The canonical write-up, published part by part

Enterprise Agent Architecture is being published as a position-paper series — the canonical account of the practice, released one part at a time. Part 0 lays out the thesis: why agents are a fifth domain, not an application tier. Parts 1–4 take each layer in turn.

• Part 0 — Enterprise Architecture Has Four Domains. The Agentic Enterprise Needs a Fifth. The position paper. Read Part 0 on Substack. Published.
• Part 1 — Why Enterprise Architecture Has No Box for a Non-Human Workforce The Agent / Workforce layer: why TOGAF, Zachman, and SABSA can't model a delegated non-human actor, and the five questions the workforce layer must answer. Read Part 1. Published.
• Parts 2–4 — Capability, Control Plane, Governance Forthcoming — one part for each remaining layer. Subscribe on Substack to follow as each is published.

The Evidence Base

Field research behind each layer

EAA is not theoretical. Each layer of the fifth domain is grounded in published agent-security field research — disclosures, test harnesses, and incident analysis. The work below is organized under the four layers it informs.