The Agent-to-Agent (A2A) Protocol: How AI Agents Talk to Each Other

Every agent you build today is fluent in exactly one language: its own. Your support agent can't ask your research agent for help unless you personally wire them together, and neither can talk to the invoicing agent another company ships — at all. As organizations go from one agent to dozens, that silence becomes the bottleneck. The Agent-to-Agent protocol (A2A) is the industry's answer: an open standard that lets agents discover each other, delegate work, and collaborate across frameworks, vendors, and company boundaries. Google launched it, the Linux Foundation now governs it, and it has moved from announcement to version 1.0 with remarkable speed. This is the practical guide — what it is, how the pieces work, code you can adapt, and the security questions to ask before you let your agents talk to strangers.

The problem: N agents, N×(N−1) integrations

The case for A2A is the same one that gave us HTTP, SMTP, and every other protocol that stuck: pairwise integrations don't scale. If every agent needs a bespoke adapter to talk to every other agent, four agents need twelve directed integrations and twenty need three hundred and eighty. Worse, the integrations are brittle — they break when either side's internals change, and they're impossible across organizational boundaries where you can't see the other side's internals at all.

A2A's bet is that agents should interoperate the way web services do: a public discovery document, a standard message format, and well-defined semantics for long-running work. Google announced the protocol in April 2025 with 50+ launch partners, donated it to the Linux Foundation in June 2025 for neutral governance, and the spec reached version 1.0 — with SDKs in Python, JavaScript, Java, Go and .NET, and support landing across Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud. Whatever you think of the design, the governance story is exactly how durable standards get made: no single vendor owns it.

The three pillars: Agent Cards, Tasks, and transports

1 · Discovery — the Agent Card

Every A2A server publishes a JSON document at a well-known URL — /.well-known/agent-card.json — that describes who it is, what it can do, and how to talk to it. Think of it as a public résumé plus an API contract. A client fetches the card, reads the agent's skills, checks the capabilities (does it stream? does it support push notifications for long tasks?), and learns which security schemes it must satisfy before sending work.

// GET https://analyst.example.com/.well-known/agent-card.json  (abridged)
{
  "name": "Churn Analyst",
  "description": "Analyzes customer churn from usage exports and produces a cited report.",
  "url": "https://analyst.example.com/a2a",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [
    {
      "id": "churn-analysis",
      "name": "Churn analysis",
      "description": "Given a usage export, identify churn drivers and produce a report.",
      "examples": ["Analyze Q2 churn for the enterprise tier"]
    }
  ],
  "securitySchemes": { "bearer": { "type": "http", "scheme": "bearer" } }
}

2 · Work — the Task and its lifecycle

The unit of work in A2A is the Task. When a client sends a message, the remote agent can reply immediately — or open a task that lives through a defined set of states. This is the part of the protocol that quietly does the most work, because real delegation is rarely instant: reports take minutes, approvals take hours, and sometimes the remote agent needs to come back and ask a question. The input_required state makes that interactive pause a first-class protocol concept instead of a hack.

3 · Transport — boring on purpose

A2A deliberately builds on plumbing your infrastructure already understands: JSON-RPC 2.0 over HTTPS as the primary binding, with gRPC and plain HTTP+JSON/REST as alternates, Server-Sent Events for streaming task updates, and webhook push notifications for tasks that outlive a connection. Messages carry typed parts — text, files, or structured data — so agents can exchange more than prose. No exotic transport, no new wire format to debug at 3 a.m.

A2A and MCP: layers, not rivals

The most common confusion is where A2A sits relative to the Model Context Protocol. The short version: MCP connects an agent to its tools; A2A connects an agent to other agents. MCP is vertical — it gives one agent hands (databases, APIs, file stores). A2A is horizontal — it gives agents a shared language to delegate whole tasks to peers, including peers built by other teams on other frameworks. A production agent typically speaks both: MCP downward, A2A sideways.

A complete exchange, in code

Here's the whole flow a client walks through — discover, send, and read the result. The protocol is JSON-RPC, so you can drive it with nothing but fetch:

