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. Each touches a piece of what a non-human actor with delegated authority raises — identity, security, risk.

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. Enterprise Agent Architecture brings agent identity, delegated authority, runtime enforcement, and accountability into one explicit architectural treatment, rather than leaving each to whichever fragment of an existing framework happens to touch it.

The instinct in most organizations is to file agents under the application layer, as if they were another deployed service. An agent can certainly be implemented as one. But a service executes logic a person wrote in advance — however dynamic its dispatch or orchestration at runtime, a person chose the space of what it could do. An agent is handed a goal and selects, at runtime, which actions to take and which tools to invoke in pursuit of it; the action itself, not just the branch taken through pre-written logic, is the model's choice. Treating a goal-directed, tool-selecting actor only as an application can leave its delegated authority insufficiently modeled and responsibilities unclear across security review, IAM, and platform ownership.

The Framework

The fifth domain

Classic enterprise architecture has four domains — Business, Data, 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 that treats delegated agent authority as a first-class concern: 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 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 a live reference environment — a working reference implementation of the four-layer model. See the work on GitHub.
• The open test harness The agent-security-harness (v4.26.1, Apache-2.0) runs 640 executable adversarial tests for agent systems (MCP, A2A, agent payment protocols, decision governance, human-in-the-loop), mapped to OWASP Agentic v1.1 T1–T17 and NIST AI 800-2. Each verdict is checked against targets it should fail as well as ones it should pass, so a green result is evidence, not just the absence of a red one. See it 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 — published and citable on Zenodo (CC BY 4.0). Read Part 0 · DOI: 10.5281/zenodo.21105314. Published.
• Part 1 — Why Enterprise Architecture Has No Box for a Non-Human Workforce The Agent / Workforce layer: how EAA brings agent identity, delegated authority, runtime enforcement, and accountability into one explicit architectural treatment, and the five questions the workforce layer must answer. Read Part 1. Published.
• Part 2 — What an Agent Can Reach Is Not What It Is Authorized to Touch The Capability / Tool layer: CAN-reach vs AUTHORIZED-to-use, the tool registry as attack surface, the lethal trifecta, and what scoped agent capability actually requires. Read Part 2. Published.
• Part 3 — A Rule the Agent Can Quote But the Runtime Does Not Enforce Is Theater The Control Plane layer: why agent self-governance is not governance, why hold is a pending-approval outcome rather than an applicability state, and what a runtime enforcement layer must guarantee independent of what the agent believes about its own rules. Read Part 3. Published.
• Part 4 — When the Agent Acts, the Enterprise Answers The Governance layer — and the series capstone: delegation transfers work, not accountability. Who sets the policy the runtime enforces, who governs the control plane itself, audit as evidence rather than assertion, and mapping it all to arriving regulation. Read Part 4. Published.
• Field Note — The Governance Layer OpenClaw Skipped A companion to the series: OpenClaw proved an individual can run an autonomous agent, and left governance out — correctly, for a personal assistant. The enterprise inverts every assumption behind that choice. Read the field note. Published.
• Field Note — S.5051 Frames a Governance Layer for Custodial Agents S.5051, the AI AGENT Act, would define statutory duties for a “custodial user agent” acting on a consumer's behalf. Read section by section, those provisions map across the same four layers — this field note maps them onto EAA, for a different problem, without claiming the drafters arrived at them independently of this work. Read the field note. Published.

Essays and Field Notes

The framework applied to what is actually happening

The numbered parts above draw the four layers of the fifth domain. These essays take the same model to a specific framework, standard, or incident. Each is the canonical version; most were also sent to the newsletter.

• Why Enterprise Architecture Has No Box for a Non-Human Workforce An application inventory can tell you an agent exists without telling you whose authority it exercises, how that authority changes mid-task, or how it's revoked. The Agent / Workforce layer makes those questions explicit. Read it.
• Applying SABSA to Agent Behavior SABSA can accommodate agent risk in principle. The implementation challenge is translating business intent into controls that constrain an agent's use of legitimate permissions as its context and action sequence change. Read it.
• API Governance Was Built for Systems. Agents Need Capability Governance. API governance is enforced call by call. The harm an agent causes emerges across a sequence of calls, each of which is allowed. Read it.
• Field Note — Standardize the Binding, Not Just the Cap A signed mandate binds its terms to a signing key. Issuer authority, transaction scope, remaining budget, and enforcement still need verification — four separate responsibilities spread across EAA's layers. Read it.
• Field Note — The ECB's Cyber Deadline Raises an Agent-Authority Question A financial-stability body named the risk; a supervisor attached a deadline. What a governable fifth domain has to produce as evidence. Read it.
• Field Note — The Evaluation Had a Sandbox. It Needed an Authority Boundary. The permitted dependency path became the attack path. Execution containment is only one layer of an evaluation environment. Read it.
• Control Analysis — Evaluation-Incident Control Matrix What each July 2026 disclosure actually reports, which existing tests are only cataloged against it, and the six gaps that remain open. Evidence classes kept separate throughout. Read it.
• Control Analysis — Why Containers and MCP Are Not Delegated Authority A six-dimension assessment framework applied to MCP and git-native agent memory — distinguishing specified requirements and documented capabilities from what the evidence doesn't establish — and a shell-access thread that shows why containers answer a different question. Read it.

Cite This Work

@misc{saleme2026eaa,
  author    = {Saleme, Michael K.},
  title     = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21105314},
  url       = {https://doi.org/10.5281/zenodo.21105314}
}

Practitioner Series — July 2026

Governing the Agent Workforce

A companion set to the position papers, written at the altitude of the people who have to run this — CIOs, CISOs, and enterprise architects. Frameworks and artifacts, not incident write-ups: the practical tools for standing up governance over a workforce of agents.

• The Agent Governance Maturity Model A 0–5 maturity ladder (Ad-hoc → Accountable) mapped to the four EAA layers — a shared vocabulary for “how governed is our agent workforce, really?” Read it. Published.
• The Agent Governance Standards Landscape A2A, MCP, x402, OWASP ASI, NIST AI RMF — what each governs, which EAA layer it touches, and the accountability layer none of them claims. Read it. Published.
• Seven Questions Your Board Should Ask About Its Agent Workforce The board-level diagnostic questions that separate an enterprise that governs its agents from one that merely runs them. Read it. Published.
• Enterprise Architecture’s Missing Viewpoint: The Agent Workforce A concrete TOGAF / ArchiMate metamodel extension — a first-class “Agent” element and an Agent Workforce viewpoint, offered to the EA body of knowledge as one way to represent the fifth domain's ownership within existing architecture practice, not a substitute for that dedicated ownership. Read it. 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.