Enterprise Agent Architecture

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

Agents are not a new application tier. They are a new class of actor — a digital workforce that holds delegated authority, acts autonomously, and composes tools on its own. Most enterprises are deploying that workforce into production with no architecture for it.

Michael Saleme — Enterprise Agent Architect

Read the framework Assess your readiness

A reference model for governing a workforce of humans and agents — grounded in a system running in production.

The fifth domain
The white space

Every framework models what the enterprise builds. None models the actor.

A category no established architecture practice has ever had to claim — until now.

TOGAF gives us domains and a 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. Each is mature, each is rigorous, and each answers a version of the same question: how do we describe what the organization builds and runs so we can govern it deliberately?

Every one of them models the same subject — the systems, data, processes, and technology the enterprise builds and operates. 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. Filing it under the application layer is a category error: a service does what it is told, an agent decides what to do. The domain that should own it is unclaimed. Enterprise Agent Architecture is the discipline that claims it.

The reference model

The fifth domain, described at four altitudes.

EAA does not replace the classic spine of enterprise architecture. It extends it with the one domain the others never needed: the agent workforce itself.

Business Information Application Technology Security (cross-cut) + Agent Workforce
1

Agent / Workforce

What agents exist, what roles they hold, what authority is delegated to them, and how they are provisioned, rotated, and retired across a lifecycle.

2

Capability / Tool

What each agent is actually allowed to touch — the tools, APIs, and data it can reach, scoped to least privilege. The tool registry is the attack surface.

3

Control Plane

Where written policy meets running behavior — the enforcement point that allows, denies, or contains an action at the moment it is attempted.

4

Governance

Who owns the agent workforce, who audits it, and who is accountable when an autonomous actor acts. The questions every architect already knows how to ask — now of a worker that happens to be software.

See the full reference model
Proof

Evidence, not theory.

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

Reference implementation

HRAO-E — a live, fully-governed autonomous organization

A workforce of autonomous agents runs in production under a written constitution, a six-gate architecture, delegated authority, and audit trails — a working instance of the four-layer model, not a diagram of one.

See the work on GitHub →
The runtime primitive

constitutional-agent on PyPI (v0.5.0)

The control-plane primitive extracted from that system — policy enforced at runtime, not documented and hoped for. Demand is real and growing: roughly 100+ installs per month and climbing, with zero marketing behind it.

View the package on PyPI →
The research trail

A traceable body of work

A 474-test agent-security harness across 33 modules, five published DOIs, and three NIST submissions. Open and falsifiable: artifacts you can read, install, and run.

Follow the trail on GitHub →
Who

Why this practice, from this architect.

Michael Saleme — Enterprise Agent Architect

Thirty years architecting enterprise systems across Oil & Gas, Energy and Utilities, and Consumer Packaged Goods. The recurring work has always been the same four concerns: identity, integration, authorization, and control — establishing who an actor is, connecting it to the systems it needs, deciding what it is permitted to do, and constraining it when it acts.

An autonomous agent raises those exact four questions a new integration user, service account, or B2B partner connection always has — only now the actor reasons, composes tools, and acts on its own. The principles transfer; the actor is new.

Agent governance is enterprise architecture applied to a new substrate — the same discipline, three decades deep, now on the newest layer.

The series

The Case for a Fifth Domain

An eight-part body of work at architect altitude — a position paper and the chapters that build on it, compounding toward a contribution to The Open Group and the Cloud Security Alliance.

Part 0 The Case for a Fifth Domain — the position paper Published
Part 1 Why an Agent Is Not an Application — the category error Coming
Part 2 The Agent / Workforce Layer — identity and delegated authority Coming
Part 3 The Capability / Tool Layer — the tool registry is the attack surface Coming
Part 4 The Control Plane — where policy meets runtime, and the N/A third state Coming
Part 5 The Governance Layer — ownership, audit, and accountability for a non-human actor Coming
Part 6 Mapping EAA Onto TOGAF, Zachman, and SABSA — extending, not replacing Coming
Part 7 A Maturity Model for the Fifth Domain — from ad hoc to governed Coming
Start with the position paper

Assess your enterprise's agent-governance maturity.

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.

Take the governance stress test Read the framework