Agent-to-Agent Communication: The Protocol Problem Nobody Has Solved Yet
Something interesting is happening in AI infrastructure that doesn’t get enough attention: the question of how AI agents talk to each other.
Not how humans talk to AI agents. That problem, while imperfect, has well-established patterns through natural language interfaces, APIs, and tool-use frameworks. The harder problem is what happens when an AI agent needs to delegate a task to another agent, coordinate work across multiple agents, or verify another agent’s output.
This isn’t hypothetical. Multi-agent systems are being deployed in production environments right now. Customer service architectures where a routing agent hands off to specialist agents. Research workflows where a planning agent coordinates data gathering, analysis, and synthesis agents. Software development tools where coding agents collaborate with testing and review agents.
What’s lacking is any kind of standard for how these agents communicate. And that’s becoming a real problem.
The Current State of Affairs
Most multi-agent systems today use one of three approaches to inter-agent communication, and none of them is satisfactory.
Shared Context Windows
The simplest approach: agents communicate by reading and writing to a shared text document or message log. Agent A writes its output. Agent B reads it, does its work, and appends its output. Agent C reads everything and synthesises.
This works for simple sequential workflows but fails as complexity increases. Context windows have finite length. As the conversation grows, earlier information gets truncated or compressed. There’s no structured way to express task delegation, status updates, or error conditions. And the approach is inherently synchronous, each agent waits for the previous one to finish.
AutoGen, Microsoft’s multi-agent framework, uses a variation of this approach with conversation patterns that define how agents take turns. It’s effective for many use cases but doesn’t address the fundamental limitations of text-based communication between agents.
Function Calling and Tool Use
Agents communicate by calling each other as tools. Agent A invokes Agent B through a function call, passing structured parameters and receiving a structured response. This provides type safety, clear input/output contracts, and supports synchronous and asynchronous patterns.
The limitation is rigidity. Function signatures must be defined in advance. When Agent A needs to ask Agent B a question that wasn’t anticipated in the interface design, it can’t. The communication channel is constrained to pre-defined parameter shapes, which limits the agents’ ability to negotiate, clarify, or handle unexpected situations.
Custom Protocols
Some multi-agent frameworks define their own communication protocols with message types, routing, and state management. LangGraph and CrewAI have built protocol layers that handle task assignment, progress reporting, and result aggregation.
These work well within their respective ecosystems but are incompatible with each other. An agent built in LangGraph can’t natively communicate with an agent built in CrewAI. This fragmentation is the core of the protocol problem.
Why Standards Matter
The agent communication problem mirrors the early internet before TCP/IP and HTTP provided common protocols. Different networks existed but couldn’t easily communicate with each other. Standardisation enabled the explosive growth of interconnected services.
For AI agents, the same dynamic applies but with additional complexity.
Interoperability: As organisations deploy agents from different vendors and frameworks, those agents need to work together. A procurement agent from one system needs to communicate with an approval agent from another. Without standard protocols, every integration is custom engineering.
Trust and verification: When Agent A delegates a task to Agent B, how does A verify that B actually completed the task correctly? How does A know that B’s capabilities match the requirements? Human-readable output isn’t sufficient for automated verification.
Error handling: When an agent fails, how does it communicate the failure mode to other agents? How do dependent agents adapt? Current approaches to agent error handling are primitive compared to what’s needed for reliable production systems.
Scalability: Text-based shared context doesn’t scale to systems with dozens or hundreds of agents. Structured communication protocols with efficient serialisation are necessary for large-scale agent orchestration.
Emerging Approaches
Several initiatives are attempting to address the protocol gap.
Anthropic’s Model Context Protocol (MCP)
MCP provides a standardised way for AI models to interact with external tools and data sources. While not specifically designed for agent-to-agent communication, it establishes patterns for structured interaction that could extend to inter-agent protocols.
OpenAI’s Function Calling Extensions
OpenAI has progressively extended their function calling capabilities toward supporting multi-step agent workflows. Their recent updates include structured output guarantees and parallel function execution, which move toward the reliability needed for agent-to-agent communication.
FIPA Standards
The Foundation for Intelligent Physical Agents published agent communication language standards decades ago for traditional multi-agent systems. While these standards pre-date LLM-based agents, some researchers are revisiting FIPA concepts as a foundation for modern agent communication protocols.
Agent Protocol Proposals
Google DeepMind and other research labs have published proposals for agent communication protocols that include message typing, capability discovery, task delegation schemas, and result verification mechanisms. These are academic at this stage but represent serious thinking about the requirements.
What’s Actually Needed
Based on observing production multi-agent systems, a viable agent communication protocol needs to support several capabilities.
Capability advertisement: Agents need to declare what they can do in a machine-readable format, so other agents can determine who to delegate to without human configuration.
Task delegation with constraints: Agent A needs to tell Agent B not just what to do, but what constraints apply: time limits, resource limits, quality thresholds, and escalation conditions.
Progressive disclosure: An agent should be able to request additional information or clarification mid-task without restarting the entire workflow. This requires conversational capability within a structured protocol.
Verifiable outputs: Agent outputs need to include sufficient metadata for other agents to verify quality and correctness without re-doing the work.
Graceful degradation: When an agent fails or is unavailable, the protocol needs to support fallback strategies, retry logic, and partial result handling.
The Timeline Question
When will we have a standard agent communication protocol? The honest answer is: not soon. The technology is evolving too fast for standards bodies to keep up, and the diversity of agent architectures makes one-size-fits-all standardisation premature.
What’s more likely is de facto standardisation around a few dominant frameworks, similar to how REST became the dominant web API pattern not through formal standardisation but through widespread adoption. Whichever framework achieves critical mass in enterprise agent deployments will likely define the communication patterns that others adopt or adapt.
For organisations building multi-agent systems today, the pragmatic approach is to abstract agent communication behind well-defined interfaces that can adapt as standards emerge. Design your agents to be protocol-agnostic wherever possible. The protocol landscape will look very different in two years, and flexibility now prevents costly re-engineering later.