Your agents don't talk to each other

Everyone's building AI agents. Almost nobody is building the communication layer between them. The result is a fleet of individually smart systems that can't coordinate, share context, or even acknowledge each other's existence. We're recreating the worst parts of enterprise software, one autonomous agent at a time. If you run more than a handful of agents, you've already felt this. The blog ideator doesn't know what the drafter just wrote. The expense tracker has no idea what's on the calendar. Each agent is brilliant in isolation and oblivious in practice. The "one agent, one job" philosophy is right, but it creates a problem nobody wants to talk about: how do a dozen agents share context without a human copy-pasting in the middle?

The single-agent trap

Most agent frameworks today are designed around a single-agent loop. ReAct, tool use, chain-of-thought, all of these patterns assume one agent reasoning about one task. Frameworks like LangChain, CrewAI, and AutoGen have made it remarkably easy to build a capable individual agent. But the moment you need two agents to work together, you're on your own. This isn't a minor gap. Research presented at ICLR 2026 specifically catalogued multi-agent failure modes: latency spikes, compounding token costs, error cascades through pipelines, and near-zero observability when something breaks. As one analysis put it, "when something breaks, you often have no idea why." The papers identified five core problem areas: brittle topologies, unreliable communication, context drift, scalability bottlenecks, and the near-total absence of debugging tools for multi-agent systems. The fundamental issue is that orchestration was an afterthought. We built the agents first and assumed coordination would sort itself out. It hasn't.

MCP is a step, not a solution

The Model Context Protocol (MCP) has been a genuine improvement for one specific problem: giving agents standardized access to tools and data. Instead of writing custom integrations for every API, MCP provides a JSON-RPC client-server interface where agents can discover and invoke tools in a structured way. That's valuable. But MCP solves vertical connectivity, how a single agent connects to external resources. It doesn't solve horizontal connectivity, how agents talk to each other. An agent using MCP can query a database or call an API, but it can't ask another agent what it just did, what it learned, or what it's about to do. MCP gives individual agents superpowers. It doesn't give them teammates. There are also practical limitations. MCP establishes stateful sessions between clients and servers, which creates scaling challenges. Each server maintains context for every client session. In regulated industries, MCP's flexible context-sharing model can introduce security vulnerabilities, particularly around encryption and data governance. These aren't dealbreakers for single-agent use, but they compound quickly when you're trying to wire agents together.

The integration problem, again

If you've spent any time in enterprise software, this pattern looks painfully familiar. We've been here before with microservices, with SaaS tools, with data pipelines. Every time we decompose a monolith into specialized components, we underestimate how hard it is to make those components talk to each other. The early days of microservices produced the same chaos: services that couldn't discover each other, incompatible data formats, cascading failures, and debugging nightmares. It took years of investment in service meshes, API gateways, and observability platforms to make microservices workable at scale. Agents are repeating this cycle, but with additional complexity. Unlike microservices, agents are non-deterministic. Their outputs vary. They make judgment calls. Two agents given the same input might produce different results, which makes coordination exponentially harder than routing HTTP requests between containers. The enterprise integration middleware market, Zapier, MuleSoft, Workato, exists precisely because connecting specialized systems is genuinely hard. "Zapier for agents" is coming, and it'll probably be just as fragile, because the underlying problem isn't tooling. It's that autonomous systems are fundamentally harder to coordinate than deterministic APIs.

What real interop might look like

