Agents at Enterprise Scale

The idea in one minute#

One agent is an engineering problem. Five hundred agents — built by different teams, bought inside different products, created by employees in low-code tools — are a management problem of a kind enterprises have met before: it looks like the arrival of cloud accounts, or of software-as-a-service, when capability spread faster than anyone’s ability to say what existed.

The risks are specific. Nobody knows which agents exist or what each can reach. Agents hold broad, long-lived credentials. One agent calls another, and accountability dissolves. Costs appear with no owner.

The enterprise answer treats an agent as a new kind of worker with a new kind of identity. Every agent is registered, has an owner, has its own identity with the least access that lets it work, reaches tools only through a governed gateway, leaves an audit trail, and can be switched off. None of this slows a good team down, if the platform provides it by default.

A picture#

flowchart LR
  subgraph SRC["Where agents come from"]
    direction TB
    A1[":i-code: <b>Built by engineering</b><br/><small>frameworks, custom code</small>"]
    A2[":i-wrench: <b>Made in low-code tools</b><br/><small>by business teams</small>"]
    A3[":i-package: <b>Bought inside products</b><br/><small>CRM, service desk, office suite</small>"]
  end
  REG[":i-list-checks: <b>Agent registry</b><br/><small>owner, purpose, tier, tools, status</small>"]
  ID[":i-fingerprint: <b>Agent identity</b><br/><small>its own principal, short-lived tokens</small>"]
  GW[":agentgateway: <b>Agent and tool gateway</b><br/><small>policy on every call</small>"]
  subgraph SYS["Enterprise systems"]
    direction TB
    S1[":i-database: Data"]
    S2[":modelcontextprotocol: Tools over MCP"]
    S3[":a2a: Other agents over A2A"]
  end
  SRC --> REG
  REG --> ID
  ID --> GW
  GW --> SYS
  GW -.-> AUD[(":i-scroll-text: <b>Audit trail</b><br/><small>who asked, what it did</small>")]
  REG -.-> OFF[":i-ban: <b>Off switch</b><br/><small>per agent, per owner, global</small>"]
  class A1,A2,A3 neutral
  class REG,GW queue
  class ID warn
  class S1,AUD memory
  class S2,S3 io
  class OFF warn

How it really works#

Three populations of agents#

A strategy that covers only the first is missing most of the estate.

The six controls#

1. A registry. One catalogue of every agent, however it was made: owner, purpose, risk tier, model, tools and data it can reach, autonomy level, status. An agent that is not in the registry cannot get credentials — that is what makes the registry true. All three large cloud platforms now offer an agent registry or control plane; the capability matters more than the product.

2. An identity per agent. An agent is a principal in the identity system, distinct from the people who use it and from the service it runs on. Three rules:

• It never shares a person’s credentials or a broad service account.
• When it acts for a user, its effective access is the intersection of what that user may do and what the agent is allowed to do — never the union.
• Its tokens are short-lived, scoped to one tool and one purpose, and requested as needed.

3. A governed path to tools. Agents reach enterprise systems only through approved tools, and those calls pass through a gateway that applies policy — who may call what, with which parameters, at what rate — and records the call. Tools are published once in a registry and reused; an unvetted tool server is a supply-chain risk like any unvetted dependency.

4. Autonomy tied to risk tier. The autonomy dial from Workflows and Agents becomes policy.

5. An audit trail that answers “who did this?” For every action: the person or event that started the task, the agent, the model and prompt version, each tool call with its parameters, any approval and who gave it. When one agent delegates to another, the chain of delegation is recorded end to end, so that responsibility never disappears into “the agent did it”.

6. Lifecycle and an off switch. Agents are reviewed on a schedule, re-certified by their owner, and retired when the owner leaves or the purpose ends — orphaned agents with live credentials are the predictable failure. There is a way to suspend one agent, all agents of one owner, or everything, and it has been tested.

Agents calling agents#

As agents multiply, they start to delegate to each other — within a team, across departments, and across company boundaries. Two questions decide whether that is safe.

