One agent is an integration. A hundred is a governance problem.

The interesting question about agents stopped being whether they work. In the projects we see, one agent that reads a supplier email and proposes the matching purchase order works well enough to keep. The interesting question is what happens on the day you have forty of them, built by four teams, three of which have moved on to something else.

That is not an AI problem. Every part of it is a problem the industry already knows by name: identity, entitlement, audit, cost attribution, blast radius, change control. The difficulty is that they all arrive at once, attached to something that makes its own decisions.

Three waves, and only the third is hard

The first wave was about models. Which one, how big, how much per million tokens. It felt decisive at the time and turned out to be the least durable question: the model in production today will be replaced twice before this article is old.

The second wave was about agents. How to connect one to a real system, where the line falls between what it decides and what code executes. We wrote about that line in agents decide, code executes, and the answer holds: judgement on one side, guarantees on the other.

The third wave is not about better agents. It is about a fleet of them. And a fleet behaves nothing like an integration, because the failure mode changes. One agent that gets a permission wrong is a bug. Forty agents sharing one service principal is an incident with no way to tell which of them did it.

What actually changed in the last year

Two things happened that are worth being precise about, because the precision is the argument.

Agents got real identities. Microsoft Entra Agent ID introduces four new object types: an agent identity blueprint, a blueprint principal, an agent identity, and an agent user. An agent identity is an account in Entra ID, governed with the same lifecycle machinery as a person: access packages, entitlement management, Conditional Access applied at blueprint level so every agent created from it inherits the policy, and risk signals from Identity Protection.

The part of that design worth pausing on is the sponsor. Every agent identity has a human being accountable for its access and its lifecycle. If that person leaves the organisation, sponsorship transfers automatically to their manager. Someone is always answerable for the agent, by construction, and the system refuses to let that be nobody.

Agents did not get a stable way to record what they did. The OpenTelemetry GenAI semantic conventions, the vendor-neutral vocabulary for agent traces, moved into a dedicated repository in the v1.42.0 release of 12 June 2026 and remain pre-stable. There is no 1.0. The shape is good and widely emitted, and it is still explicitly expected to churn.

Put those side by side and the asymmetry is the whole story:

We can now say who an agent is, what it may touch, and who answers for it. Saying exactly what it did, in a format that will still parse next year, is the part that has not landed. Anyone planning a fleet this year is planning around that gap, whether or not they have noticed it.

The protocol grew a governance structure

There is a second piece of evidence, and it is not an analogy.

The Model Context Protocol spent its first year being a description layer: this tool exists, here is how to call it. The revisions since have been almost entirely about control. The June 2025 revision classified MCP servers as OAuth 2.0 Resource Servers, made protected resource metadata mandatory under RFC 9728, and required clients to bind each access token to a specific server with the resource parameter from RFC 8707. The November 2025 revision added incremental scope consent through the WWW-Authenticate header, OAuth client ID metadata documents for registration, and an experimental tasks mechanism for durable requests with polling and deferred results.

That last one matters more than it looks. Tasks exist because agents started doing work that outlives a request. Work that outlives a request is work that needs a status, an owner and a way to be cancelled, which is the definition of something you have to govern.

And then the protocol did the thing that infrastructure does when it becomes load bearing: it formalised its own governance. Working groups, interest groups, a documented governance structure, an SDK tiering system with maintenance commitments. Protocols that stay toys do not grow committees.

What a fleet needs, and who owns each part

The nine concerns below are the ones we have watched go wrong. Grouping them this way is useful because it shows that almost none of them belong to the AI team.

Only the last row is new, and it is new only in the sense that the industry has not yet built the habit.

One identity per agent, and why the shortcut is expensive

The single most common shortcut we see is one service principal shared by every agent a team ships. It is easy, it works on day one, and it destroys three properties at once.

You lose attribution: the audit log records the principal, not which agent used it, and the answer to "which one did this" becomes a reconstruction exercise across application logs that may not exist. You lose least privilege: the shared principal accumulates the union of every permission any agent needed, so the newest and least reviewed agent inherits the rights of the oldest and most trusted. And you lose the ability to revoke: turning off the compromised agent turns off all of them.