Several approaches are emerging, though none are mature enough to call solutions yet. Agent2Agent Protocol (A2A). Google launched A2A in April 2025 with backing from over 50 technology partners including Salesforce, SAP, Atlassian, and ServiceNow. A2A is designed specifically for agent-to-agent communication: agents can discover each other's capabilities through "Agent Cards," negotiate interaction modalities, and collaborate on long-running tasks without exposing internal state. It uses standard web technologies (JSON-RPC 2.0, HTTP, server-sent events) and is now under Linux Foundation governance. A2A is explicitly complementary to MCP: MCP handles agent-to-tool, A2A handles agent-to-agent. Agent Communication Protocol (ACP). IBM's contribution through the Linux Foundation takes a REST-native approach with support for multimodal messages, asynchronous streaming, and capability-based security tokens. ACP focuses on enterprise-scale orchestration where agents need structured task invocation and lifecycle management. Shared memory architectures. Some teams are building coordination around shared state stores with access controls. The idea is that agents write to and read from a common memory layer, with permissions governing who can see and modify what. Research on multi-agent coordination suggests this can prevent context drift, where agents gradually diverge because they're working with stale information. The tradeoff is complexity: access control in a shared memory system between non-deterministic agents is a hard problem. Event-driven architectures. Event buses, like those built on Apache Kafka or Apache Pulsar, let agents subscribe to specific event types and react when something relevant happens. Instead of polling or direct calls, agents publish state changes that other agents can consume. This approach can reduce latency by 70-90% compared to polling, but it introduces its own challenges around event ordering, exactly-once delivery, and schema evolution. Each of these approaches solves part of the problem. None of them solve the whole thing. The honest assessment is that we're still in the "let a hundred flowers bloom" phase, figuring out which patterns survive contact with production.

The security problem nobody wants to discuss

Here's where it gets uncomfortable. Agent-to-agent communication isn't just an engineering challenge. It's a security nightmare. Traditional lateral movement in cybersecurity means an attacker compromises one system and pivots to others through network connections or stolen credentials. AI agents create a new variant: they bridge isolated systems through delegated authority and tool access, without needing new network paths or stolen credentials. Security researchers have coined the term AILM (AI-Induced Lateral Movement) to describe this pattern, and multiple frameworks including OWASP now explicitly cover multi-agent attack scenarios. The threat model is straightforward. If a compromised or manipulated agent can communicate with other agents, it can potentially escalate privileges, exfiltrate data, or trigger unauthorized actions across systems that were never meant to be connected. A scheduling agent that gets fed a malicious prompt could request patient records from a clinical data agent by falsely claiming physician-level access. A logic error in one agent cascades through a chain, with each downstream agent trusting the output of the one before it. Least-privilege access, the standard defense, gets dramatically harder in multi-agent systems. With a single agent, you scope its permissions tightly. With thirteen agents that need to share context, every communication channel is a potential attack surface. You need agent identity verification, message-level authentication, taint tracking to follow data provenance, and circuit breakers to prevent cascade failures. Most production deployments today have none of this. A 2026 SailPoint-commissioned study found that 96% of tech leaders agree AI agents are a growing security threat, yet fewer than half have policies to manage them. The gap between awareness and action is enormous.

What to do right now

If you're building or managing multiple agents today, a few things are worth doing even while the ecosystem figures itself out. Define explicit boundaries. Every agent should have a clear, documented scope of what it can and cannot do. This isn't just good architecture, it's the foundation for security. When agents need to share information, the boundary crossing should be intentional and logged. Treat agent outputs as untrusted input. If Agent A passes data to Agent B, Agent B should validate it the same way it would validate user input. The trust boundary isn't between your system and the outside world. It's between every agent in your system. Invest in observability early. You need message trace logging across agent interactions, clear audit trails, and the ability to replay agent-to-agent exchanges when debugging. If you can't see what your agents are saying to each other, you can't fix problems or detect compromise. Start with the protocols that exist. A2A and ACP aren't perfect, but they're better than custom point-to-point integrations. If your agents need to coordinate, building on emerging standards gives you a migration path as the ecosystem matures. Accept that this is hard. Multi-agent coordination is genuinely one of the harder problems in the current AI landscape. ICLR 2026 had an unusual concentration of papers on exactly this topic, which suggests the research community recognizes it too. Don't let anyone tell you it's a solved problem. The teams doing interesting work here are the ones who acknowledge the difficulty and build defensively. The agents are getting smarter every quarter. The connections between them are barely getting started. That gap is where the next wave of real engineering work lives.