Whose authority is being used? The safe default is that authority is passed down explicitly and can only narrow. An agent handed a task on behalf of a user cannot do more than that user, and cannot grant a sub-agent more than it holds itself.

Is the other agent trusted? Inside one organisation, the registry answers that. Across organisations, the A2A protocol lets an agent publish a signed description of what it does and how to reach it, and lets tasks run for a long time and be resumed. Treat an external agent’s output exactly as you treat any external content: as untrusted data.

Multi-agent systems also raise ordinary engineering costs — every hand-off loses context and adds latency and a failure point. The enterprise guidance is the same as the design guidance: delegate when the work is truly separable or separately owned, not because the diagram looks impressive.

Standards that make this tractable#

MCP and A2A are both stewarded by the Agentic AI Foundation under the Linux Foundation. Standards bodies are also moving on the governance side: NIST opened an AI Agent Standards Initiative in February 2026 covering agent identity and security. Details are in Identity and Authorization and MCP and Tool Security.

Buying agents#

Embedded and purchased agents need procurement questions that older software did not.

1. What can it do without a person approving — and can we configure that?
2. Whose identity does it act under, and can we scope it?
3. Which of our data can it reach, and does it respect our permissions?
4. What does it log, and can we export the logs to our own tools?
5. Which model does it use, where, and are our data used for training?
6. Can we connect it to our own tools through MCP, and to our gateway?
7. How is it priced — per seat, per task, per outcome — and what caps exist?
8. How do we switch it off, and what happens to work in flight?

A vendor that cannot answer the first four has built a demonstration, not an enterprise product.

The economics of an agent workforce#

Agents make cost harder to predict and easier to justify badly.

• Price per outcome, not per call. The useful unit is cost per resolved case, per merged change, per reconciled invoice — compared with what that outcome is worth.
• Budget the tail. Report the median, the 95th percentile and the cap. The tail is where the surprise is.
• Count supervision. Review and approval time is part of the cost of an agent; if a person spends as long checking as doing, nothing was saved.
• Watch input tokens. Long-running agents re-read large contexts. Caching and context trimming are the main cost controls.
• Avoid the headcount fallacy. “This agent replaces ten people” is rarely how value arrives. It usually arrives as the same people handling more, or a queue that no longer exists.

An adoption path#

Moving up a phase is a recorded decision by the system’s owner and, for higher tiers, the governance board. It is reversible, and the way back is planned.

Signs it is going wrong#

• Nobody can produce a list of the agents in production.
• Agents use shared service accounts with broad access.
• A person’s permissions are copied to an agent “to get it working”.
• Autonomy was raised because the pilot went well, not because a gate was passed.
• The agent bill is one line with no owner.
• A departed employee’s agents are still running.

Remember this#

• Agents are a new kind of identity. Register every one, with an owner and a risk tier.
• Three populations: engineered, citizen-built, embedded in bought software. Govern all three.
• Each agent has its own identity; acting for a user means the intersection of permissions.
• Tools go through a governed gateway; delegation can only narrow authority.
• Autonomy is raised by recorded decision, on evidence, and can be lowered.

Try it#

1. List every agent you know of in an organisation — built, low-code and embedded in products. For each, can you name the owner and what it can reach?
2. Pick one and write its registry entry: owner, purpose, tier, model, tools, data, autonomy level, review date.
3. Send the eight procurement questions to a vendor whose product has an “agent” feature, or answer them from its documentation. Which could you not answer?

Check yourself#

1. Why is “five hundred agents” a different kind of problem from “one agent”?
2. When an agent acts for a user, what should its effective permissions be?
3. What makes an agent registry true rather than aspirational?
4. Name three signs that agent adoption is outrunning its governance.

Sources#

• Linux Foundation: formation of the Agentic AI Foundation
• The 2026-07-28 MCP specification
• Cloud Security Alliance: NIST AI Agent Standards Initiative
• AWS Prescriptive Guidance: Building multi-tenant architectures for agentic AI
• Gemini Enterprise Agent Platform overview — Agent Registry, Agent Identity, Agent Gateway