Enterprise Agent Architecture | Cognitive Thought Engine

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.

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

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:

Layer	The question it answers	Evidence base
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.	Trust-boundary research
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."
Control Plane	Where written policy meets running behavior — the enforcement point that allows, denies, or contains an action at the moment it is attempted.	Containment over capability; the N/A third state.
Governance	Who owns the agent workforce, who audits it, and who is accountable when an autonomous actor acts.	Constitutional governance framework.

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

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.

Agent governance is not a departure from that work. It is that exact discipline applied to a new substrate. An autonomous agent raises the same 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.

Enterprise Agent Architecture is what you get when three decades of identity, integration, and authorization architecture meet the newest layer of the enterprise: a workforce that isn't human.

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.

An enterprise agent-governance-maturity self-assessment is in production. In the interim, the governance stress test surfaces where your fifth domain stands today.

Take the Governance Stress Test Read the Series