AI agents are spreading faster than enterprises can govern them

In enterprise software budgeting meetings in 2026, almost nobody asks anymore whether to adopt AI agents. The question has shifted to how to keep them from spiraling out of control. OutSystems' 2026 State of AI Development report puts a number on that gap: 96% of enterprises are using AI agents to some degree, but only 12% have a centralized platform to actually govern them. That gap in the middle is what this piece is about: sprawl.

A sprinting protocol layer makes sprawl easier, not harder

A big reason this wave of agents is moving so fast is that the protocol layer has matured. The Model Context Protocol (MCP, a standardized way for AI models to call external tools and data sources) accumulated a large number of publicly listed MCP servers (external services that follow this protocol and can be called directly by a model) in a short span and has been integrated into ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code. The Agent2Agent protocol (A2A for short, a protocol that lets agents from different vendors discover and call each other), built on JSON-RPC 2.0 (a lightweight remote-procedure-call format) over HTTPS, uses an Agent Card (a document describing exactly what an agent can do and where its boundaries are) to declare each agent's capability boundary, and already has several major cloud vendors supporting it. For the first time, agents from different vendors and different frameworks can discover and call each other through a standardized interface. An open ecosystem is good news, but it also means a single enterprise can end up running dozens of agents from different vendors, on different protocol versions, with inconsistent permission models, and almost no unified audit view across any of them. The more standardized the protocol gets, the easier it is to casually bolt an agent onto a workflow, which actually lowers the bar for sprawl rather than raising it.

Sprawl is the real risk, not adoption itself

The root cause usually isn't that any single agent is poorly built. It's that the enterprise genuinely doesn't know how many agents it's running, what systems each one can touch, or who signed off on its permissions. A support team's agent can read the ticketing system, a finance team's separate agent can call the invoicing API, each reasonable on its own, but once both are allowed to write to the same CRM field, nobody can predict what happens. More often, an agent was never formally approved at all, just a plugin some team wired in on the side, and six months later nobody remembers it's still running.

A refrain that's becoming common in this space: the question enterprises face now isn't whether to use agents, it's whether, three months from now, anyone will still know how many agents they actually authorized.

The answer isn't to slow down. It's to take the architecture back

Faced with sprawl, most enterprises' instinct is to tighten approval workflows, adding a manual review gate for every new agent. That treats the symptom, not the cause, because the problem was never insufficiently strict approvals. It's that these agents are scattered across dozens of disconnected SaaS tools in the first place, each maintaining its own memory, its own permissions, its own logs. The adoption-to-governance gap described above doesn't close by adding more approval steps, because approval only stops new agents, not the one that's been quietly running for a year that nobody remembers approving. The sustainable fix is pulling agent execution and memory back into a workspace you can actually audit, whether that's a single task-specific agent or a full multi-agent orchestration, so every call log, permission boundary, and memory store lives in one observable system instead of scattered across each vendor's separate black box. That's the actual point of a sovereign AI agent workspace. Not fewer agents, but the first real visibility into how many you're running and what each one is doing.