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 — what each can decide, and who owns it. No framework answers that. That blank is the subject of this layer.
You can produce, on demand, a complete inventory of what your enterprise builds and runs. You cannot produce an inventory of the agents now acting inside it. That gap is not an oversight. No framework you use was built to close it.
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 Information 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. The agents are running — calling tools, composing actions, making decisions at machine speed — but the architecture has no row for them. That blank row is the subject of this layer, and the reason it stays blank is more interesting than the blank itself.
A Category Error, Not a Coverage Gap
The blank is not there because the frameworks are immature. It is there because of what the frameworks were built to describe. TOGAF's four domains — Business, Application, Information, Technology — all model 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 not that. An agent is an actor you delegate authority to. You hand it credentials, scope what it may do, give it a goal, and let it decide. That is not the relationship you have with an application. It is the relationship you have with an employee. You do not architect an employee as a Technology component — you onboard them, scope their authority, supervise them, and can revoke their access. The agent belongs in the same conceptual bucket as the worker, not the workstation.
Look across the other frameworks and the same wall appears. Zachman's grid has a "Who" column — but it was drawn for human actors and human roles; it has no cell for a non-human that reasons and acts on delegated authority. SABSA models the security of systems with great rigor, but it models systems as things to be protected, not as autonomous decision-makers whose own choices are the risk. None of them has a workforce domain, and none of them has a workforce domain for non-humans in particular. The agent falls between the cells. Filing it under "Application" is not a small mislabel — it is a category error that puts an actor where the model expects an artifact.
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 architecture that would describe, scope, and account for them is not.
The workforce is already here. The architecture isn't. 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.
Michael K. Saleme
Enterprise Agent Architect · Cognitive Thought Engine