Agent Sprawl: When Every Vendor Ships You an Agent

Nobody sat down and decided to buy five AI agents. You bought a CRM, a ticketing system, an ERP, a low-code platform, and a document tool. Over the past year, each of those vendors shipped an agent into the product you already pay for. Now you own an agent portfolio you never evaluated, never compared, and never designed.

That's agent sprawl. It's not a hypothetical risk — it's the predictable result of how the market moved. Salesforce shipped an Agentforce release on October 13, 2025, pitched as the fastest path from AI prototypes to production-scale agents, though Computerworld noted at the time that many of the announced features were still to come. Low-code vendors moved in the same direction: SD Times' October 2025 roundup listed Mendix adding an agent builder, generative AI project planning, AI-generated microflows, and support for the Model Context Protocol (MCP).

Every one of those is a reasonable product decision by the vendor. Collectively, they hand the buyer a problem nobody is accountable for: a dozen agents, each with its own memory, its own permissions model, and its own idea of what "done" means.

The uncomfortable math

Consider a mid-market company running a CRM, a service desk, and an ERP — a completely unremarkable stack. Each platform now ships with agentic features. Add a document intelligence tool and whatever your developers wired up in a weekend, and you're at four to six agents with production access.

Here's what that actually looks like in practice. A customer emails about a delayed order. The CRM agent sees the contact record and the open opportunity, but not the inventory position. The ERP agent knows the shipment is three weeks out, but has no idea this account is mid-renewal. The service desk agent opens a ticket, because that's what service desk agents do. Three agents, three partial answers, zero resolution — and a human still has to assemble the picture.

The failure isn't that any individual agent is bad. Each one is genuinely good inside its own data. The failure is that real business workflows cross silos, and vendor agents are deliberately shallow outside their own.

Why vendors build it this way

This isn't incompetence. A vendor's agent is a retention feature. Its job is to make their platform stickier, surface their data more usefully, and justify a seat-price increase. Deep, neutral integration with a competitor's system does none of those things. You should expect every vendor agent to be excellent within its boundary and indifferent beyond it — because that's the product they're incentivized to ship.

Which means the cross-system layer is never going to arrive in a release note. It's yours to build or yours to live without.

MCP and A2A are plumbing, not strategy

The honest counterargument is that interoperability protocols solve this. And it's true that protocols have moved from specification to procurement checkbox. Flowable's platform documentation, for example, cites multi-agent orchestration with A2A-compatible external agent support plus runtime visibility for regulated environments — a clear signal that buyers in regulated industries are now asking about cross-vendor agent protocols by name.

That's real progress. It is also not a strategy. Protocols let agents exchange messages. They do not answer the questions that actually determine whether a multi-agent system works:

• Which agent is authoritative? When the CRM agent and the ERP agent report different delivery dates, who wins?
• Who arbitrates conflicts? Two agents proposing contradictory actions on the same record is a governance question, not a messaging question.
• What happens on failure? If agent three in a five-step chain times out, does the workflow roll back, retry, escalate, or quietly stall?
• Where does context live? If every agent maintains its own memory, the same customer has five different histories and none of them are complete.
• Who is accountable in the audit log? Runtime visibility across vendors is not automatic just because the handshake succeeded.

These are architecture decisions. A protocol is a wire format; architecture is the set of rules about what travels over it and who's responsible when it doesn't.

Governance is the real adoption blocker

The pattern showing up in enterprise coverage isn't a capability gap — it's a trust gap. Computerworld ran a December 2025 piece framing agentic adoption around overcoming governance and trust issues. And the adoption curve itself is uneven: PYMNTS Intelligence's CAIO Report in its October 2025 edition described a two-speed enterprise landscape, where firms already comfortable with automation accelerate while others haven't started at all.

The stakes rose as agents started touching production systems directly. In October 2025, SD Times reported OpenAI's private beta of an agentic security researcher that finds and fixes vulnerabilities — an agent writing changes into code, not drafting a summary for someone to review.

When agents act rather than advise, ungoverned sprawl stops being an efficiency problem and becomes a risk problem. Five agents with write access and no shared policy layer is not an AI strategy; it's an incident waiting for a root-cause review.

The orchestration layer is the only part you should own

Here's the durable argument. Models churn constantly — Moonshot AI's Kimi K2.7 Code shipped in June 2026, and that cadence shows no sign of slowing. Vendors get acquired. Agent features get deprecated, renamed, or folded into a higher pricing tier. Anything you build tightly coupled to a specific agent has a short half-life.

What doesn't churn is the layer above: routing, shared context, policy, arbitration, and observability. That layer encodes how your business makes decisions — which system is the source of truth for a customer address, when a refund needs human approval, what a complete order picture looks like. No vendor will ever build that for you, because it's specific to you.

This is the practical case for treating orchestration as owned infrastructure rather than a feature you shop for. Agentic AI systems built as a coordination layer let you keep the vendor agents you already pay for — they're good at what they do — while adding the hub that decides who's authoritative, where context lives, and what happens when something fails. Point-to-point integrations between a growing set of agents scale quadratically and break constantly. A hub scales linearly and gives you one place to change a rule.

Start with an audit, not an architecture

Before anyone proposes a build, answer these. Most teams are surprised by their own answers.

• How many agents do you actually have? Count vendor-shipped features, not just things you deployed. Include anything in beta or toggled on by default in a recent release.
• Which ones can write? Separate read-only assistants from agents that create records, send messages, move money, or change code.
• What identity does each one use? Service account, shared credential, or an impersonated human user?
• Where is each agent's memory stored, and who can inspect it?
• Which workflows already cross two or more agents? These are your immediate failure candidates.
• If an agent takes a wrong action today, how would you find out — and how fast?
• Which of these agents would survive a vendor contract change?

If you can't fill in that table in an afternoon, that gap is the finding. You don't have an agent strategy; you have agent inventory.

What to do next

Keep the vendor agents. They're paid for and they're good inside their lane. The work is deciding what sits above them — and making that layer yours, so the next model release or vendor acquisition is a configuration change instead of a rebuild.

Levels AI builds that layer. If you're staring at an agent inventory nobody planned, our team can run the audit with you and map a coordination architecture that fits the systems you actually run. Start with AI consulting and a short discovery call — we'll tell you honestly whether you need orchestration now or whether you're two agents away from needing it.