What Is the A2A Protocol? How Agent-to-Agent Communication Works

TL;DR

• The A2A protocol (Agent2Agent) is an open standard that lets AI agents built on different frameworks discover each other, delegate tasks, and return results without exposing their internal memory, prompts, or tools.
• Google announced A2A in April 2025, the Linux Foundation took it over in June 2025, and the current stable specification is v1.0, now a Growth Stage project in the Agentic AI Foundation.
• Every A2A exchange is built from six objects: the agent card, message, part, task, context, and artifact, with tasks moving through states such as working, input-required, completed, and failed.
• A2A v1 defines three standard transports (JSON-RPC 2.0, HTTP+JSON/REST, and gRPC) and three update patterns: polling, streaming over server-sent events, and push notifications to a webhook.
• A2A connects agents to agents while MCP connects an agent to its tools, so production systems run both and need one place to govern and trace the traffic.

The A2A protocol (Agent2Agent) is an open standard that defines how AI agents built by different teams, on different frameworks, discover each other, exchange messages, and hand off long-running tasks over HTTP or gRPC. As soon as one agent delegates work to another, teams need answers that the protocol alone does not provide: who called the agent, whether that caller was allowed to, and which model and tool calls produced the result. Bifrost, the open-source AI gateway for model, tool, and agent traffic built by Maxim AI, carries A2A calls alongside LLM and MCP traffic under one set of access rules and logs. This guide explains how agent-to-agent communication works at the protocol level, then how to run it in production.

What Is the A2A Protocol?

The A2A protocol is an open, transport-neutral standard for communication between independent AI agents. A client agent reads a remote agent's agent card, sends it a message, and receives either a direct reply or a task that it can follow until the remote agent returns artifacts. The remote agent stays opaque: callers see its skills and endpoints, never its internals.

Opacity separates A2A from in-framework multi-agent patterns, where agents share memory and call each other as functions. The official A2A documentation targets agents owned by different teams or vendors, which interact "without needing to share internal memory, tools, or proprietary logic."

A2A standardizes only the contract between two agents: discovery, messages, task state, results, and updates. It is not an agent framework or a tool-calling protocol. Teams meet it as an A2A agent (a server exposing the protocol) and an A2A client (the application or agent calling it).

The Agent Gateway in Bifrost accepts any server that speaks A2A v1, however it was built. For registration steps, see the companion guide on running A2A protocol traffic through a gateway.

A2A history: from Google to the Linux Foundation

Google announced the Agent2Agent protocol on April 9, 2025, with support from more than 50 technology partners. On June 23, 2025, the Linux Foundation launched the Agent2Agent project to give it vendor-neutral governance, with more than 100 supporting companies.

Two later milestones define where the agent2agent protocol stands in October 2026:

• Stable v1.0 specification. 1.0.0 is the latest released version (after 0.1.0, 0.2.6, and 0.3.0). v1.0 renamed the core operations (SendMessage, GetTask, CancelTask), made a2a.proto the normative source for all bindings, and added ListTasks.
• Agentic AI Foundation. In August 2026, A2A was accepted as a Growth Stage project at the Agentic AI Foundation (AAIF), the Linux Foundation-directed home it now shares with MCP, goose, and AGENTS.md. The project reports backing from more than 150 organizations.

A Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow maintains the protocol, and the code and specification are licensed under Apache 2.0.

How Agent-to-Agent Communication Works

Agent-to-agent communication over A2A follows one sequence. The client fetches the remote agent's card to learn its skills, endpoints, and authentication. It sends a message. The remote agent answers with a message for quick exchanges or a task for tracked work, and the client follows that task until it reaches a final state with artifacts.

Figure 1: Discovery happens once through the agent card; after that, the task ID carries every follow-up, status update, and artifact.

The specification names three actors: the user who defines the goal, the A2A client that acts for the user, and the A2A server (remote agent) that does the work. One agent can be a server to its caller and a client to the agents it delegates to.

A typical exchange runs in four steps:

1. Discover. The client reads the agent card, usually from https://{domain}/.well-known/agent-card.json or a registry.
2. Send. The client calls SendMessage with a message made of one or more parts.
3. Follow the task. The client polls with GetTask, streams, or registers a push callback, and answers input-required on the same task ID.
4. Collect artifacts. At completed, the client reads text, file, or structured-data artifacts.

As Figure 1 shows, the task ID threads through the whole exchange, and it later becomes the key for tracing the agent's own model and tool calls. The Bifrost guide to A2A messages, tasks, and events walks through the sequence with working requests.

Core A2A Objects: Agent Cards, Messages, Tasks, and Artifacts