The shape that survives is boring and familiar:

One blueprint carries the policy. Each agent gets its own identity from it. Access arrives through a package with an approver and an end date, rather than as a permanent grant that outlives the project that needed it.

The detail that deserves a decision, not a default

Entra Agent ID allows an agent identity to request an access package programmatically, on its own behalf, by creating an assignment request. The sponsor can also request on the agent's behalf, and an administrator can assign directly.

Read that first pathway again. An agent can ask for more access.

This is not a flaw. It is the correct primitive for a system where work is discovered at runtime, and the request still lands in an approval workflow with a human approver. But it is a genuine architectural fork, and it should be a decision your organisation makes deliberately rather than one it discovers in an audit.

Our position, from the same reasoning we apply to any privilege escalation path: the ability to request is fine, the approval must never be automatic, and the approver must be someone who understands what the resource is. An approval workflow that routes to a person who cannot evaluate the request is a rubber stamp with better logging.

Approval belongs at the irreversible step

The instinct, once a team realises how much an agent can do, is to put a human in front of everything. That fails within a fortnight: the reviewers stop reading, and you have added latency without adding judgement.

The line that holds is the same one that governs the rest of the system. Ask for a person where the action is irreversible or externally visible, and nowhere else.

The test is not how important the action feels. It is whether an unnoticed mistake can still be corrected on Monday.

Cost is a control, not a report

Token spend is usually treated as a finance question discovered at the end of the month. In a fleet it is a safety mechanism, because runaway cost and runaway behaviour are the same event seen from two angles. An agent stuck in a retry loop against a tool that keeps failing produces exactly one visible symptom before anyone notices the behaviour: the bill.

Which means the budget belongs at the identity, not in a dashboard:

# The limit belongs to the agent identity, not to a monthly review.
# An agent stuck in a loop spends its own budget and stops. It does not
# spend the team's, and it does not spend the next agent's.
def call_model(agent: AgentIdentity, request: Request) -> Response:
    if budget.spent(agent.id, today()) >= agent.daily_limit:
        raise BudgetExhausted(agent.id)          # fail closed, and alert
    response = model.invoke(request)
    budget.record(agent.id, response.tokens, response.cost)
    return response

Per-agent limits give you three things a monthly report cannot: the loop stops itself, the failure is attributed to one agent instead of one team, and the alert fires while the cause is still on screen.

Audit, when the reason is a probability

Traditional audit answers what happened and under whose authority. With agents there is a third question, and it is the one that gets asked in the room after an incident: why did it choose that.

That answer cannot be a model explanation, because a post hoc explanation from a model is a plausible narrative, not a record. What can be recorded is everything around the decision, and it turns out to be enough:

• the agent identity, not the shared principal;
• the tools available at that moment, and their versions;
• the inputs the agent actually received, including what a retrieval step returned;
• the tool calls made, in order, with parameters;
• the approvals granted, by whom, and when;
• the model and version, because behaviour changes between them.

Recreate those and you can reproduce the decision, which is what an auditor wants. This is also precisely the surface the OpenTelemetry GenAI conventions describe, and precisely why their pre-stable status is a planning constraint rather than a footnote. Instrument now, pin the convention version, and expect to migrate.

The uncomfortable conclusion

An organisation with clean identity, working entitlement management, real audit and honest cost attribution can put a fleet of agents into production this year. An organisation without those is not slow because it lacks agents. It is slow because that foundation was never built, and agents make the absence measurable in a way that nothing before them did.

We wrote something similar about the assistant that only reads what the user can read and about what to put in order before switching Copilot on. The pattern repeats because it is not really about AI. Each wave of automation asks the same question of an organisation, and asks it louder: do you know who is allowed to do what, and can you prove what was done?

Agents are the loudest version of that question so far. They are also the first that will keep asking it several hundred times a day, without getting tired, until someone answers.