Most multi-agent system tutorials assume your agents all live in the same codebase, share the same memory, and trust each other implicitly. That’s fine for demos. Production is different. In production, you have an AI agent that needs to call an agent your supplier built, or coordinate with a workflow owned by a different team that runs on completely separate infrastructure. And suddenly the question of how agents actually talk to each other — across trust boundaries, without sharing internals — becomes genuinely hard.

That’s the problem the Agent-to-Agent (A2A) protocol is designed to solve. Google released A2A in early 2026, and it’s been gaining traction quickly because it addresses something that MCP (Model Context Protocol) explicitly doesn’t: the agent-to-agent layer rather than the agent-to-tool layer.

What A2A Actually Does

A2A is a communication protocol that lets agents expose their capabilities to other agents and coordinate tasks without requiring either side to know anything about the other’s implementation. Think of it as an HTTP-style interface contract for AI agents.

Each A2A-compatible agent publishes an “agent card” — a JSON document describing what the agent can do, how to call it, and what authentication it expects. An orchestrating agent can discover these cards, understand available capabilities, and delegate tasks accordingly. The delegated agent handles its own tool access, its own context, and its own execution. The orchestrator doesn’t need to know any of that.

The key difference from just calling an API directly: A2A handles the turn-based, streaming, long-running-task nature of agent interactions. An agent task might take seconds or minutes. It might stream intermediate results. It might need to ask a clarifying question mid-task. A2A provides the message protocol for all of this, including task lifecycle management (pending, running, completed, failed) and streaming output.

A Simple Example: Cross-Team Coordination

Say you’re building a procurement automation agent. It needs to check supplier pricing with a supplier’s own agent, cross-reference with internal inventory via your company’s stock agent, and then raise a purchase order through your finance team’s approvals agent.

Without a shared protocol, you’re writing custom integration code for each. With A2A, each of those systems publishes an agent card, your orchestrating agent discovers them, and the coordination happens through a standard message exchange. The supplier’s agent doesn’t expose your internal pricing logic. Your finance agent doesn’t share its approval rules with the supplier. Each side retains its own context and access controls.

from a2a_sdk import AgentClient, Task

# Discover and call a supplier pricing agent
supplier_agent = AgentClient("https://api.supplier.com/.well-known/agent.json")
task = await supplier_agent.submit_task(
    message="Get current pricing for SKU-4821, quantity 500",
    auth_token=get_bearer_token("supplier-agent")
)

async for event in task.stream():
    if event.type == "result":
        pricing_data = event.content

The supplier agent handles its own authentication to its own systems. Your agent only sees the result.

Authentication Across Trust Boundaries

This is where it gets interesting, and where a lot of A2A implementations cut corners. If agents are calling each other across organisational boundaries, you need proper token-based authentication. OAuth 2.0 Client Credentials Flow is the right model: each agent has its own identity, and tokens are scoped to the specific capabilities the calling agent is authorised to access.

The agent card specifies what authentication the agent expects:

{
  "name": "Supplier Pricing Agent",
  "url": "https://api.supplier.com/a2a",
  "authentication": {
    "type": "oauth2",
    "flows": {
      "clientCredentials": {
        "tokenUrl": "https://auth.supplier.com/oauth/token",
        "scopes": {
          "pricing:read": "Read current pricing data",
          "pricing:quote": "Request formal quotation"
        }
      }
    }
  }
}

Your orchestrating agent requests only the scope it needs. If it’s compromised or produces unexpected output, the damage is bounded.

Where A2A Fits With MCP

The two protocols are complementary, not competing. MCP connects agents to tools: databases, APIs, file systems, external services. A2A connects agents to other agents.

A common pattern in 2026 enterprise deployments: an orchestrating agent uses MCP to access its own tools (internal APIs, document stores, calendaring), and uses A2A to delegate specialist tasks to other agents that have their own MCP-connected tool sets. The orchestrator doesn’t need to know anything about how the downstream agents implement their capabilities.

This is a cleaner separation than trying to model everything as MCP tools. An agent is not a tool: it has its own reasoning, its own state management, and its own execution model. Treating agent-to-agent calls as tool calls muddies that abstraction.

Things to Watch

A2A is still maturing. A few gaps worth knowing about.

Agent card discovery is informal — there’s no equivalent of a DNS-style registry for finding agents. Right now, you typically know the agent card URL out of band. Standard discovery infrastructure will come, but isn’t here yet.

Audit and observability are harder across agent boundaries. When something goes wrong in a multi-agent workflow, tracing the decision back across multiple agents is non-trivial. Build logging at the A2A call boundaries in your orchestrators.

The protocol handles task lifecycle but not task result validation. An agent that returns a plausible-looking but incorrect result is indistinguishable from a correct one without your own validation logic. Don’t assume downstream agent outputs are correct just because the task succeeded.

For teams starting to build cross-system agent workflows in 2026, A2A is the most promising substrate. It’s not perfect yet, but it’s the first protocol that takes the cross-boundary problem seriously enough to model agent identity, authentication, and long-running task coordination properly.