The Mixed Agent Enterprise

The enterprise will not have one agent.

It will have a population.

This changes the architectural problem again.

The enterprise no longer needs merely to make an agent work.

It needs to make different machine actors work together inside the same institution.

That is the Mixed Agent Enterprise.

Chapter 08 established the architecture required to convert machine intelligence into controlled execution.

1. 01Identity
2. 02Context
3. 03Tools
4. 04State
5. 05Runtime
6. 06Authority
7. 07Orchestration
8. 08Evaluation
9. 09Observability
10. 10Control

But an enterprise scale execution architecture creates another consequence.

It lowers the cost of creating machine actors.

Once the infrastructure exists, agents can proliferate.

The number of machine actors can grow far faster than the number of enterprise applications.

This creates a new architectural object.

The agent population.

The enterprise must govern not only individual machine actors but the relationships among them.

It is tempting to imagine an enterprise standardized around one agent platform.

That may occur locally.

It is unlikely to describe the entire enterprise.

Large enterprises already operate heterogeneous technology estates.

Agent systems will emerge across that estate.

The enterprise therefore needs an architecture that assumes heterogeneity rather than waiting for standardization to eliminate it.

A useful starting point is to distinguish machine actors by their relationship to the enterprise.

01

1 · Enterprise Agents

Created or directly controlled by the enterprise.

Examples include: internal operations agents, engineering agents, finance agents, service agents, enterprise research agents.

The enterprise controls their lifecycle and operating environment.

02

2 · Embedded Agents

Agents delivered inside enterprise software and platforms.

The enterprise uses them but may not control their underlying implementation.

03

3 · External Agents

Agents operated by another organization that interact with enterprise systems.

A supplier agent. A customer agent. A partner agent. A financial institution's agent.

04

4 · Personal Agents

Machine actors acting on behalf of individual employees or users.

They may cross multiple systems and workflows.

These categories create different trust relationships.

An internally developed agent is not equivalent to a supplier's agent.

An embedded software agent is not equivalent to an employee's personal agent.

The architecture must know the difference.

The enterprise does not need to own every agent.

It does need to know what kind of actor it is dealing with.

A heterogeneous agent population cannot depend entirely on bespoke integration.

Agents need mechanisms to discover capabilities.

This is why agent interoperability standards have begun to emerge.

Model Context Protocol addresses one part of the problem by providing a common mechanism through which AI systems can access tools and context.

Agent-to-agent protocols address another by creating mechanisms through which machine actors can discover capabilities and exchange work.

The specific standards will evolve.

The enterprise requirement is more fundamental.

Machine actors need stable interfaces through which collaboration can occur without requiring shared internal architecture.

This resembles earlier stages of enterprise computing.

Applications became more useful when they could communicate through common interfaces.

Services became more composable when APIs established stable contracts.

Agents require an equivalent interoperability layer.

But the interface must carry more than data.

It may need to carry:

• identity
• objective
• context
• authority
• requested action
• constraints
• artifacts
• execution status
• evidence.

Agent interoperability is therefore not merely an integration problem.

It is an operating protocol.

Human organizations use contracts constantly.

An agent interaction requires something similar.

If Agent A delegates work to Agent B, the system needs to know:

• What is being requested?
• What outcome is expected?
• What information accompanies the request?
• What may Agent B do?
• What must Agent B not do?
• What evidence should be returned?
• How long may execution continue?
• What happens if the task cannot be completed?
• Who remains accountable?

Without these boundaries, delegation becomes ambiguous.

The same ambiguity that creates organizational failure among humans can become computational failure among machines.

The difference is speed.

Machine actors can reproduce ambiguous delegation at enormous scale.

The contract does not require a literal document.

It represents the information that must exist for accountable machine delegation.

Agent-to-agent communication should not be treated as unrestricted conversation between machines.

It should be treated as delegated execution across a boundary.

That changes the architecture.

A message between agents can create consequences.

The enterprise therefore needs to know when communication becomes delegation.

And when delegation becomes authority.

This is where the organizational model and technical architecture meet again.

Chapter 05 established the Delegated Authority Chain.

Chapter 08 established the runtime that enforces authority.

The Mixed Agent Enterprise extends that chain across machine actors.

Authority cannot silently expand merely because one agent calls another.

Delegation must preserve the authority boundaries of the originating system.

Consider an agent authorized to prepare a purchase request.

At each step, execution has moved.

