Your AI Agents Don't Talk to Each Other
Enterprises run about 12 AI agents and half work in silos. Why connecting them is a distributed-systems problem, and the order to fix it in, from my setup.
The average enterprise now runs about twelve AI agents. Around half of them work in isolated silos rather than as part of any multi-agent system.
That figure comes from Salesforce's 2026 Connectivity Benchmark Report, published in February (CIO Dive's summary), and it has been widely re-reported since, usually with the twelve in the headline and the half further down. Respondents expect the number of agents to reach about twenty by 2027. The same report found only 27% of enterprise applications are connected to each other.
I think the industry is reading that statistic exactly backwards. Twelve agents is presented as the adoption win and the isolation as a footnote. But an agent that isn't connected to anything is not a partial success on the way to a full one. It's a silo that responds in natural language.
We spent fifteen years complaining about departmental SaaS sprawl: every team with its own tool, its own copy of the customer record, its own login. Then we bought agents the same way. One per department, each with its own context, its own credentials, its own memory of what it has already tried. We rebuilt the sprawl, and this time the silos talk back.
How we got here, and why it was rational
I want to be fair to how this happened, because it wasn't stupidity.
Agent procurement followed agent capability. The first genuinely useful agents were single-domain: a support agent that could read tickets and draft replies, a security agent that triaged alerts, a sales agent that updated the CRM. Each one was bought or built by the team that felt the pain, on that team's budget, against that team's success metric.
Every one of those decisions was locally correct. The support team's agent didn't need to talk to the security team's agent to justify itself.
The result is a topology that looks like this: N agents, each with its own connection to the systems it needs, its own service account, its own idea of what happened. No shared substrate. When work needs to cross a boundary (a support ticket that turns out to be a security incident, a sales question that needs a supply chain answer), a human copies the context from one agent's window into another's.
That human is your integration layer. And the thing worth noticing is that you have now automated both ends of a handoff and left the handoff itself entirely manual.
What "agents talking to each other" actually requires
This is where the vendor demos and the reality diverge sharply. Wiring two agents together is easy: one agent calls the other as a tool, and you are done in ten minutes. Making it work in production requires five things that nobody sells as a package.
Shared context. Agent B needs to know not just what agent A wants, but what A already tried and ruled out. Without that you get expensive duplicated work: two agents independently querying the same system, reaching the same conclusion, and neither knowing the other did it. This is the easy one, and even it is annoying, because "what I tried" is exactly the part that lives in a conversation transcript rather than a structured field.
Identity and permission propagation. This is the genuinely unsolved one, and it deserves more attention than it gets. When agent A calls agent B, whose authority is B acting under?
If B uses its own service account, you've created a confused deputy: a user who couldn't access payroll directly can now ask the support agent to ask the HR agent, and the HR agent's own broad permissions happily comply. If B instead acts under the original user's delegated authority, you need that identity to survive every hop in the chain, including asynchronous ones where the user went home an hour ago.
Human org charts solve this with judgment: a person who gets an odd request from a colleague asks why. Service accounts have no judgment. And the identity infrastructure most enterprises have was built for "service A calls service B," which is a different problem from "service A calls service B on behalf of a specific human, three hops back, for a reason B cannot evaluate."
A shared tool surface. If every agent implements its own integration with your ticketing system, you have N implementations of the same thing, drifting apart. This is the argument for MCP, and it's the part of the stack that has actually converged. If you have not built one, here is how to build an MCP server. A common tool protocol doesn't solve orchestration, but it's the precondition. You cannot coordinate agents that don't agree on what a tool is.
Audit across the chain. When a five-agent chain does something wrong, which link decided? Per-agent logs tell you each one behaved reasonably given its input, which is true and useless. You need the trace, not the logs. Most teams discover this the week after their first incident.
Failure semantics. Agent A calls B, B calls C, C fails halfway through a side-effecting operation. There's no transaction. There's no rollback. What happens? Often the honest answer is "nobody has decided, and we'll find out."
Notice that four of those five are distributed systems problems, not AI problems. That's the actual shape of this: we've built a distributed system where the nodes are non-deterministic, and we're mostly ignoring the distributed part.
The three patterns people actually ship
Orchestrator with sub-agents. One agent owns the plan and delegates to specialists. Context flows through the orchestrator, which makes audit tractable and identity manageable: there's one place that decides. The cost is that the orchestrator becomes a bottleneck and a single point of confusion, and it has to be good enough to know which specialist to call. This is what I use, and it works because the trust boundary is one hop deep.
Shared bus. Agents publish events and subscribe to what they care about. Scales better, decouples nicely, and makes the audit story significantly worse, because causality across an event bus of non-deterministic actors is hard to reconstruct. Good when the coupling is loose and the actions are reversible. Bad when you need to explain a decision to a regulator.
The human as integration layer. The most common pattern by far, and usually unacknowledged. A person reads agent A's output and prompts agent B with it.
I want to defend this one, because it's treated as the embarrassing interim state and it frequently isn't. The human handoff gives you identity propagation for free (the human is the authority), audit for free (the human decided), and failure semantics for free (the human notices and stops). Those are the four hard problems, solved by one person doing thirty seconds of copy-paste. Replacing that person with automation means rebuilding all four properly.
The question isn't whether human-in-the-loop is embarrassing. It's whether that handoff is your bottleneck. If it happens twice a day, automating it is a hobby project. If it happens four hundred times a day, it's the whole ballgame.
What I actually run
My own engineering work runs on an orchestrator pattern, and my experience matches the trade-offs above more than I expected. The full setup and its numbers are in the case study; here is the part relevant to orchestration.
One session acts as a router. It does not edit code. It classifies a request, writes a self-contained brief, and dispatches it to a separate agent session. Every session ends with a written handoff so the next one can start cold. The handoff is a document, not shared memory, and that is the main reason it works: the trust boundary is one hop deep and I can read exactly what crossed it.
Three things went wrong, and each maps to one of the five requirements:
- Shared mutable state. Parallel sessions sharing one git checkout overwrote each other's work more than once. Two agents modifying the same thing don't have a merge conflict, they have a disagreement, and neither of them knows it happened. Each session now gets its own worktree.
- Drift at the orchestrator. When I reviewed the logs, my "never does heavy work" router had run 19 of the last 30 sessions and used 30% of all tokens in two weeks, with one conversation past 800 turns. The orchestrator-as-bottleneck problem is real, and it creeps. I added a hard "orchestrate, never edit" rule and a fresh session every 40 turns.
- Untrusted text crossing boundaries. Agents read a lot of email, chat and ticket text written by other people. A standing rule treats that text as data, never instructions. It is a crude answer to the identity problem, but it closes the most obvious confused-deputy path: a stranger's ticket telling an agent what to do.
Standardise the tools before you orchestrate the agents. When every agent needs its own bespoke integration to the same system, adding the next agent means duplicating work and multiplying credentials. A common tool layer turns "add an agent" into "grant access to existing tools," which is the difference between orchestration being a project and orchestration being a configuration change.
The counterargument, which is strong
Isolated agents are frequently the right call, and the push toward orchestration is partly vendors selling a harder problem.
Connecting twelve agents gives you a distributed system with every classic failure mode (partial failure, cascading retries, unclear causality) plus non-determinism at every node. You've made debugging harder in ways your existing operational experience does not cover. A retry storm between deterministic services is bad. A retry storm between agents that each reason slightly differently about whether to retry is genuinely novel and unpleasant.
I'd argue most organisations with one excellent isolated agent are ahead of most organisations with twelve chatty ones. The Salesforce number gets read as "half your agents are underperforming." It might equally read as "half your agents are scoped sensibly and half have accumulated integrations nobody audits."
Orchestrate when the handoff is measurably the bottleneck. Not because the architecture diagram looks more impressive with lines on it.
If you have a pile of isolated agents
A sequence, in this order, because the order matters:
- Inventory them. Many organisations running twelve agents could not produce a list of twelve agents. Start there: what exists, who owns it, what it can touch.
- Find the handoffs humans are doing by hand. These are your actual integration requirements, and they're already documented in people's habits. Count them. Frequency is the whole argument.
- Standardise the tool layer before the orchestration layer. MCP or equivalent. This is the step people skip and the one that determines whether the next step is possible.
- Solve identity before you solve autonomy. Decide explicitly whose authority an agent acts under when called by another agent. Write it down. If you can't answer it, you aren't ready to connect them, and connecting them anyway is how you get a confused-deputy incident.
- Add tracing before you add autonomy. You want the trace infrastructure in place before the first cross-agent incident, not after.
- Then connect the highest-frequency handoff. One. Measure whether it helped.
Most of that list is unglamorous platform work with no demo. That's not incidental. It's why the connectivity half of the statistic exists while the twelve-agents half keeps climbing. Buying an agent is a purchase order. Connecting agents is a platform team.
My prediction, stated as one: 2027's agent spend goes to orchestration and the identity layer underneath it, and the organisations that win at it will look like infrastructure teams rather than AI teams. The capability problem is largely solved. The plumbing problem is wide open, and plumbing is where the money has always gone.
Related Reading
Enjoying this article?
Get posts like this in your inbox. No spam, unsubscribe anytime.