The A2A data model has six objects. The agent card describes an agent, and a message carries one turn of conversation built from parts. A task tracks a unit of work through its states, a context groups related tasks into one conversation, and an artifact holds the output a task produces.

The remote agent creates and owns task and context IDs; clients and gateways only preserve them, which is what makes tasks resumable after a dropped connection.

The A2A agent card

The agent card is the agent's directory entry. Required fields include name, description, version, an ordered list of supportedInterfaces (first is preferred), capabilities (streaming, push notifications, extensions, extended card), default media types, and skills; optional fields cover security schemes and JSON Web Signatures over the card. An agent can also serve an authenticated extended agent card with extra skills for signed-in callers; the agent card guide in this cluster walks through the full schema with JSON examples. When Bifrost serves a card for a registered A2A agent, it fetches the current card from the agent on each request and rewrites the endpoints and authentication for gateway access.

A2A tasks vs messages: when an agent returns which

An agent replies with a message for exchanges that need no tracked state and with a task for substantial or long-running work. Hybrid agents negotiate scope with messages, then create a task once work is committed. A task in a terminal state accepts no further messages; to refine its result, the client starts a new task in the same context and references the original with referenceTaskIds.

Task states

In v1.0 wire formats these appear as TASK_STATE_WORKING, TASK_STATE_COMPLETED, and so on. One detail causes many debugging mistakes: a successful HTTP or JSON-RPC response can carry a task in the failed state. The request reached the agent; the work did not succeed. Check the transport status and the task state separately.

A2A Transports: JSON-RPC, HTTP+JSON, and gRPC

A2A v1 defines three standard protocol bindings: JSON-RPC 2.0 over HTTP(S), HTTP+JSON (often labeled REST), and gRPC. All three carry the same operations and data model, defined in one normative protobuf file. An agent advertises the bindings it supports in its card, and implementers can add custom bindings through the extension process.

Clients declare the protocol version with the A2A-Version service parameter; an agent that does not support it returns VersionNotSupportedError. A minimal JSON-RPC request looks like this:

{
  "jsonrpc": "2.0",
  "id": "req-1",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-1",
      "role": "user",
      "parts": [{"text": "Summarize the open incidents for the payments service."}]
    }
  }
}

Friction appears when a REST client needs to reach a gRPC-only agent. Bifrost resolves that with transport selection and recovery: the client-facing and agent-facing transports are chosen independently, so a client can call over REST while the gateway calls the agent over JSON-RPC or gRPC.

Streaming and Push Notifications in A2A

A2A offers three ways to receive task updates. Polling calls GetTask until the state changes. Streaming opens a server-sent events or gRPC stream with SendStreamingMessage and receives status and artifact events as they happen. Push notifications send updates to a client-provided webhook, so the client does not hold a connection open.

A stream delivers the task, status updates, and artifact updates (with append and lastChunk flags for large outputs), and closes when the task reaches a terminal or interrupted state. A dropped stream resumes with SubscribeToTask; disconnecting never cancels the task, only CancelTask does. Push notifications use a TaskPushNotificationConfig with a webhook URL, an optional validation token, and optional authentication.

Push concentrates production concerns: callback URLs are an outbound request surface, and delivery needs retries. With push notifications through Bifrost, the agent receives a Bifrost callback URL and a separate notification token, while the client's real callback URL and credentials stay in the gateway. Bifrost stores pending deliveries durably, retries up to six times with a 30-second timeout per attempt, delivers at least once, and blocks private and loopback callback destinations by default.

A2A Security and Authentication

A2A relies on standard web security rather than inventing its own. An agent declares how callers must authenticate in its card's security schemes, and credentials travel in HTTP headers or gRPC metadata, separate from A2A message content. The v1.0 specification supports API key, HTTP authentication (such as bearer tokens), OAuth 2.0, OpenID Connect, and mutual TLS schemes.

A2A security covers four areas:

• Authentication. The card's securitySchemes and securityRequirements tell the client which credentials to obtain, often through an out-of-band OAuth flow. Individual skills can carry their own requirements.
• Authorization. The protocol leaves authorization to the agent, with one explicit rule: operations such as ListTasks must return only tasks visible to the authenticated caller.
• Card integrity. Agent cards can carry JSON Web Signatures (RFC 7515) so a client can verify the card was not altered.
• Transport security. HTTP interfaces must use HTTPS in production, and mutual TLS is a first-class scheme.

The protocol does not define which internal applications may call which agents or where credentials stop. Bifrost adds that as agent access control and per-registration authentication and credential forwarding, covered below. The A2A security guide in this cluster goes deeper; for broader context, see the AI security resource page.