But authority should not automatically move with it.

A machine actor should not gain authority simply because another machine actor requested work.

Otherwise agent chains can create accidental privilege escalation.

The enterprise therefore needs a governing rule:

1. 01Delegation can narrow authority.
2. 02It cannot silently expand it.

If additional authority is required, the system must obtain it from an appropriate authority source.

This principle becomes critical as agents dynamically compose other agents.

Without authority propagation rules, the execution graph can acquire capabilities that no accountable human intentionally delegated.

Every consequential action should be traceable backward.

1. 01Machine Action
2. 02Executing Agent
3. 03Delegated Authority
4. 04Calling Agent or Workflow
5. 05Execution Domain
6. 06Accountable Human Owner

This chain may cross several machine actors.

But accountability cannot disappear inside the graph.

The enterprise should be able to answer:

Why was this machine allowed to do this?

If the answer cannot be reconstructed, the system does not possess accountable autonomy.

It possesses distributed execution without attributable control.

Human organizations operate through trust.

Machine actors require equivalent distinctions.

But trust cannot remain purely social.

The execution architecture must translate trust into controls.

Trust becomes a combination of:

• identity
• provenance
• authentication
• authorization
• reputation
• observed behavior
• contractual relationship
• execution history
• risk.

This creates another architectural object.

The Machine Trust Boundary.

Trust determines the conditions of interaction.

It does not determine whether the actor is intelligent.

A highly capable external agent may still deserve very little authority.

Capability and trust are separate dimensions.

The production experience of multi-agent systems already demonstrates why these distinctions matter.

Anthropic's multi-agent research system uses a lead agent to create and coordinate specialized subagents operating in parallel. Its engineering analysis reports significant gains for breadth-first research, but also identifies rapid growth in coordination complexity, state-management challenges, cascading failures and substantial resource consumption. Multi-agent execution in its research system can consume roughly fifteen times the tokens of ordinary chat interactions.

The same work found that agents need explicit delegation boundaries. Poorly specified subagent tasks produced duplicated work, gaps and wasted execution. Anthropic's production architecture therefore gives subagents defined objectives, output expectations, tool guidance and task boundaries.

More recent Anthropic research on multi-agent environments warns that agent populations introduce another class of problem. Individually reasonable agent behavior can combine into undesirable system-level outcomes, and current agents remain much better at hierarchical or tool-like delegation than at open-ended coordination among long-lived peers.

Microsoft's 2026 agent architecture similarly combines multi-agent workflow capability with runtime governance, including policy enforcement and auditability.

The evidence is early.

But it points toward the same architectural conclusion.

The behavior of an agent population cannot be governed solely by governing each agent individually.

An individual agent can fail.

A population can create another kind of failure.

Interaction failure.

The error propagates.

Or several agents independently optimize local objectives.

Each behaves within its own authority.

The combined result harms the enterprise outcome.

No individual actor necessarily violated its instructions.

The system still failed.

This is familiar in human organizations.

Local optimization can produce global dysfunction.

Machine populations can reproduce the same phenomenon at greater speed.

The enterprise therefore needs to evaluate not only:

Is this agent behaving correctly?

but:

Is the agent population producing the intended system behavior?

That is a different level of control.

Each objective is legitimate.

Their combined execution may be impossible.

Someone must reconcile the objectives.

Human organizations do this through strategy, management, governance and escalation.

Machine populations require equivalent mechanisms.

This is why the Mixed Agent Enterprise cannot become a collection of independently optimized agents.

The enterprise requires shared outcome architecture.

The outcome constrains the agents.

Not the reverse.

The enterprise should resist a seductive architectural mistake.

Do not turn every organizational objective into an autonomous optimizing agent and assume the enterprise will emerge from their interaction.

An enterprise is not merely a market of competing objectives.

It contains deliberate priorities.

Machine execution must remain subordinate to that architecture.

The agent population exists to execute the enterprise operating model.

The operating model should not become an accidental consequence of agent interaction.

This is the difference between an agent ecosystem and an AI Native enterprise.

One contains machine actors.

The other governs them toward a coherent outcome.

And that raises the next question.

If thousands of agents can interact, delegate, compete for resources and act across enterprise boundaries, the organization needs mechanisms for governing the population itself.

It needs to determine:

• which agents may exist
• which may interact
• which may delegate
• which may persist
• which may consume shared resources
• which may cross trust boundaries
• and which should be removed.

