How Do Agents Talk to Each Other? A2A and Agent Protocols

// In plain English

When you build a multi-agent system inside a single codebase, agents can call each other directly because you control every piece. But what happens when the agent that handles your HR data lives on Workday, the agent that manages your helpdesk tickets lives on ServiceNow, and the agent orchestrating the whole workflow lives on a completely different platform? Without a shared standard, those agents are strangers — they have no common language for advertising what they can do, handing off a task, or reporting back a result.

That is the problem agent-to-agent (A2A) protocols solve. A2A is an open specification — announced by Google in April 2025 and donated to the Linux Foundation in June 2025 — that defines a common language for independently built agents to discover each other, delegate tasks, and exchange results over the open web. Think of it like HTTP for web pages: any browser can load any website because both sides speak the same protocol. A2A aims to do the same for AI agents.

A useful analogy is the international postal system. If you want to send a package from Japan to Brazil, neither country's postal service needs a custom arrangement with the other. They both follow shared addressing rules and handoff conventions. A2A does the same for agents: an agent from Salesforce can hand a task to an agent from SAP without either team writing custom glue code, because both sides follow the same envelope format and delivery rules.

// Why it matters

Before A2A, enterprise teams building multi-agent systems faced a fragmentation tax. Every pair of agents from different vendors required its own hand-rolled connector. A Salesforce agent delegating to a ServiceNow agent needed custom code. An AWS Bedrock agent talking to a Google Vertex agent needed a bridge. With five agents from five vendors you had potentially ten bespoke integrations to build, test, and maintain.

That fragmentation breaks the promise of composable AI. The pitch of AI agents is that you assemble specialist capabilities like Lego bricks. But if every Lego brick has a different connector shape, you spend most of your time fabricating adapters rather than building anything useful.

Why this matters to builders

• Vendor portability: swap out the helpdesk agent from one provider to another without rewriting the orchestrator that calls it.
• Ecosystem growth: any vendor that ships an A2A-compliant agent instantly becomes compatible with every other compliant system — network effects compound over time.
• Async safety: A2A natively handles long-running tasks (minutes to hours) through streaming and push notifications, rather than forcing the caller to poll a custom endpoint.
• Security parity: authentication, task scope, and capability declarations are baked into the protocol, not bolted on per integration.

By early 2026, over 150 organizations — including AWS, Microsoft, Salesforce, SAP, and ServiceNow — had adopted the specification, and A2A v1.0 entered production use. The Linux Foundation's neutral governance ensures no single vendor controls the roadmap.

// How it works

A2A communication centers on four primitives: the Agent Card, the Task, the Message, and the Artifact. Every A2A interaction follows a discoverable-delegate-report loop.

Agent Cards: the published identity

Every A2A-compliant agent publishes a JSON document called an Agent Card at a well-known URL — conventionally /.well-known/agent.json on its domain. The card declares the agent's name, description, supported skills, authentication requirements, and the endpoint that accepts tasks. It is the digital equivalent of a business card stapled to a skills brochure.

{
  "name": "Invoice Processing Agent",
  "description": "Validates, categorizes, and routes supplier invoices.",
  "url": "https://finance-agent.example.com/a2a",
  "skills": [
    {
      "id": "validate-invoice",
      "name": "Validate Invoice",
      "description": "Check an invoice for format errors and policy compliance."
    }
  ],
  "authentication": {
    "schemes": ["Bearer"]
  }
}

In A2A v1.0 (released early 2026), Agent Cards gained cryptographic signatures. A receiving agent can now verify that the card was genuinely issued by the domain owner, not a spoofed card from a malicious server.

Tasks: the unit of work

A Task is the fundamental work unit. When an orchestrator wants a remote agent to do something, it sends a task via an HTTP POST using the JSON-RPC 2.0 message format. Every task gets a unique ID and tracks its own lifecycle.

Messages and Artifacts

Agents exchange Messages within a task — the caller sends instructions or clarification; the remote agent sends status updates or questions back. When the work is done, the remote agent attaches one or more Artifacts to the task: structured output, file references, or any other payload the caller requested. The caller reads the artifacts and moves on.

Transport and async patterns

All A2A traffic runs over HTTPS with JSON-RPC 2.0 as the payload format. For short tasks, the caller waits for a synchronous response. For long-running tasks the protocol supports two async patterns:

• Server-Sent Events (SSE): the remote agent streams incremental progress updates back to the caller in real time — useful for watching a multi-step workflow unfold.
• Push notifications: the remote agent posts a webhook to a URL the caller registered when submitting the task — useful for fire-and-forget delegation where the caller does not want to hold a connection open.

// A2A vs MCP: complementary, not competing