// 1) Discover — fetch the Agent Card and check it fits the job.
const card = await fetch(
  "https://analyst.example.com/.well-known/agent-card.json"
).then((r) => r.json());

const skill = card.skills.find((s) => s.id === "churn-analysis");
if (!skill) throw new Error("This agent doesn't advertise the skill we need.");

// 2) Delegate — send a message; the agent opens a Task.
const res = await fetch(card.url, {
  method: "POST",
  headers: { "Content-Type": "application/json", Authorization: `Bearer ${TOKEN}` },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "message/send",
    params: {
      message: {
        messageId: crypto.randomUUID(),
        role: "user",
        parts: [{ text: "Analyze Q2 churn for the enterprise tier." }],
      },
    },
  }),
});

const { result } = await res.json();
console.log(result.status.state); // "submitted" → poll tasks/get, or use
                                  // message/stream (SSE) for live updates

// 3) Collect — when state is "completed", read the artifacts.
// result.artifacts → [{ parts: [{ text: "## Churn report …" }] }]

For long-running work you'd use message/stream (SSE) instead of polling, and register a push-notification webhook for tasks that outlive the connection. The official SDKs wrap all of this, but it's worth seeing once that there's no magic underneath — just HTTP, JSON, and a state machine. Watch the same exchange as a trace:

The security section nobody should skip

A2A makes it easy for your agents to talk to agents you didn't build — which is precisely why it deserves the same suspicion as any federation technology. The protocol gives you the primitives (security schemes on the card, authenticated endpoints, task-level auth states); the posture is on you. Four practices matter most:

• Treat remote agent output as untrusted input. A peer agent's reply can carry a prompt injection just like a poisoned document can. Quarantine it, don't paste it raw into your planner's context — the layered-defense playbook applies verbatim.
• Allowlist who your agents may call. Discovery being open doesn't mean delegation should be. Maintain an explicit registry of approved peer agents, exactly as you would for MCP servers.
• Authenticate both directions and scope the credentials. The card's securitySchemes tell you how to authenticate to the agent; make sure your own agents demand auth from callers too, with least-privilege tokens per peer.
• Keep humans on irreversible delegations. A task that ends in money moving or data leaving should pass a human gate on your side, whatever the remote agent claims — HITL patterns here.

Best practices for adopting A2A

1. 1Start by publishing, not consuming. Wrapping one existing agent with an Agent Card and an A2A endpoint teaches you the whole protocol with minimal risk.
2. 2Write skills like API docs, not marketing. The skills array is how other agents decide to call you — precise descriptions and realistic examples beat adjectives.
3. 3Design for `input_required` from day one. The tasks that matter will need mid-flight clarification; handling it late is a rewrite.
4. 4Version and monitor like any public API. Your Agent Card is a contract. Track who calls you, budget their usage, and treat breaking changes with the same ceremony as a REST API bump.
5. 5Keep MCP for tools. Don't wrap a database in an agent just to speak A2A to it — a tool is a tool; the protocol boundary should follow the reasoning boundary.

Where AgentSwarms fits

A2A standardizes the conversation between systems of agents — but you still have to build the agents and the team. That's the part AgentSwarms is for: compose multi-agent workflows on the visual swarm canvas and watch every handoff in the trace; learn the protocol layer by building — the notebooks library now includes MCP notebooks across seven frameworks (OpenAI SDK, ADK, Strands, Mastra, VoltAgent and more), the exact protocol A2A complements; and when your agent is ready to meet the world, embeds give it a public, domain-locked surface. The concepts transfer directly: an AgentSwarms swarm is the 'org chart' A2A would federate.

The bigger picture is worth stating plainly. The agent ecosystem is converging on a stack: MCP for an agent's hands, A2A for its voice, and your orchestration layer for its brain. Protocols this young always carry risk — but with neutral governance, three clouds on board, and a 1.0 spec, A2A is currently the only serious candidate for the lingua franca. Learning it now is cheap; retrofitting interoperability later never is.