A2A vs MCP: How the Two Protocols Fit Together

A2A and MCP solve different problems and are designed to be used together. The Model Context Protocol connects one agent to its tools, APIs, and data sources. A2A connects one agent to another agent that it treats as an opaque peer. A typical multi-agent system uses MCP beneath each agent and A2A between them.

Figure 2: The two protocols sit on different axes, so most multi-agent systems use both: A2A between agents, MCP beneath each one.

The AAIF announcement calls MCP the vertical layer from an agent down to its tools and A2A the horizontal layer between peers. The practical differences:

For the tool side, read the complete guide to the Model Context Protocol and the breakdown of MCP transports, primitives, and the message lifecycle; the A2A vs MCP guide in this cluster compares them in depth. The same Bifrost gateway that governs MCP tool access also governs agent access, so running both protocols through one gateway keeps policy in one place.

A2A SDKs, Servers, and Testing Tools

The A2A project publishes official SDKs for Python, JavaScript, Java, Go, C#/.NET, and Rust, plus a command-line client and samples. An A2A SDK provides typed protocol models, a client, and server scaffolding that turns an agent's logic into a compliant A2A server with a served agent card.

The core resources in the project's GitHub organization:

• SDKs. Python, JavaScript, Java, Go, .NET, and Rust libraries implement the client and server sides. The A2A v1.0 specification defines the contract they implement, and the project's Python quickstart builds an agent card, an executor, and a server end to end.
• A2A CLI. Released in October 2026, the a2a command-line client discovers agents, sends messages, and manages tasks from a terminal, a CI pipeline, or a coding assistant.
• A2A Inspector. A UI tool for connecting to an A2A agent, viewing its card, and exchanging messages during development.
• Framework support. LangGraph, CrewAI, Pydantic AI, AG2, and IBM BeeAI support A2A, so many teams expose an existing agent rather than writing a server from scratch.

Testing an A2A server means validating the card, exercising every advertised binding, driving tasks through input-required and failure states, and confirming streaming and push behavior; the testing guide in this cluster covers the Inspector and its alternatives. In production, the Bifrost Agent Gateway troubleshooting guide covers the failures that appear once a gateway sits between client and agent.

Running the A2A Protocol in Production with Bifrost

Running the A2A protocol in production adds requirements the specification leaves to implementers: a single place to register agents, grant callers access, bridge transports, relay push callbacks, and log every operation. The Bifrost AI gateway handles these through its Agent Gateway, which currently supports A2A v1, alongside the LLM and MCP traffic the gateway already governs.

Figure 3: One gateway sees both hops: the A2A call into the agent and the LLM and MCP calls the agent makes to finish the task.

The Agent Gateway launch post explains the motivation; the production mechanics break down into five parts.

Registration by agent card URL

An agent is registered by its full agent card URL, such as https://research.example.com/.well-known/agent-card.json, through the dashboard, config.json, Helm, or the API. Bifrost fetches the card, previews its skills and authentication, and creates gateway endpoints for the agent card, JSON-RPC, REST, and optionally gRPC. Gateway protocol endpoints activate only after the External Client URL (the public base URL) is set in Agent Gateway settings.

{
  "agents": [
    {
      "name": "library-research",
      "agent_card_url": "<https://research.example.com/.well-known/agent-card.json>",
      "allow_by_default": false,
      "virtual_key_ids": ["application-key-id"]
    }
  ]
}

Clients discover the agent through the gateway's served card, so their calls come through Bifrost.

Agent access grants

Virtual keys grant access to individual agents; a key granted one agent does not gain access to any other. "Allow any virtual key" opens an agent to every valid key, and enabling authentication enforcement rejects anonymous calls. Bifrost Enterprise adds agent grants through access profiles and projects, so agent access can follow the identity provider's groups.

Agent access is a separate grant from model and tool access: permission to call a research agent does not authorize that agent's own LLM or MCP calls, which are checked against their own grants and the AI governance budgets and rate limits. The Bifrost governance resource page covers the wider model.

Credential handling

By default, Bifrost strips the caller's Bifrost credential before forwarding a request to an agent. For trusted agents, the opt-in "Forward Bifrost authentication" setting passes it on so the agent's downstream calls keep the original caller's access rules and budgets. Upstream authentication to the agent supports headers, OAuth 2.0 client credentials, custom CAs, and mutual TLS.

Transport bridging and recovery

Bifrost bridges all three A2A v1 bindings, choosing the upstream transport from the card's supportedInterfaces in card order. On a dial failure, an HTTP 404, 405, 410, or 426, or a method-not-found error, a unary operation moves to the next eligible interface. Bifrost does not replay ambiguous failures or streaming operations, because a replay could create a duplicate task.