When A2A launched, the natural question was: how does it relate to MCP (Model Context Protocol), the standard Anthropic released in November 2024? The short answer: they solve different problems at different layers of the stack, and most production systems in 2026 use both.

The cleanest mental model: MCP is how an agent connects to its tools; A2A is how that agent connects to another agent. An orchestrator agent might use MCP to call a web search tool, then use A2A to hand a research sub-task off to a specialist agent at another company. The two protocols operate at different altitudes and are designed to coexist.

Microsoft confirmed at Build 2025 that both protocols would be supported inside Azure AI Foundry and Copilot Studio, explicitly framing them as complementary infrastructure rather than a forced choice.

// Real-world patterns and examples

The most common A2A deployment pattern in 2025-2026 enterprise settings is a hub-and-spoke orchestration: one internal orchestrator agent coordinates a collection of specialist agents, some of which are first-party and some of which live behind third-party SaaS platforms.

IT operations example

A concrete example: an IT operations workflow where a central orchestrator receives an employee's 'I can't log in' ticket. The orchestrator uses A2A to delegate to a ServiceNow agent (which queries the ticketing system), an Okta agent (which checks account status), and an internal remediation agent (which resets credentials). Each remote agent exposes an Agent Card, accepts a task, and returns an artifact. The orchestrator never needs to know the internals of any of those systems — it only speaks A2A.

What A2A looks like in code

From the orchestrator side, submitting an A2A task is a JSON-RPC call over HTTPS. The orchestrator fetches the remote Agent Card first, then posts a task to the declared endpoint:

import httpx

# 1. Discover: fetch the remote agent's card
card = httpx.get("https://servicenow-agent.example.com/.well-known/agent.json").json()

# 2. Delegate: submit a task via JSON-RPC 2.0
response = httpx.post(
    card["url"],
    headers={"Authorization": "Bearer <token>"},
    json={
        "jsonrpc": "2.0",
        "method": "tasks/send",
        "id": "task-001",
        "params": {
            "id": "task-001",
            "message": {
                "role": "user",
                "parts": [{"text": "Check if user alice@example.com has an open account lockout ticket."}]
            }
        }
    }
)
print(response.json())

Other emerging protocols

A2A is the most widely adopted agent interoperability specification, but it is not the only one. ACP (Agent Communication Protocol), developed by IBM and the BeeAI community, takes a similar HTTP + JSON approach. ANP (Agent Network Protocol) explores decentralized discovery using DIDs (Decentralized Identifiers). In practice, A2A's head-start, Linux Foundation governance, and cloud platform integrations have made it the default choice for enterprise cross-vendor agent communication as of mid-2026.

// Going deeper

Once you are past the basics, there are several areas where A2A's design choices have meaningful implications for production systems.

Security model

A2A's security model is layered. Transport security is HTTPS; Agent Cards declare which authentication schemes a remote agent accepts (API keys, OAuth 2.0, OpenID Connect Discovery). In v1.0, signed Agent Cards added a cryptographic layer: the card carries a signature verifiable against a key published at the agent's domain, preventing a man-in-the-middle from substituting a malicious capability declaration. For high-stakes cross-organization delegation, verifying the card signature before submitting any task is essential.

Prompt injection is a live concern in any multi-agent system — a malicious document retrieved by one agent can attempt to hijack instructions passed to another. A2A reduces the surface by keeping agent capabilities scoped to the declared skills in their Agent Card, but the protocol alone cannot prevent injection at the content layer. Defense-in-depth (input/output filtering, trust boundaries, least-privilege tool scopes) remains necessary.

Task cancellation and idempotency

A2A supports canceling in-flight tasks with a tasks/cancel call. Remote agents are expected to surface a canceled status, though there is no guarantee of mid-execution rollback — a remote agent that has already written data will not automatically undo it. Design your orchestrator to treat cancellation as 'stop further work' rather than 'undo all work'. For tasks that must be exactly-once safe, use deterministic task IDs and idempotent task handler logic on the remote side.

Versioning and capability negotiation

Agent Cards include an apiVersion field. When you have agents from different organizations evolving at different speeds, capability negotiation becomes important: an orchestrator should read the remote card at task submission time, not cache it forever. Stale cards are one of the most common subtle bugs in production A2A systems. A recommended pattern is to re-fetch the card on a short TTL (e.g., once per hour) and handle version mismatches explicitly rather than silently falling through.

Where A2A is heading

The A2A v1.0 anniversary update (April 2026) added support for gRPC as an alternative transport alongside HTTP/SSE, multi-tenancy controls, and early work on the AP2 payments protocol — an extension that lets agents authorize micropayments on behalf of a task. The project hit 22,000 GitHub stars by its first anniversary. The trajectory suggests A2A is becoming the same kind of foundational plumbing for the agentic web that OAuth became for delegated authorization on the regular web.