EAA Knowledge Index

A reference model that treats the autonomous agent workforce as enterprise architecture's fifth domain. EAA gives architects a common structure for reasoning about agents the way they already reason about business, data, application, and technology — organized into four layers, from the agents themselves down to the written governance that constrains them.

The autonomous agent workforce positioned as a new domain of enterprise architecture, alongside the four classical TOGAF-style domains (business, data, application, technology). Agents are neither pure application nor pure workforce; treating them as their own domain gives them a first-class place in architecture decisions instead of an afterthought bolted onto existing systems.

The layered structure of the agent workforce. Agent / Workforce — the autonomous actors and their roles. Capability / Tool — what each agent is allowed to call, including the MCP tool-authority boundary. Control Plane — the runtime that enforces policy on every action as it happens. Governance — the written rules, gates, hard constraints, and amendment process the whole workforce answers to.

Three distinct governance concerns that are routinely conflated. WHO an agent is — identity, authentication, delegated credentials. HOW it is allowed to behave — runtime filtering, trust scoring, output controls. WHY it may act at all — constitutional authority over its decisions. Most of the market covers WHO and HOW; the WHY layer is the open gap EAA names and fills.

A sequential evaluation pipeline every agent action passes through: epistemic (guards against false certainty), risk (guards trust), governance (guards against gaming), economic (guards sustainability), autonomy (ensures the system keeps operating), and constitutional (ensures the rules can improve). Sequencing the gates keeps a single bad decision from compounding into a system-level failure.

Absolute prohibitions enforced at the architecture level rather than described in a policy document. A policy says an agent should not do something; a hard constraint makes the action structurally impossible. The difference determines whether a governance layer prevents incidents or merely records them after the fact.

The evaluation of accumulated risk across individually authorized actions. Each step may be permitted in isolation while the composed sequence — assembled across sessions — is not. This is the authorized-action gap: an agent that is authorized for every move can still compose those moves into an outcome no one authorized.

The space between "the agent was authorized" and "the action should have happened." Access control answers who may enter; behavioral security answers how a request is shaped; neither answers whether an authorized agent should compose a particular sequence of permitted actions. Refusing on that basis — authorized but refused — is a governance decision, not an access decision.

Vendor-neutral, execution-time governance of what autonomous agents decide and do. The three incumbent control planes govern identity and access; decision governance sits in the white space — at the moment of action — deciding whether a permitted step should actually be taken given everything that came before it.

The runtime layer that enforces policy on every agent action as it happens, rather than reviewing behavior after the fact. In EAA the control plane is where governance stops being documentation and becomes enforcement — the point at which a rule either blocks an action or does not.

The line between what an agent is capable of calling and what it is authorized to call. Model Context Protocol makes tool access easy to grant; the boundary question — which tools, under which conditions, composed in which sequences — is a capability-layer governance concern, not a connectivity concern.

Adversarial testing of agent behavior against known failure classes — prompt injection, tool misuse, privilege escalation, autonomous persistence. It characterizes how an agent responds under attack; it is a reference implementation of the testing discipline, not a certification.

The open-source Python primitive for the WHY layer — six gates, hard constraints, and a formal amendment process — that enforces constitutional authority at runtime rather than describing it in a policy. It is the control-plane primitive extracted from the reference implementation running in production.

A Fundamental Rights Impact Assessment (FRIA) is required under Article 27 of the EU AI Act for certain high-risk deployments. Execution-time decision governance — gates, hard constraints, and audit trails — produces the behavioral evidence a FRIA needs. This is support material and characterization, not a certification of compliance.

The autonomous actors themselves — their roles, responsibilities, and delegated authority. This layer answers who is in the workforce and what each agent is accountable for, the way an org chart answers it for people.

What each agent is allowed to call — APIs, tools, data, and the MCP tool-authority boundary. Capability is not the same as permission; this layer governs which capabilities may be exercised, under which conditions, and in which combinations.

The runtime that enforces policy at the moment of action. Every agent decision passes through it; this is where the six gates and hard constraints actually block or permit, rather than being reviewed after the fact.

The written rules the whole workforce answers to — the constitution, hard constraints, and the formal amendment process that lets the rules improve without abandoning them. This is the WHY layer: the source of an agent's authority to act at all.