For a step-by-step setup walkthrough, the companion article on how to route A2A agents through Bifrost covers the four-step registration flow.

Teams comparing options can review the open-source agent gateways for MCP and A2A, the criteria for choosing an agent gateway, and the requirements for an enterprise agent gateway.

Tracing A2A Agents: Agent Logs Correlated With LLM and MCP Logs

Agent Logs record every A2A operation that passes through Bifrost, from card discovery to push delivery, and group them into sessions by A2A context ID. When the agent sends its own model and tool calls through Bifrost with two correlation headers, Agent Logs link each task to the exact LLM and MCP calls that produced its result.

Figure 4: Without the correlation headers the gateway sees the A2A call and the model calls as unrelated traffic.

The two headers are x-bf-session-id, set to the A2A context ID, and x-bf-agent-correlation-id, set to the A2A task ID. The agent reads both from its execution context and attaches them, with the forwarded caller credential, to every LLM and MCP request it makes for the task:

curl <http://localhost:8080/v1/chat/completions> \
  -H "x-bf-vk: $CALLER_BIFROST_VK" \
  -H "x-bf-session-id: $A2A_CONTEXT_ID" \
  -H "x-bf-agent-correlation-id: $A2A_TASK_ID" \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-4o-mini", "messages": [{"role": "user", "content": "Summarize the incident."}]}'

In Agent Logs, an operation's detail view shows the conversation, ordered stream events, artifacts, and LLM Logs and MCP Logs tabs filtered to that task; a session view spans the whole conversation. Token usage and cost belong to the correlated LLM logs.

To diagnose a failed task, open its operation, read the status message, then check the matching MCP and LLM calls. The same operations flow to the observability connectors for agent telemetry, including OpenTelemetry, Prometheus, Datadog, BigQuery, Kafka, Pub/Sub, and Splunk, so agent traffic appears beside the rest of the gateway-layer AI observability data. The differences between this layer and model-only routing are covered in the comparison of an agent gateway vs an LLM gateway.

Frequently Asked Questions

What is the A2A protocol used for?

The A2A protocol lets independent AI agents delegate work to each other across framework and vendor boundaries. Google created it in April 2025, and the Linux Foundation has governed it since June 2025. A support agent can hand a research question to a documentation agent, a procurement agent can ask a supplier's agent for a quote, or an orchestrator can split a project across specialist agents. Each agent stays opaque, exposing only its agent card, endpoints, and results.

What is the difference between A2A and MCP?

MCP connects an agent to tools, APIs, and data sources; A2A connects an agent to other agents. An MCP server exposes functions that return results, while an A2A agent accepts tasks, reasons on its own, and returns artifacts over a lifecycle that can last days. Most production multi-agent systems use both protocols, and the MCP gateway resource page covers governing the tool side.

What is an agent card in A2A?

An agent card is a JSON document that describes an A2A agent: its name, description, version, skills, supported transports in preference order, capabilities such as streaming and push notifications, and the security schemes callers must satisfy. Clients usually fetch it from /.well-known/agent-card.json. Agents can also serve an authenticated extended card with additional skills or configuration.

What is the difference between A2A tasks and messages?

A message is one turn of communication, used for quick exchanges that need no tracked state. A task is a unit of work with an ID, a state such as working or input-required, a history, and artifacts. Agents return a message for trivial requests and a task for substantial or long-running work. Once a task reaches a terminal state, it accepts no further messages.

Which A2A SDKs are available?

The A2A project publishes official SDKs for Python, JavaScript, Java, Go, C#/.NET, and Rust, along with the a2a command-line client and sample code. Agent frameworks including LangGraph, CrewAI, Pydantic AI, AG2, and IBM BeeAI also support A2A, so an existing agent can often be exposed as an A2A server without writing protocol code by hand.

Does the A2A protocol require a gateway?

No. Any A2A client can call an A2A server directly. A gateway becomes useful once several teams call several agents, because it centralizes registration, agent access grants, credential handling, transport bridging, push callback relay, and logs. Bifrost provides that layer as part of the same AI gateway that governs model and MCP tool traffic.

Getting Started with A2A on Bifrost

The A2A protocol gives agents a shared contract for discovery, tasks, and results; running it across an organization requires access control, transport bridging, and traces that connect each task to the model and tool calls behind it. Bifrost governs A2A traffic alongside LLM and MCP calls in one self-hosted gateway, with enterprise deployment options for in-VPC and air-gapped environments. To see Agent Gateway running with your own agents, book a demo with the Bifrost team.