Why Enterprise Architecture Has No Box for a Non-Human Workforce
The Agent / Workforce layer. You can name every application, datastore, server, and process you own. Now name every autonomous agent acting in your enterprise — whose authority it exercises, how that authority changes mid-task, and how it's revoked. Existing frameworks give you fragments of that answer, not the whole of it. That incomplete treatment is the subject of this layer.
You can produce, on demand, a complete inventory of what your enterprise builds and runs. Producing the same inventory for the agents now acting inside it is harder — not because no framework touches the question, but because none of them was built to answer it completely.
The Blank Row
Walk into any mature enterprise and the architecture is legible. You can name every application in the Application domain, every datastore in the Data domain, every server and runtime in the Technology domain, every process in the Business domain. There is a diagram, a registry, an owner. Three decades of practice have made the enterprise describable.
Then ask one question: List every autonomous agent acting in your enterprise, what each one is empowered to decide, and who owns it.
The room goes quiet. There is no diagram. There is no registry. In most organizations there isn't even agreement on what would go in it. An application inventory can tell you that an agent exists without telling you whose authority it exercises, how that authority changes during a task, or how it can be revoked. The agents are running — calling tools, composing actions, making decisions at machine speed — but the architecture has no row that answers those questions for them. That blank row is the subject of this layer.
Incomplete Treatment, Not a Coverage Gap
The blank isn't there because the frameworks are immature, and it isn't because no framework can represent an agent at all. It's there because of what the frameworks were primarily built to describe. TOGAF's four domains — Business, Data, Application, Technology — are built around artifacts the enterprise builds and owns. An application is something you architect, deploy, and operate. A datastore is something you provision. A server is something you rack. Every one of these is a thing you make and possess.
An agent is also that: it is still a software system, deployed and operated like any other. It is additionally an actor you delegate authority to. You hand it credentials, scope what it may do, give it a goal, and let it decide. That second description is the one existing frameworks treat incompletely. It is closer to the relationship you have with an employee than with a workstation — you onboard them, scope their authority, supervise them, and can revoke their access — and that relationship deserves its own explicit treatment, not just a mention where it happens to surface.
Look across the other frameworks and the same pattern appears. Zachman's grid has a "Who" column that can represent an actor, but it was built around human roles and doesn't natively carry a non-human actor's delegated scope, its mid-task changes, or its revocation. SABSA models the security of systems with real rigor across governance, risk, and lifecycle — but its access-centric implementations are typically built around a set of controls decided at grant time, not one that reasons about an autonomous actor's own behavior, mid-task, as the thing being risk-assessed. Neither gap means the frameworks are silent on agents; it means delegated agent authority isn't a first-class, explicit concern in either one. Filing an agent under "Application" without also giving it this treatment leaves its delegated authority insufficiently modeled — a real gap, but a narrower one than saying no framework can represent it.
A Workforce, Not a Tier
The instinct, once the misfit is felt, is to invent a new tier: an "agent layer" that sits above the application layer in the stack, another box in the integration diagram. This is the same error in a new costume. A fleet of agents calling tools and composing actions is not a tier of infrastructure. It has the properties of a workforce.
It has roles — this agent triages support, that one reconciles invoices, another drafts outreach. It holds delegated authority — each is empowered to decide and act within a scope someone granted. It has a lifecycle — agents are provisioned, they operate, and at some point they must be retired. And it requires accountability — when an autonomous actor acts, a named human or team must answer for it. Roles, delegated authority, lifecycle, accountability: those are the attributes of a workforce, not the attributes of an integration tier.
Treating the workforce as a tier is precisely the mistake that produces the failures below. A tier you stand up and monitor. A workforce you govern.
What the Agent / Workforce Layer Must Answer
If the fifth domain's first layer is a workforce, then it has to answer the questions any HR function answers about its people — only about software actors. Five questions define the layer.
| Question | What the layer must establish |
|---|---|
| Inventory | What agents exist — the complete roster, including the shadow agents in no registry that a team spun up against an API key last quarter. You cannot govern a workforce you cannot enumerate. |
| Identity & provenance | Which agent this is, who authored it, and what model and version it runs on. An action without an identity behind it cannot be attributed, and an actor you cannot attribute you cannot hold to account. |
| Delegated authority | What each agent is empowered to decide and do — the explicit scope of delegation. Not what it technically can reach, but what it has been granted the authority to do. |
| Lifecycle | Provision → operate → revoke. Can you turn an agent off — and can you prove it is off? An agent you cannot decommission with evidence is an actor you have lost control of. |
| Accountability | A named human or team that owns each agent. Every autonomous actor in the enterprise traces to someone who answers for what it does. |
Read together, these five are the contents of the Agent / Workforce layer. An enterprise that can answer all five has an architecture for its non-human workforce. An enterprise that cannot is operating one without one.
The Symptoms Are Already in the Field
This is not a hypothetical gap. The failures that follow from deploying a workforce with no workforce architecture are already documented — in field research, test harnesses, and incident analysis. Each of the findings below is a symptom of the same missing layer.
- Identity that grades its own exam When an agent asserts its own identity and the system trusts the assertion, provenance is theater. Every agent passport layer is grading its own exam.
- Identity is not safe behavior Knowing which agent acted does not tell you whether it was allowed to. Authentication answers identity; it does not answer authority. Authenticated, Authorized, and Still Unsafe: The Missing Layer in Agent Security.
- The trust boundary moved Delegating authority to an autonomous actor relocates the trust boundary — and most teams have not redrawn it. Stop Babysitting What? The Trust Boundary You Just Relocated.
- Measured at scale The boundary failures are not anecdotal. A 332-test harness puts numbers on how consistently agent systems fail where authority is delegated. Agent Systems Are Failing at Trust Boundaries. We Ran 332 Tests to Prove It.
- The maturity models miss the actor axis Agentic maturity models grade capability and autonomy but skip the question this layer exists to ask: who is the actor, and who validated that it is what it claims to be? The Agentic Maturity Model Is Missing an Axis.
Read each one as the same diagnosis from a different angle: a workforce was deployed without a workforce architecture, and the incidents land in the gap.
Already in Production
The reason this matters now, and not in two years, is that the workforce is already on the floor. Enterprises are putting delegated agents into production today. Platform offerings such as Agentforce ship agents into the enterprise as a managed capability; teams elsewhere assemble their own fleets on open frameworks like LangChain, CrewAI, and AutoGen. These are named here only as examples of a pattern that is now general — the point is not any one of them. The point is that across every one of these paths, the same thing is true: the agents are live, and the explicit treatment of their delegated authority — inventory, provenance, scope, lifecycle, accountability — is, in most organizations, still incomplete.
The workforce is already here. The architecture for it is still catching up. That is the gap the Agent / Workforce layer exists to close.
The Bridge to Part 2
Once you can inventory the workforce — who each agent is, what authority it holds, and who answers for it — the next question follows immediately: what may that authority actually touch? Delegated authority is meaningful only against the tools, APIs, and data an agent can reach. That is the Capability / Tool layer, and it is the subject of Part 2.
About This Series
Michael K. Saleme — Enterprise Agent Architect
Enterprise Agent Architecture is published as a position-paper series — the canonical account of the practice, released one part at a time. Part 0 makes the case that agents are a fifth domain of enterprise architecture, not an application tier. Part 1, above, takes the first layer of that domain: the agent workforce itself.
The recurring work of three decades of enterprise architecture has been the same four concerns — identity, integration, authorization, and control. An autonomous agent raises every one of them again, only now the actor reasons and acts on its own. The principles transfer; the actor is new.
Cite the Position Paper
Part 1 develops the Agent / Workforce layer of the Enterprise Agent Architecture position paper, which is published and citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.
Saleme, M. K. (2026). Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise. Zenodo. https://doi.org/10.5281/zenodo.21105314
BibTeX
@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}
}
Michael K. Saleme
Enterprise Agent Architect · Cognitive Thought Engine