For the past decade, we've built AI systems around a simple model: send a request to a central orchestrator, which routes it to specialized services. A user query goes to a dispatcher, which decides whether to call a search agent, a coding agent, or a database query agent. Clean. Synchronous. Centralized.

That architecture is breaking at scale.

As enterprise deployments demand more sophistication — routing decisions across dozens of specialized agents, handling long-running workflows, enabling agents to discover and negotiate with peers on the fly — the centralized orchestrator becomes a bottleneck, a single point of failure, and a coordination nightmare. What if agents could talk directly to each other, discover capabilities dynamically, and collaborate without waiting for a central authority?

Three protocols are leading this shift: Google's Agent-to-Agent (A2A), Anthropic's Model Context Protocol (MCP), and Amazon's Agent Client Protocol (ACP). Each takes a different architectural approach to the same problem: how can autonomous systems exchange information, negotiate tasks, and compose capabilities in real-time?

In this article — drawing from Building Agentic AI Systems and hands-on implementation experience — I'll dissect these three protocols, explain their topology and trade-offs, and show you how emerging collaboration patterns are reshaping enterprise architecture.

The Problem with Centralized Orchestration

Before diving into the protocols, let's be clear about why we need them. Consider a typical enterprise agentic system circa 2024:

This works for simple pipelines. But as systems grow, several problems emerge:

Orchestration Bottlenecks

Single point of routing failure: If the orchestrator can't decide which agent handles a query, the entire request stalls. No direct agent-to-agent discovery: Agents can't learn about each other's capabilities without the orchestrator's explicit permission. Latency accumulation: Every request bounces through the orchestrator, adding round-trip overhead. State coordination: The orchestrator must maintain shared state across all agents, which doesn't scale beyond a few dozen services.

