From an agent fleet to an agentic organization: define who does what
How to assign every agent a mission, scope, authority, owner, and lifecycle before scaling the system.
AI agents are still often designed as isolated features. A need is identified, a model is connected to data and a few tools, and the resulting agent is made available to a team.
This approach works while agents remain few, weakly autonomous, and separated from one another. It reaches its limits as soon as they can read sensitive data, modify a business system, trigger a workflow, or delegate work to another agent.
At that point, every agent becomes a new operational actor. It has a mission, tools, access rights, and some degree of authority. It also introduces dependencies, risks, and accountability that must remain assigned to a person or a team.
Scaling agents is therefore not only a model or orchestration problem. It is an organizational problem.
This article opens a series on the organizational architecture of agents. The series follows four questions:
- Who does what?
- Who acts on whose behalf?
- Who may communicate with whom, and what may they share?
- Who controls, proves, and stops the whole system?
The first question is the foundation for the other three.
The Current Situation: Creation Is Moving Faster Than Organization
The building blocks required to create agents are advancing rapidly. Platforms can connect models to document repositories, APIs, tools, and workflows. Business teams can experiment without rebuilding an entire infrastructure.
This democratization creates speed, but it also encourages local optimization. Each team addresses its own use case, selects its tools, and defines its rules. The enterprise gradually accumulates useful agents without gaining a shared view of their place in the organization.
What commonly exists today:
- use-case catalogs;
- specialized assistants or agents;
- orchestration workflows;
- platform-specific controls;
- separate technical logs.
What is often missing:
- a map of agents and their capabilities;
- a clearly accountable owner for every agent;
- an explicit separation of missions;
- rules for preventing duplicate capabilities;
- a shared definition of authority and limits;
- a suspension and retirement process.
The NIST AI Risk Management Framework already recommends maintaining an inventory of AI systems, clarifying roles and lines of communication, and planning for safe decommissioning. With agents that can take action, these governance outcomes become architectural properties.
An Autonomous Agent Remains an Operational Software Actor
When an agent participates durably in a real process, it does not become a member of staff. It becomes an operational agent: a software actor to which the organization assigns a mission, scope, tools, access rights, and bounded authority.
This term describes a function within the information system, not a human or legal status. An agent does not carry legal responsibility or general human judgment. It cannot itself be accountable for the consequences of its decisions. Accountability remains with the people and organizations that designed, authorized, operated, and supervised it.
A more accurate definition is therefore:
An agent is a software-based operational actor whose mission and powers must be explicitly assigned, limited, and supervised.
This definition distinguishes an operational agent from a conversational feature. The more it can act on the information system, the more precise its organizational framework must become. An agent is operational only when its mission, powers, human owner, controls, and lifecycle are explicitly defined.
The Risk of Agent Sprawl
When agents multiply without a shared model, the organization may experience Agent Sprawl: a proliferation of locally created agents whose missions, permissions, and dependencies are difficult to map.
Five symptoms reveal it.
1. Responsibilities Overlap
Two agents cover the same capability using different rules, sources, or answers. An internal assistant and an HR agent may both answer leave-related questions without sharing the same source of truth.
The technical duplicate becomes a conflict of authority: which agent is authoritative?
2. Privileges Accumulate
An agent receives an initial permission, followed by additional access as new requirements emerge. Its original mandate remains narrow, but its technical identity gradually becomes capable of operating across a much broader scope.
3. Decisions Can Conflict
Two agents act on the same business object without priority or concurrency rules. One updates a record while another is still working from an older version. Connecting the agents does not eliminate the issue; it may accelerate it.
4. Accountability Becomes Untraceable
When an incorrect action occurs, several questions must be answered: which agent acted, for which mission, on whose behalf, under which authorization, according to which policy, and under the responsibility of which team?
A technical log proves that an API call occurred. It does not establish organizational accountability.
5. Redundancy Becomes Structural
Several agents retrieve the same data, execute the same controls, or repeatedly invoke the same services. Cost and latency increase, while no one knows which agent can be retired without breaking an invisible dependency.
What an Organizational Architecture for Agents Must Define
The organizational architecture of agents is the model that gives every agent a place in the organization and formalizes its relationships with users, systems, and other agents.
It answers seven questions.
| Dimension | Design question |
|---|---|
| Position | Which domain, product, or process does the agent belong to? |
| Mission | What precise outcome must it produce? |
| Scope | What may it handle, and what must it refuse? |
| Authority | May it inform, propose, execute, delegate, or interrupt? |
| Access | Which data, tools, and systems may it use? |
| Interfaces | Which users, agents, and services may it interact with? |
| Sensitivity | What level of validation, traceability, and supervision is required? |
Two additional attributes are essential: a human owner and a lifecycle.
The owner is accountable for the mission, outcomes, and risks. The lifecycle covers creation, approval, modification, suspension, and retirement.
The Agent Mission Charter
Every agent should have a mission charter shared across business, architecture, security, and operations teams.
At a minimum, it should contain:
- identity and version;
- mission and expected outcome;
- owner and business sponsor;
- positive scope;
- negative scope;
- tools and knowledge sources;
- levels of authority;
- interfaces and partners;
- escalation conditions;
- review frequency and retirement procedure.
This charter should not remain a static document. Its information should feed the agent registry, access policies, execution harness, and supervision controls.
Separating the Business Plane from the Control Plane
The logical organization benefits from being divided into two planes.
The Business Plane
This plane contains agents that carry operational missions. They are organized by domain or capability: human resources, finance, procurement, customer service, or operations.
Each domain may select its agents, knowledge sources, and workflows, provided it complies with shared contracts and policies.
The Control Plane
The control plane provides the cross-cutting mechanisms required to make these agents governable:
- identity and capability registry;
- authorization policies;
- data and action classification;
- controlled context distribution;
- logging and observability;
- version management;
- suspension and revocation.
The structural rule is simple:
Centralizing governance does not mean centralizing all execution.
A super-agent with access to every data source and tool would concentrate privileges and create a major single point of failure. The control plane should enforce shared rules while business agents remain distributed and limited to their domains.
Example: An Organizational Architecture for HR Agents
The HR domain illustrates this separation.
The interface agent understands the request and handles low-risk interactions. It does not automatically receive full access to HR records.
The gateway verifies the requester’s identity, the sensitivity of the request, and the agent authorized to act. It distributes only the context required for the task.
Specialized agents each have a limited scope. The leave agent does not share the payroll agent’s tools or permissions. Sensitive or irreversible actions go through human approval or a deterministic workflow.
One point is essential: authorization decisions should not depend solely on a probabilistic model. A model may classify the request; a testable and auditable policy must decide whether the action is allowed.
Organization Is Not Enough: Four Identities Must Still Be Connected
Assigning a mission to an agent does not prove that the acting instance is legitimate. Four identity proofs must be distinguished and then connected:
- 01 Requester The user or system that initiates the request.
- 02 Logical agent The declared agent, its mission, and its owner.
- 03 Workload The cryptographic identity of the instance actually running.
- 04 Version The provenance and integrity of the deployed artifact.
Effective permission should then result from the following intersection:
This formula prevents two errors: transferring all user privileges to the agent, or allowing the agent to act through a generic technical account that cannot be attributed.
These mechanisms are the subject of the second article.
Sovereignty Is a Deployment Axis, Not a Different Organization
The organizational structure does not depend on the choice of cloud, model, or provider. An HR mission remains the same whether the agent runs on a SaaS platform, in a European cloud, or on internal infrastructure.
The sovereignty profile does, however, change the placement and control of components:
- where data and models reside;
- who controls identities and keys;
- who operates the control plane;
- which external dependencies are accepted;
- how a provider can be replaced or a workload moved.
Sovereignty should therefore be treated as an implementation variant applied to the same logical model. This distinction prevents security, localization, and operational autonomy from being conflated.
The European Commission Cloud Sovereignty Framework illustrates this multidimensional view by distinguishing legal, data and AI, operational, supply-chain, technological, security, and compliance dimensions, among others.
Design the Organization Before Accumulating Agents
A governable agentic organization begins with a few basic decisions: inventory the agents, assign every capability to a domain, designate an owner, formalize positive and negative scopes, and classify actions according to sensitivity.
Models, protocols, and platforms then implement this framework. They cannot define it on behalf of the organization.
An organizational architecture can answer the first question: who does what?
It does not yet prove that the agent presenting itself is the one that was authorized, or that it is operating within the rights granted by the user.
After assigning missions, the series must therefore address a more sensitive question:
Who acts on whose behalf, with which identity and which authority?