Agent-to-Agent Communication

Why agent-to-agent is not just another tool call.

You can model "call another agent" as a tool: one function, ask_billing_agent(query), returning text. For simple, synchronous, stateless requests that is fine. It breaks down on the properties that make a peer an agent rather than a function:

• Opacity. The remote agent has its own model, tools, and internal state you cannot and should not see. You exchange goals and results, not internal reasoning.
• Duration. Agent work can take seconds or hours (a research agent, a deploy agent). The interaction must survive longer than one request/response.
• Multi-turn negotiation. The peer may need to ask clarifying questions before it can proceed — a dialogue, not a single call.
• Rich, typed outputs. The result may be a file, a structured record, or a stream of partial updates, not a string.

An agent-to-agent protocol exists to standardise this interaction shape — opaque, potentially long-running, multi-turn, richly-typed delegation between peers — the same way MCP standardised the agent-to-tool edge.

Discovery: the Agent Card.

Before delegating you must learn what a peer can do. A2A's mechanism is the Agent Card: a machine-readable JSON document, served at a well-known URL, that advertises the agent's identity, endpoint, supported capabilities, the skills it offers, and how to authenticate. It is the agent-to-agent analogue of MCP's initialize capabilities exchange — capability discovery, again, as a first-class step.

# Agent Card (served at /.well-known, illustrative shape)
{
  "name": "invoice-reconciler",
  "description": "Matches invoices to purchase orders.",
  "url": "https://agents.example.com/invoice",
  "version": "2.0",
  "capabilities": {"streaming": true,
                   "pushNotifications": true},
  "defaultInputModes":  ["text", "file"],
  "defaultOutputModes": ["text", "file"],
  "skills": [
    {"id": "reconcile",
     "description": "Reconcile an invoice batch against POs.",
     "inputModes": ["file"], "outputModes": ["file"]}
  ]
}

The card lets a client agent decide, at runtime, whether a peer is suitable and how to talk to it — which skill to request, which content modalities are accepted, whether the peer streams, and which auth scheme to present. No peer is hard-coded into the caller.

The interaction: tasks, messages, artifacts.

A2A frames delegation around a few durable concepts. Names below follow the A2A specification's vocabulary:

• Task. The unit of work, with its own lifecycle and a stable id. A task moves through states — submitted, working, input-required (the peer needs more from you), completed, failed, canceled — so the interaction can outlive a single HTTP request.
• Message. A turn in the conversation about a task, from the user/client role or the agent role. Messages carry parts (text, file, or structured data), making the channel multimodal rather than string-only.
• Artifact. A typed output the remote agent produces — a generated file, a structured result — also composed of parts. Results are first-class objects, not stringified blobs.

client                          remote agent
  │  message/send (task: reconcile, file)  │
  ├───────────────────────────────────────>│ state: submitted → working
  │                                         │
  │  status: input-required                 │
  │<────────────────────────────────────────┤ "which fiscal year?"
  │  message/send (text: "FY2025")          │
  ├───────────────────────────────────────>│ state: working
  │  artifact: reconciled.csv               │
  │<────────────────────────────────────────┤ state: completed

Crucially, the caller never sees the remote agent's tools, model, or chain of thought — only task state, messages, and artifacts. Opacity is the design, not a limitation: it is what lets independently built agents compose. A2A's transport is JSON-RPC over HTTP (with streaming and push-notification options below), an intentional symmetry with the JSON-RPC core of MCP.

Long-running work: streaming and push.

Because agent tasks can be slow, A2A defines ways to avoid blocking a connection for the full duration:

• Streaming. If the Agent Card advertises it, the client can subscribe and receive incremental status updates and artifact chunks over a server-sent-events stream — partial progress instead of one terminal reply. This is the agent-to-agent face of the long-running-work pattern.
• Push notifications. For work measured in minutes or hours, the client registers a webhook; the remote agent calls back when the task changes state, so neither side holds an open connection. The task id is the durable handle that ties the callback to the original request.

This is the same long-running pattern any robust asynchronous API uses — a durable resource id, pollable/subscribable state, and out-of-band completion signals — applied to autonomous peers.

The throughline: agent-to-agent interop generalises the same three moves seen throughout this track — discover (Agent Card), invoke with a negotiated contract (task/message/artifact), and stream or call back for long work — applied to peers that are deliberately opaque so that independently built agents can compose into systems.