AI agent sprawl is the proliferation of sanctioned AI agents across an enterprise without coordinated ownership, a shared inventory, or lifecycle management. In 2026 the average enterprise runs twelve AI agents (Salesforce Connectivity Benchmark), IBM projects more than 1,600 per large enterprise by year-end, 89% of AI agent pilots never reach production (Gartner Agentic AI Pulse 2026), and only 18% of organisations maintain a current agent inventory. This handbook explains what agent sprawl is, how it differs from shadow AI, and the nine-column registry an enterprise Salesforce architect can build in two weeks to prevent it.
Every enterprise Salesforce architect has lived through integration sprawl. A middleware layer that started as three connections became four hundred. Nobody could name the owner of any given endpoint. Retiring a legacy system became a six-month archaeological dig through interfaces that had been added, forked, and forgotten.
The pattern is repeating one abstraction layer up — as AI agent sprawl — and it is repeating faster.
Enterprises run twelve AI agents on average today, according to Salesforce's 2026 Connectivity Benchmark. That number is projected to reach twenty within two years. IBM's own forecast is more aggressive: by the end of 2026, most large enterprises will operate a digital workforce of more than sixteen hundred AI agents spread across Agentforce, Microsoft Copilot Studio, Azure OpenAI, custom LLM deployments, and third-party SaaS vendors. Only eighteen percent of organisations can produce a current inventory of the agents already running inside their walls. Fifty percent of those agents run without any AI governance controls at all.
Salesforce brought Agentforce multi-agent orchestration to general availability on 15 June 2026. Hosted Model Context Protocol (MCP) servers went GA in April. Both were unambiguous good news for practitioners. Both also removed the last technical excuse for delaying the AI governance conversation. The tools now exist to compose specialist agents into orchestrated workflows across the enterprise; the discipline required to know what those agents are, and who is responsible for them, does not arrive with the release notes.
This handbook is written for the enterprise architect who has to answer that question.
What is AI agent sprawl?
AI agent sprawl is not the same as shadow AI, and treating them interchangeably is one of the reasons enterprises are already behind on AI governance.
Shadow AI is the classic control-evasion problem: employees pasting customer data into public LLMs, browser extensions calling foreign APIs, procurement blind spots. It is a familiar security incident pattern in a new medium.
AI agent sprawl is different. It describes agents that were sanctioned — approved by IT, provisioned inside Agentforce or a hosted MCP server, granted specific tool access — but deployed without coordination, without documented ownership, without a lifecycle, and without a common place to look them up. It is the AI inventory problem, not the AI perimeter problem.
An organisation can have zero shadow AI and still have severe AI agent sprawl. In practice most enterprises in 2026 have both, and the mitigations are different.
The consequence is that the failure mode has shifted. Two years ago the question was “did we approve this?” Today the question is “we approved forty-seven of these Agentforce agents; can anyone tell us which one just told a customer the wrong renewal price?”
How many AI agents does the average enterprise run in 2026?
Four figures from independent sources do most of the work of framing AI agent governance as an enterprise architecture problem rather than an implementation problem. They belong in every architecture review deck for the rest of the year.
- 89% of AI agent pilots never reach production — Gartner Agentic AI Pulse 2026, corroborated by a16z and MIT Sloan CIO panel.
- 40% of agentic AI initiatives will be discontinued by 2027 — Gartner 2026 projection.
- 12 AI agents per enterprise today; more than 1,600 by end of 2026 — Salesforce 2026 Connectivity Benchmark; IBM year-end forecast.
- Only 18% of organisations maintain a current AI agent inventory — SAP News Center, 1 August 2026, reclassifying agent sprawl as a board-level concern.
Eighty-nine percent of AI agent pilots never reach production. Gartner's Agentic AI Pulse 2026 puts the failure rate at 89%; independent polling from a16z and MIT Sloan's CIO panel places it above 88%. The pilots that do reach production fare only modestly better: 41% cross positive ROI within twelve months; 19% never reach payback at all.
Forty percent of agentic AI initiatives will be discontinued by 2027. Gartner's projection is not a warning about the technology. It is a warning about the operating model. The programmes that survive are not the ones with the best models; they are the ones with the clearest ownership.
Twelve today, sixteen hundred tomorrow. The Salesforce Connectivity Benchmark's twelve-agents-per-enterprise figure describes the current baseline. IBM's sixteen-hundred figure describes the eighteen-month trajectory. The distance between those numbers is where architecture teams are supposed to make ownership, registry, and orchestration decisions that will still be legible in three years.
Only eighteen percent maintain a current inventory. SAP News Center reclassified agent sprawl as a board-level concern on 1 August 2026. The reclassification was not about severity of individual incidents. It was about the visibility gap: leadership teams asking their CIOs how many agents the enterprise runs and receiving a range, not a number.
Five architectural decisions that create AI agent sprawl — and prevent it
Every organisation now dealing with AI agent sprawl made the same five architectural decisions by default, in the same order. Enterprise architects catching the problem early can make each of them deliberately. Together, the five constitute a minimal AI agent governance framework for Salesforce environments.
1. Ownership model
Every agent must have one named owner with real budget and a stated business trigger. Not a committee. Not a shared inbox. Not “the AI CoE.” An agent without a named owner will drift toward the person who complains loudest about it, and that person will not have the authority to sunset it.
The registry entry for a new agent should refuse to save without an owner field populated. This is a two-day change in ServiceNow, Backstage, or a custom Salesforce object — and it removes ninety percent of future sprawl in one control.
2. Registry as a first-class architectural artefact
The wiki page is not the AI agent registry. The Slack channel is not the registry. The agent list inside the Agentforce Command Center is a partial view, not the registry — it does not include third-party SaaS agents, Copilot Studio agents, Azure OpenAI agents, MCP-connected agents on other platforms, or Heroku-hosted custom agents.
A registry that only covers what one vendor can see is exactly the failure the integration-sprawl generation of enterprise architects already lived through with three different iPaaS consoles. The AI agent registry must be platform-neutral by design. It can live inside Salesforce as a custom object; it can live in an enterprise developer catalog such as Backstage or Port; it can live in an MCP gateway. What it cannot do is live in only one vendor's control plane.
3. Tool-call contracts and MCP gateways
Model Context Protocol (MCP) has emerged as the de facto standard for describing how an AI agent connects to tools, data sources, and enterprise systems. Salesforce ships hosted MCP servers (GA April 2026 for Enterprise Edition and above), MuleSoft converts existing APIs into MCP endpoints, Heroku hosts custom MCP servers, and AgentExchange now includes an MCP marketplace.
MCP is a standardisation opportunity, not a policy. Standardising on the protocol reduces custom integration surface; it does not by itself enforce which tools an AI agent may call, on which data domains, under whose authorisation. That policy layer — the tool-call contract, typically enforced through an MCP gateway that sits between agents and the org — remains the enterprise architect's responsibility. Every agent in the registry should carry an explicit, versioned declaration of the tools it may invoke and the data classifications it is permitted to touch.
4. Trust boundaries: decide vs. do
The single most useful distinction to apply across an agent estate is the separation of what an agent may decide from what an agent may do.
An agent that summarises a case, recommends a next action, and posts the recommendation to a human queue is operating inside a decision boundary. An agent that summarises a case, recommends a next action, and executes that action against a customer record is operating inside an action boundary.
The controls appropriate to each are different. The audit obligations are different. The failure blast radius is different. In practice most enterprises today do not classify their agents this way, which is why post-incident reviews so frequently discover that an agent had permission to perform an action nobody would have consciously granted it in isolation.
5. AI agent observability that survives the vendor tab
Agentforce 3's Command Center is a legitimate step forward for observing Agentforce agents. It does not observe agents hosted in Azure OpenAI, agents inside Microsoft Copilot Studio, agents deployed by a marketing platform vendor, or agents running on internal Heroku instances.
Every enterprise now needs a cross-platform AI agent observability layer in the same way it needed a cross-platform integration observability layer a decade ago. The Agentforce Command Center is the Salesforce component of that layer. The rest is still the enterprise architect's build.
How Agentforce multi-agent orchestration changes AI governance
The June 2026 GA of Agentforce multi-agent orchestration brought a real architectural shift. Agents are now composed: one orchestrator agent reads the descriptions of specialist subagents and routes tasks between them at runtime. The Atlas Reasoning Engine 3.0 performs the routing based on natural-language agent descriptions rather than hardcoded decision trees, and coordination between subagents flows over the Model Context Protocol.
This is genuinely useful. It also relocates the failure mode.
In the single-agent world, the dominant failure mode was the agent doing the wrong thing well. In the multi-agent world, the dominant failure mode is the orchestrator picking the wrong subagent — and the wrong subagent then doing the wrong thing well, quickly, and with a plausible audit trail.
Gartner's 2026 cohort study on Agentforce found that programmes achieving eighty percent pilot accuracy lose between twelve and nineteen percentage points on launch to broader user populations, primarily because real users surface task variants the pilot never tested. Multi-agent orchestration compounds that loss: the variants now interact across subagents.
The practical implication for AI governance is that pre-production evaluation of a multi-agent system must include the orchestration layer, not just the individual agents. The registry entry for an orchestrator must include the set of subagents it can route to, and the change process must require re-evaluation whenever any subagent in that set changes.
How to build an AI agent registry for Salesforce (nine columns, two weeks)
Enterprise architects asking “where do I start with AI agent governance” should start with a registry, and the registry should be small.
The minimum viable AI agent registry has one row per agent and the following columns:
- Agent name and internal ID
- Owner — individual, not team
- Business trigger — the specific situation this agent exists to handle
- Hosting platform — Agentforce, Copilot Studio, custom, third-party
- Tools it may call — explicit list, versioned
- Data domains it may touch — mapped to your existing data classification
- Decide vs. do — decision-only or action-taking
- Escalation path — the human queue or role that receives failed or ambiguous cases
- Sunset review date — the date on which the agent must be reviewed for continued existence
Nine columns. A registry that requires more is one that will not get filled in.
Two weeks of engineering effort produces a working version, whether the storage is a Salesforce custom object with a lightweight Lightning Web Component UI, a Backstage plugin, an MCP gateway configuration file, or a governed Google Sheet with disciplined change control. The choice of storage matters less than the discipline of requiring every new AI agent to appear in the registry before it goes live in production.
Enterprises that already have hundreds of Agentforce agents deployed will find the registry easier to build than to backfill. Backfilling is the tax on delay.
What AI agent sprawl means for your next enterprise architecture review
The editorial position is straightforward, and it is the same position enterprise architects took on integration sprawl fifteen years ago after they had already lived through it once:
The technology to build AI agents is now cheap. The technology to compose them via multi-agent orchestration is now cheap. The technology to host them inside enterprise-controlled MCP servers is now generally available across Salesforce, MuleSoft, and Heroku. Every one of these decreases is real.
The discipline required to know what AI agents exist, who owns them, what they can do, and what they cannot, has not decreased at all. That discipline is now the enterprise architect's problem. It will not be solved by Salesforce, by the CIO, by the AI Center of Excellence, or by the vendor whose product is the largest line item on the AI budget.
Enterprise architects reading this whose organisations do not yet have an AI agent registry have a two-week project waiting for them. Architects whose organisations already have hundreds of ungoverned agents have a much larger one — but the same first step.
The AI agent estate you build in 2026 will be the estate you inherit in 2029. Own it now, or archaeology it later.