What happens when Agent A completes its work and discovers that Agent B (which it's never heard of) has exactly the capability it needs next? In a centralized model, Agent A can't call Agent B directly — it must return control to the orchestrator, wait for permission, and then invoke Agent B. In a decentralized model, agents negotiate peer-to-peer.

Google's Agent-to-Agent (A2A) Protocol

Google's A2A protocol (announced as part of their broader GenAI stack) takes a direct peer-to-peer approach. Rather than funneling all communication through a central authority, agents publish their capabilities and communicate directly when needed.

Architecture and Topology

A2A operates as a flat topology with capability discovery via a shared registry:

Here's a conceptual example: Imagine a financial analysis system with three agents: 

# Agent Registry (shared, discoverable)
{
  "agents": [
    {
      "id": "market-data-agent",
      "capabilities": ["fetch_stock_price", "fetch_market_indices"],
      "endpoint": "https://agents.corp.com/market-data",
      "requires_auth": true
    },
    {
      "id": "analysis-agent",
      "capabilities": ["compute_correlation", "regression_analysis"],
      "endpoint": "https://agents.corp.com/analysis",
      "requires_auth": true
    },
    {
      "id": "reporting-agent",
      "capabilities": ["generate_pdf_report", "send_to_stakeholder"],
      "endpoint": "https://agents.corp.com/reporting",
      "requires_auth": true
    }
  ]
}

When a user asks "Correlate Apple stock with the Nasdaq index and send me a report," the system doesn't invoke a central orchestrator. Instead:

  1. Analysis agent queries the registry, finds the market-data-agent
  2. Analysis agent calls market-data-agent directly, requesting stock and index prices
  3. Analysis agent computes correlation and queries registry for reporting capabilities
  4. Analysis agent calls reporting-agent directly with the analysis results
  5. Reporting agent generates the PDF and sends it

Strengths of A2A

Limitations

Anthropic's Model Context Protocol (MCP)

Anthropic's MCP takes a fundamentally different approach. Rather than agent-to-agent communication, MCP defines how LLMs (or other reasoning engines) interact with external tools and data sources. It's less about horizontal agent-agent networking and more about vertical capability exposure.

Architecture and Topology

MCP operates as a client-server model where the "client" is typically an LLM application and the "server" is a data source, tool provider, or external system:

Think of MCP as a protocol for "teaching an LLM about your organization's data and systems." Instead of embedding tool-calling logic in the LLM itself, you provide an MCP server that the LLM can query: 

# MCP Server advertises resources and tools
{
  "resources": [
    {
      "uri": "notion://database/projects",
      "name": "Current Projects",
      "description": "Live project database from Notion"
    },
    {
      "uri": "slack://channels",
      "name": "Slack Channels",
      "description": "Indexed Slack messages and channels"
    }
  ],
  "tools": [
    {
      "name": "search_documents",
      "description": "Search across all company documents",
      "input_schema": {
        "type": "object",
        "properties": {
          "query": {"type": "string"},
          "limit": {"type": "integer", "default": 10}
        }
      }
    }
  ]
}

When an LLM needs to answer a question, it can query the MCP server for relevant resources, incorporate them into its context window, and reason over them. For example:

  1. LLM receives query: "What are our current blockers in the Q4 roadmap?"
  2. LLM calls MCP client: "Fetch resources from notion://database/projects"
  3. MCP client queries MCP server: Server returns current project data from Notion
  4. MCP server returns resources: Project status, blockers, team assignments
  5. LLM reasons over context: Integrates project data into its reasoning and generates an answer

Strengths of MCP

Limitations

Amazon's Agent Client Protocol (ACP)

Amazon's ACP (integrated into Bedrock and other AWS services) aims to bridge the gap between orchestration and decentralization. It defines how agents and supervisory systems coordinate task delegation — with support for both synchronous and asynchronous workflows.

Architecture and Topology

ACP operates as a hierarchical but flexible topology:

Here's how ACP orchestrates a customer support workflow: 

# Agent publishes capability contract
{
  "agent_id": "sentiment-classifier",
  "version": "1.0",
  "capabilities": [
    {
      "name": "classify_sentiment",
      "input": {
        "text": "string",
        "language": "string"
      },
      "output": {
        "sentiment": "positive|negative|neutral",
        "confidence": "number",
        "key_entities": "[string]"
      },
      "sla": {
        "max_duration_ms": 500,
        "availability": 0.999
      }
    }
  ]
}

# Supervisor invokes worker agent with callback
POST /agents/invoke
{
  "target_agent": "sentiment-classifier",
  "capability": "classify_sentiment",
  "input": {"text": "Your service is terrible", "language": "en"},
  "callback_url": "https://supervisor.corp/agent-callback"
}

# Worker responds asynchronously
POST https://supervisor.corp/agent-callback
{
  "request_id": "req-123",
  "sentiment": "negative",
  "confidence": 0.97,
  "key_entities": ["service", "terrible"]
}

Strengths of ACP

Limitations

Protocol Comparison: A2A vs. MCP vs. ACP

Aspect A2A (Google) MCP (Anthropic) ACP (Amazon)
Primary Use Case Agent-to-agent peer communication LLM context provisioning Supervisor-worker task delegation
Topology Flat, peer-to-peer via registry Client-server (LLM as client) Hierarchical with peer options
Discovery Shared capability registry Explicit server configuration Contract-based advertisement
State Management Distributed; agents own their state Stateless (LLM context-driven) Centralized for supervisor workflows
Synchrony Model Primarily synchronous Synchronous request-response Both sync and async with callbacks
Security Model Per-agent authentication Client-server mutual auth IAM-based with fine-grained permissions
Fault Tolerance Agent-level retry logic LLM-driven error handling Protocol-level retries & fallbacks
Industry Maturity Early; under active development Stable; community adoption growing Production-ready in AWS; nascent elsewhere

Emergent Collaboration Patterns

As these protocols mature, new collaboration patterns are emerging that go beyond simple request-response:

Task Delegation and Negotiation

Rather than a supervisor assigning work, agents can propose and negotiate task boundaries. Agent A might offer a service, Agent B might counter-offer a modified version, and they settle on a contract: 

# Agent A proposes: "I can process orders up to $10K in 100ms"
# Agent B responds: "I can process orders up to $50K but need 500ms"
# Result: They establish a contract:
#   - A handles small orders (< $10K)
#   - B handles large orders ($10K - $50K)
#   - Both agree on retry policies and fallback chains

Voting and Consensus

Multiple specialized agents can vote on ambiguous decisions. For example, three sentiment analysis agents might disagree on a customer feedback score. A supervisor can collect their votes and use the consensus to guide downstream actions:

Dynamic Service Composition

Agents discover each other's capabilities at runtime and compose new services. If a user asks for something that requires three capabilities your system wasn't explicitly built for, agents can chain together in real-time:

  1. Query the registry: "Who can extract tables from PDFs?"
  2. Discover: "PDF-Parser can do that"
  3. Query the registry: "Who can analyze financial data?"
  4. Discover: "FinanceAnalyzer can do that"
  5. Compose: "PDF-Parser → FinanceAnalyzer → ReportGenerator"
  6. Execute: The chain runs automatically with data flowing through each stage
The Multi-Agent Internet Vision

These protocols are laying the foundation for a "multi-agent internet" where specialized AI services run autonomously, discover each other on demand, and compose into increasingly sophisticated systems. Think of it as microservices for AI: modular, scalable, and inherently decentralized.

Interoperability Challenges

Despite the promise, bringing these protocols together poses significant challenges:

Semantic Incompatibility

Each protocol has a different model of what "capability" means:

Bridging these requires translation layers. An A2A agent's "compute_score(input)" might map to an MCP tool, but the semantics (what does the score mean? what are the SLAs?) don't translate automatically.

Negotiation and Versioning

When an Agent A expects input format V2 but Agent B only publishes V1, how do they communicate? Each protocol handles versioning differently, and there's no universal agreement on backward compatibility.

Trust and Authorization

In a fully decentralized multi-agent internet, how do you prevent a rogue agent from spoofing another's identity or accessing privileged resources? Each protocol assumes different trust models (mutual TLS, OAuth, IAM), and mixing them requires careful security architecture.

How These Protocols Change Enterprise Architecture

If you're building agentic systems at scale, these protocols reshape your architecture in three ways:

1. From Monolithic Orchestrators to Distributed Choreography

Instead of a single master orchestrator deciding the workflow, agents negotiate directly. This reduces latency, improves fault isolation, and allows independent scaling of agent services.

2. From Tool Integration to Context Integration

Rather than coding tool-calling logic into agents, you expose your data and systems as MCP servers or capability contracts. This decouples the reasoning engine from operational details.

3. From Synchronous Pipelines to Asynchronous Event Networks

Protocols like ACP enable truly asynchronous, long-running workflows where agents can queue work, receive callbacks, and react to events — rather than blocking on every request.

Security and Trust Between Agents

Decentralization introduces trust challenges. How do you ensure that:

Best practices emerging from production deployments:

Key Takeaways

The move from centralized orchestration to protocol-driven agent networking is reshaping how we build AI systems at scale:

These protocols are in the earliest stages of production adoption, and the multi-agent internet is still being written. But the trajectory is clear: the next era of agentic AI isn't about better LLMs in isolation — it's about intelligent systems that discover each other, negotiate capabilities, and compose into emergent solutions. The protocols enabling this shift are A2A, MCP, and ACP. Understanding their trade-offs and when to apply each is now table stakes for building enterprise agentic systems.

For deeper technical dives, implementations, and case studies, see Building Agentic AI Systems (Chapters 7-9, which cover distributed coordination, capability contracts, and multi-agent composition).