The enterprise now needs population governance.

The enterprise now needs population governance.

Population governance begins with a basic requirement.

The enterprise must know which machine actors exist.

This sounds obvious.

It will not remain simple.

A machine actor can become operational without appearing in the systems traditionally used to understand enterprise technology or workforce capacity.

At small scale, this can be managed manually.

At enterprise scale, it cannot.

The first requirement of population governance is therefore visibility.

What machine actors are participating in enterprise execution?

Machine actors need an equivalent mechanism.

An Agent Registry.

The registry establishes a discoverable record of the machine actors recognized by the enterprise.

For each material agent, the enterprise should be able to determine:

• identity
• purpose
• owner
• execution domain
• capabilities
• authority
• tools
• models
• data access
• runtime
• dependencies
• cost center
• evaluation status
• lifecycle state.

This does not mean every temporary subagent requires a permanent administrative record.

The level of registration should follow consequence.

The principle is proportionality.

The more consequential the machine actor, the stronger its institutional identity must become.

The registry makes the machine population legible.

Without legibility, there is no population governance.

A registry creates another capability.

Discovery.

Agents may need to locate other machine capabilities.

Discovery makes machine execution composable.

But discovery creates risk if it is confused with authority.

An agent being able to discover another agent does not mean it may invoke it.

An agent being able to invoke another agent does not mean it may use every capability the receiving agent possesses.

The enterprise therefore needs to separate:

Capability Discovery

Finding what exists.

Execution Permission

Being allowed to use it.

This mirrors the distinction established throughout the operating model.

Agent populations will accumulate unless the enterprise deliberately removes them.

This is predictable.

This is how machine sprawl emerges.

The consequences are more serious than unused software licenses.

An abandoned application consumes money.

An abandoned agent may retain the ability to act.

Population governance therefore requires lifecycle states.

1. 01Creation
2. 02Experimentation
3. 03Evaluation
4. 04Approval
5. 05Activation
6. 06Modification
7. 07Restriction
8. 08Suspension
9. 09Retirement

Retirement must remove more than the agent interface.

It may require revoking:

• identity
• credentials
• authority
• tool access
• data access
• delegation rights
• scheduled execution
• memory
• persistent state.

Machine actors need an end of life.

Every consequential agent needs a human accountable owner.

But organizations change.

If agent ownership is attached only to the person who created it, accountability can decay while execution continues.

Ownership therefore needs institutional continuity.

The agent should belong to an execution domain or accountable role, not merely to an individual creator.

When organizational responsibility moves, machine responsibility must move with it.

This creates a governance requirement:

No consequential agent should become organizationally orphaned.

An orphaned machine actor should lose authority until accountable ownership is restored.

That principle turns ownership into an enforceable lifecycle condition.

Individual agents can carry individual rules.

But some policies apply across the enterprise.

• No agent may expose protected information to an untrusted external actor.
• No purchasing agent may exceed defined transaction authority.
• No external agent may inherit internal credentials.
• No agent may delegate authority it does not possess.
• No machine actor may continue operating after its identity is suspended.
• No agent may use an unapproved model for restricted information.

These are population policies.

They should not depend on every agent implementation independently reproducing them.

Where possible, the control plane should enforce them consistently across the execution environment.

This creates a hierarchy of control.

1. 01Enterprise policy
2. 02Domain policy
3. 03Workflow policy
4. 04Agent policy
5. 05Runtime constraint

The closer a rule is to enterprise risk, the less it should depend on local agent behavior for enforcement.

Population governance turns a collection of agents into a governable institutional capability.

The Mixed Agent Enterprise does not end at the organizational boundary.

Execution can therefore cross institutional boundaries without a human participating in every interaction.

This creates a machine to machine version of a familiar enterprise problem.

Who are we dealing with?

The answer must be stronger than:

an API call arrived.

The enterprise may need to establish:

• which organization the agent represents
• which principal authorized it
• which credentials establish identity
• which capabilities it may access
• which transaction limits apply
• which evidence must be retained
• which legal or contractual framework governs the interaction.

The external agent should not be trusted because it speaks coherently.

It should be trusted because the institutional relationship supporting its actions can be established.

Agent interoperability without institutional trust will not be enough for consequential enterprise execution.

Two agents may be technically capable of communicating.

That does not mean they should transact.

Enterprise execution requires another layer above protocol compatibility.

This is what turns machine communication into trusted economic interaction.

