Enterprise Architecture's Missing Viewpoint: The Agent Workforce

What the Frameworks Were Built to Describe

Enterprise architecture is, at its core, a discipline of legible inventory. Its frameworks give an organization a shared vocabulary for the components it owns and the relationships between them, so that change can be reasoned about rather than discovered in production. That vocabulary is mature, well-tooled, and, for what it was built to cover, remarkably complete.

It was built to cover artifacts. TOGAF's four architecture domains — Business, Application, Information (Data), and Technology — each catalogue things the enterprise constructs, provisions, and operates. Zachman's grid intersects six interrogatives with six perspectives to describe an enterprise as a designed system. ArchiMate gives that system a precise notation, with active-structure elements that perform behavior and passive-structure elements that behavior acts upon. SABSA layers a security architecture over the whole, from contextual intent down to operational mechanism. Between them, these frameworks can describe almost anything a modern enterprise builds.

An autonomous agent is not something the enterprise builds in that sense. It is something the enterprise delegates authority to. You issue it credentials, scope what it may do, hand it a goal, and let it decide and act within that scope. That is not the relationship an architecture has with an application or a datastore. It is closer to the relationship an organization has with an employee — and none of these frameworks has a first-class construct for that.

Where Each Framework Falls Short — Precisely

The gap is not that the frameworks ignore agents. It is that the nearest existing construct in each is the wrong kind of construct: it was drawn for an artifact, a human, or a protected system, and an agent is none of those. The mismatch is worth stating exactly, because the precision is what makes the extension proposable rather than hand-wavy.

Framework	Closest existing construct	Why it doesn't fit
TOGAF	Application Architecture component (or an Application Service)	The four domains model artifacts the enterprise builds and operates. An agent classified as an application is treated as something you deploy and monitor — not as an actor holding delegated authority to decide. The domain set has no place for a non-human worker.
Zachman	The “Who” column (People / roles & responsibilities)	The “Who” column was drawn for human actors and the roles they hold. It has no cell for a non-human that reasons and acts on delegated authority — the actor is neither a person nor one of the artifacts the other five columns describe.
ArchiMate	Active-structure elements: Business Actor, Business Role, Application Component	Active-structure elements assume either a human actor performing a role or a system component executing designed behavior. A non-human decision-maker that acts under scoped, delegated authority is neither — it exhibits actor-like discretion but is not human, and component-like implementation but is not deterministic.
SABSA	Asset / system to be secured within the layered security architecture	SABSA secures systems as things to protect — assets whose confidentiality, integrity, and availability are the concern. An agent is not primarily a thing to protect; it is an autonomous decider whose own choices are the risk to be governed. The model has no construct for a system that is itself the threat surface it operates.

Read down the third column and the same diagnosis recurs: each framework offers a construct for an artifact the enterprise owns, a human who holds a role, or an asset to defend. None offers a construct for a non-human actor operating under delegated authority. That is the missing element.

The Proposed Extension: An Agent Element and an Agent Workforce Viewpoint

The extension has two parts, and keeping them distinct matters. The first is a new active-structure element — the Agent: a non-human actor that holds delegated authority and acts on its own within a granted scope. It sits alongside the human actor and the system component as a first-class citizen of the metamodel, not as a subtype of either. It behaves like an actor in that it exercises discretion; it behaves like a component in that it is provisioned and versioned; it is fully neither, which is exactly why it needs its own element rather than a stretched interpretation of an existing one.

The second is a new Agent Workforce viewpoint — the coherent set of models an architect assembles to reason about that element. Following the ISO/IEC/IEEE 42010 sense of a viewpoint, it frames a specific set of stakeholder concerns and prescribes the models that address them. Five concerns define it:

Concern the viewpoint frames	What the model must capture
Identity & provenance	Which agent this is, who authored it, and the model and version it runs on — so that an action can be attributed to a specific, known actor rather than an anonymous process.
Delegated authority	The explicit scope of decision-making granted to the agent — what it is empowered to do, expressed as a delegation relationship from a granting authority, distinct from what it merely can reach.
Capability boundary	The tools, APIs, and datasets the agent may actually invoke — the concrete reach that gives the delegated authority its real extent, and the perimeter a containment plan is drawn against.
Lifecycle	Provision → operate → revoke as an explicit, evidenced state model — including the ability to decommission an agent and prove it is off.
Accountability	The named human or team that owns the agent, so that every autonomous actor traces to someone who answers for what it does.

Where does this slot into the metamodel? Not as a new application tier layered above the existing stack. That framing recreates the very error the extension corrects, by treating a set of actors as a slab of infrastructure. The Agent element and its viewpoint constitute a fifth domain of the enterprise — a workforce domain of non-human actors — peer to Business, Application, Information, and Technology rather than stacked on top of them. It is a workforce, not a tier: something the architecture governs, in the way it governs people, not something it merely stands up and observes.

What the Viewpoint Buys the Architect

A viewpoint earns its place in a framework by producing artifacts a stakeholder needs and could not otherwise get. The Agent Workforce viewpoint produces four, and each maps to a governance obligation that is currently unmet.

An inventory A complete roster of the non-human actors operating in the enterprise, including the ones no one registered. You cannot govern a workforce you cannot enumerate, and today most organizations cannot produce this list at all.
An authority map A model of which agent has been delegated what, expressed as explicit grants. It turns “the agent seems to have access to that” into a documented scope of decision-making that can be reviewed, tightened, or withdrawn.
A containment plan A drawn perimeter from the capability boundary — the tools and data each agent may reach, and therefore the blast radius if it errs or is subverted. Containment is impossible without a boundary to contain against.
An accountability chain A traceable line from every autonomous action to a named owner. When an agent acts, the question “who answers for this?” has a documented answer rather than a search party.

Inventory, authority map, containment plan, accountability chain: these are precisely the artifacts any governance regime demands of a workforce. The viewpoint's contribution is that it makes them producible from the architecture itself, rather than reconstructed after an incident.

A Candidate Contribution to the Body of Knowledge

This is offered as exactly that — a candidate contribution to the enterprise architecture body of knowledge, put forward for the scrutiny that any proposed metamodel extension deserves. The venues for that scrutiny already exist: the standards bodies and registers where the discipline consolidates its vocabulary, from The Open Group's stewardship of TOGAF and ArchiMate to the Cloud Security Alliance's work on agent governance. The claim here is narrow and testable: the frameworks model artifacts, humans, and protected assets; they do not model a non-human actor under delegated authority; and the gap is now being felt in production, not merely in theory.

Categories in enterprise architecture do not arrive fully formed. They are proposed, argued, refined against practice, and eventually absorbed into the metamodel that every architect shares. The agent workforce is a category in exactly that early stage — forming in the field faster than the frameworks are naming it. The construct proposed here, the Agent element and the Agent Workforce viewpoint, is one attempt to give the category a precise place to live.

The Bridge

The extension named here is the metamodel piece — the missing element and the viewpoint that governs it. The fuller account of that fifth domain, layer by layer, is the Enterprise Agent Architecture. Start there for how the workforce, its capabilities, and its accountability fit together as a reference model.

About This Series

Michael K. Saleme — Enterprise Agent Architect

Enterprise Agent Architecture is published as a practitioner series — the working account of a discipline as it forms, released one part at a time and offered for the scrutiny of the enterprise architecture community. This part takes up the metamodel question directly: what construct the established frameworks are missing, and where it slots in.

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, and it needs an element of its own.