Agent Protocols

MCP solves how a model talks to tools. A different problem is how agents talk to each other — across processes, organizations, and trust domains. Several protocols are competing to be the standard there. None has fully won yet; understanding the shape of the space matters more than picking a single one.

The Problem

A growing class of work involves multiple agents, often built by different teams or vendors, cooperating on a task:

• A sales agent in your CRM hands off to a billing agent in your finance stack.
• A travel planning agent contracts with a separate booking agent for execution.
• A user-facing assistant delegates a sub-task to a specialist agent in another company's system.

Without a standard, every pairing is a custom integration. With a standard, agents can discover, authenticate, and cooperate across organizational boundaries the way services do over HTTP.

What an Agent Protocol Specifies

A useful agent-to-agent protocol covers:

• Discovery. How does agent A know what agent B can do?
• Capability description. What format is the "API surface" of the agent?
• Invocation. How does A actually ask B to do something?
• State and async. Long-running tasks, partial results, status updates.
• Authentication. Who is A, what is A authorized to ask of B?
• Trust and provenance. How does B know the request really came from A and on whose behalf?
• Error handling. What does failure look like, and how does A recover?

This is harder than it sounds. A2A protocols are still working through the pieces.

The Major Protocols

A2A (Agent-to-Agent Protocol). Originally proposed by Google. Cross-organization agent communication, with capability cards, message formats, and authentication. Aimed at cross-vendor agent ecosystems. Adoption is growing among enterprise platforms.

MCP for sub-agents. MCP is gaining primitives that overlap with A2A territory — agents exposed as MCP servers, sub-agent invocation, etc. Some of the agent-to-agent space is being absorbed into MCP rather than living in a separate protocol.

ACP (Agent Communication Protocol). Linux Foundation effort, broader ambitions around agent networking. More aspirational than deployed.

Native multi-agent frameworks. Within frameworks like LangGraph, CrewAI, AutoGen, agents communicate over framework-specific protocols. Not interoperable across frameworks.

Just APIs. The default. Agents call each other's HTTP APIs with custom auth and message formats. Not standardized, works fine for known partners.

Where Agent Protocols Actually Matter

• Marketplaces. "An ecosystem of agents you can hire" requires a protocol; bilateral integrations don't scale.
• Cross-vendor automation. When the tool vendor and the agent vendor are different companies and want to interoperate.
• Enterprise composition. Large organizations where different teams ship different agents that need to cooperate.
• Open-source ecosystems. Where contributors want their agents to plug into anyone's stack.

Where They Don't (Yet)

For most teams today, an internal agent protocol is overkill:

• A single team building a single agent? Direct function calls.
• A few cooperating agents in one codebase? A framework's native protocol is plenty.
• Tool integrations? MCP is the right answer, not an A2A protocol.

You reach for an agent-to-agent protocol when crossing trust boundaries — different teams, different companies, different deployment environments — and you specifically need standardization.

Identity and Trust

The hardest unsolved problem isn't the wire format; it's identity:

• Who is the agent acting on behalf of? A user? A team? A service account?
• What can it authorize? Spending money, sending email, deleting data — each has different stakes.
• How is consent captured? When the user okays "let agent A delegate to agent B," what specifically did they approve?
• How is the chain audited? When something goes wrong, can you reconstruct who asked whom to do what?

Existing identity standards (OAuth, OIDC, SPIFFE) can be adapted — and proposals are emerging for agent-specific extensions — but the practice is unsettled.

Privacy Across Boundaries

When agent A sends data to agent B in a different organization, you've created a data flow that may need:

• Disclosure to the user.
• Compliance review for sensitive data.
• Retention rules different from either system's defaults.
• Right-to-delete that propagates across systems.

The protocol can help, but the policy work is the harder half.

Failure Modes Specific to Multi-Agent Systems

• Cascading errors. Agent A relies on B, B fails, A makes things worse trying to recover.
• Coordination loops. Two agents handing work back and forth, neither completing.
• Contradictory authority. When two agents disagree, who wins?
• Cost blow-ups. Each cross-agent message is more tokens; multi-agent loops are how you discover unbounded spend.

Hard limits on turns, depth, and cost matter even more in cross-agent settings.

A Pragmatic Stance

The agent protocol space is in roughly the same shape that web services were in the early 2000s — multiple competing standards, real interoperability gaps, lots of vendor positioning. For most teams in 2025:

• Use MCP for tool and data integration. It's settled enough to bet on.
• Use direct APIs or a framework for in-house agent communication. Standards aren't yet worth the integration cost.
• Watch A2A if you're building cross-vendor agent products. It's the most likely winner in that space.
• Don't over-invest in protocol-level standardization until you're crossing real organizational boundaries.

The answer in two years may look very different. For now, plan for evolution.