The agent may become the interface.

The institution remains the principal.

A population of agents also competes for resources.

One agent behaving inefficiently may be tolerable.

Ten thousand agents behaving inefficiently can become an infrastructure event.

This makes resource governance a population problem.

If every agent independently optimizes its own execution quality, the collective system may consume far more resources than the enterprise intends.

Each decision may appear locally rational.

Collectively, they create cost.

The control plane therefore needs the ability to allocate scarce machine resources across the population.

Budgets cannot exist only at the agent level.

They may also exist at:

• workflow level
• domain level
• business unit level
• model level
• platform level
• enterprise level.

This creates a machine capacity allocation problem analogous to capital allocation.

Not every valid execution deserves unlimited resources.

Resource contention creates another requirement.

Priority.

When capacity is constrained, which execution matters most?

The enterprise therefore needs mechanisms to express execution priority.

Priority can influence:

• model allocation
• compute allocation
• queue position
• latency target
• budget
• retry behavior
• human escalation.

This is strategy entering the execution system.

The architecture is not merely determining what can execute.

It begins to determine what deserves capacity first.

Chapter 08 established observability at the execution level.

The Mixed Agent Enterprise requires another layer.

Population observability.

The enterprise needs to see patterns across machine actors.

• Which agents interact most frequently?
• Where does delegation concentrate?
• Which agents consume disproportionate resources?
• Which tools have become critical dependencies?
• Where are failures propagating?
• Which machine actors repeatedly trigger escalation?
• Where are new interaction patterns emerging?
• Which agents are operating outside expected domains?
• Which execution chains cross trust boundaries?

These questions cannot be answered by inspecting one agent trace at a time.

The enterprise needs to observe the execution graph.

The execution graph reveals the machine organization as it actually operates.

Not as it was designed on paper.

This becomes critical because dynamic agent systems can form relationships during execution that were not explicitly represented in the original architecture.

The runtime graph becomes evidence of the real operating model.

An individual agent failure can often be stopped by stopping the agent.

Population failure may require something stronger.

The enterprise needs mechanisms to contain the blast radius.

Containment may require:

• isolating an agent
• blocking an interaction path
• revoking a tool
• restricting a model
• suspending an execution domain
• cutting external connectivity
• reducing authority
• forcing human approval
• stopping a workflow class.

This is the machine equivalent of operational containment.

The objective is not merely to stop the original failure.

It is to prevent propagation.

Architecture determines how far failure can travel.

If execution domains have bounded permissions and isolated environments, failure can be contained.

This produces another architectural principle.

Autonomy should scale through bounded domains, not unlimited connectivity.

The enterprise should make collaboration easy where it is intended.

It should make propagation difficult where it is not.

At sufficient scale, the enterprise cannot prescribe every interaction among agents.

The number of possible relationships becomes too large.

Governance therefore shifts from specifying every action toward establishing rules under which interaction may occur.

• Identity must be established.
• Authority cannot silently expand.
• Trust boundaries must be respected.
• Enterprise policies must survive delegation.
• Resource consumption must remain bounded.
• Consequential actions must remain attributable.
• Execution must remain observable.
• Human accountability must remain identifiable.

These are not workflow instructions.

They are constitutional rules for machine participation in the enterprise.

They define the conditions under which autonomous execution is legitimate.

The Mixed Agent Enterprise requires governance that behaves more like institutional architecture than application configuration.

Applications

Are configured.

Populations

Are governed.

A machine population contains relationships, dependencies, incentives, shared resources, trust boundaries and emergent behavior.

The enterprise therefore needs mechanisms that operate above the individual actor.

These are the institutions of the machine execution environment.

The enterprise does not need to control every decision centrally.

It needs to establish the conditions under which distributed execution remains coherent.

This is the Mixed Agent Enterprise.

A heterogeneous population of machine actors operating across enterprise workflows under a common institutional architecture.

Once machine actors operate at population scale, something else changes.

The execution architecture therefore creates an economic system.

Machine execution may create enormous operating leverage.

It may also create enormous infrastructure demand.

The enterprise cannot separate the architecture of machine execution from the economics of the infrastructure underneath it.

The next question is therefore not simply:

Can the enterprise scale machine execution?

It is:

What happens to enterprise economics when intelligence itself becomes a continuously consumed infrastructure resource?

That is the next layer of the AI Native Operating Model.

10 · Infrastructure and the Economics of Compute