---
description: "The A2A protocol explained: agent cards, tasks, transports, streaming, push notifications, security, how it relates to MCP, and running A2A in production."
title: What Is the A2A Protocol? How Agent-to-Agent Communication Works
image: https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/what-is-the-a2a-protocol-how-agent-to-agent-communication-wo-bifrost-1920x1080.png
---

Try Bifrost Enterprise free for 14 days. [Request access](https://www.getmaxim.ai/#enterprise-trial)

**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](https://www.getmaxim.ai/), the [open-source AI gateway for model, tool, and agent traffic](https://github.com/maximhq/bifrost) 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](https://a2a-protocol.org/latest/) 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](https://docs.getbifrost.ai/features/agent-gateway/overview) 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](https://www.getmaxim.ai/articles/a2a-protocol-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](https://linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents) 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](https://a2a-protocol.org/latest/blog/2026/08/27/a-new-chapter-for-a2a-joining-the-agentic-ai-foundation/) (AAIF), the Linux Foundation-directed home it now shares with MCP, goose, and [AGENTS.md](http://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.

![A2A protocol flow from a client agent reading the agent card, sending a message, receiving a task that moves through working or input-required, and ending with artifacts](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/what-is-a2a-protocol/what-is-a2a-protocol-task-lifecycle.png)

*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](https://docs.getbifrost.ai/features/agent-gateway/messages-and-tasks) 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.

| Object | What it is | Key fields |
| --- | --- | --- |
| Agent card | JSON manifest describing one agent | `name`, `description`, `version`, `supportedInterfaces`, `capabilities`, `skills`, `securitySchemes` |
| Message | One turn of communication | `messageId`, `role` (`user` or `agent`), `parts`, optional `taskId` and `contextId` |
| Part | The content container inside messages and artifacts | Exactly one of `text`, `raw`, `url`, or `data`, plus `mediaType`, `filename`, `metadata` |
| Task | A stateful unit of work created by the remote agent | `id`, `contextId`, `status`, `artifacts`, history |
| Context | A server-generated ID that groups related tasks and messages | `contextId` |
| Artifact | A deliverable produced by a task | `artifactId`, `name`, `parts` |

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](https://docs.getbifrost.ai/features/agent-gateway/registration), 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

| State | Meaning | Terminal? |
| --- | --- | --- |
| `submitted` | The agent accepted the task | No |
| `working` | The agent is processing | No |
| `input-required` | The agent needs more information on the same task ID | No (interrupted) |
| `auth-required` | The caller must complete authentication before work continues | No (interrupted) |
| `completed` | Work finished; artifacts are available | Yes |
| `failed` | Work failed | Yes |
| `rejected` | The agent declined the work | Yes |
| `canceled` | Cancellation completed | Yes |

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.

| Binding | Request format | Streaming | Example operation |
| --- | --- | --- | --- |
| JSON-RPC 2.0 | `POST` with a JSON-RPC envelope, `Content-Type: application/json` | Server-sent events (`text/event-stream`) | `"method": "SendMessage"` |
| HTTP+JSON / REST | Resource-style HTTP endpoints | Server-sent events | `POST /message:send`, `GET /tasks/{id}` |
| gRPC | Protobuf over HTTP/2 | Server-streaming RPCs | `SendStreamingMessage` |

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:

```json
{
  "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](https://docs.getbifrost.ai/features/agent-gateway/transports-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.

| Pattern | Agent card capability | Best fit |
| --- | --- | --- |
| Polling (`GetTask`) | None required | Short tasks, simple clients |
| Streaming (`SendStreamingMessage`, `SubscribeToTask`) | `capabilities.streaming: true` | Real-time progress, incremental artifacts |
| Push notifications (`CreateTaskPushNotificationConfig`) | `capabilities.pushNotifications: true` | Tasks lasting minutes to days, serverless or mobile clients |

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](https://docs.getbifrost.ai/features/agent-gateway/push-notifications), 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](https://docs.getbifrost.ai/features/agent-gateway/access-control) and per-registration [authentication and credential forwarding](https://docs.getbifrost.ai/features/agent-gateway/authentication), covered below. The A2A security guide in this cluster goes deeper; for broader context, see the [AI security resource page](https://www.getmaxim.ai/resources/ai-security).

## 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.

![Client agent talks to an opaque remote agent over the A2A protocol, while each agent reaches its own tools and data through MCP servers](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/what-is-a2a-protocol/what-is-a2a-protocol-a2a-and-mcp.png)

*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:

| Dimension | A2A | MCP |
| --- | --- | --- |
| Connects | Agent to agent | Agent (or model host) to tools and resources |
| Other side | Opaque peer with its own reasoning | Tool server exposing callable functions |
| Unit of work | Task with state, history, and artifacts | Tool call with a result |
| Discovery | Agent card | Server capability listing |
| Typical duration | Seconds to days | Usually one request |

For the tool side, read the [complete guide to the Model Context Protocol](https://www.getmaxim.ai/articles/what-is-model-context-protocol-mcp-a-2026-guide/) and the breakdown of [MCP transports, primitives, and the message lifecycle](https://www.getmaxim.ai/articles/the-mcp-protocol-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](https://www.getmaxim.ai/mcp-gateway) 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](https://a2a-protocol.org/latest/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](https://docs.getbifrost.ai/features/agent-gateway/troubleshooting) 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](https://www.getmaxim.ai/) handles these through its Agent Gateway, which currently supports A2A v1, alongside the LLM and MCP traffic the gateway already governs.

![Client application calls Bifrost Agent Gateway over REST, which checks agent access and forwards over JSON-RPC to an A2A agent whose model and MCP calls return through Bifrost](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/what-is-a2a-protocol/what-is-a2a-protocol-bifrost-agent-gateway.png)

*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](https://www.getmaxim.ai/bifrost/blog/introducing-agent-gateway-in-bifrost-one-gateway-for-models-tools-and-agents) 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](https://docs.getbifrost.ai/features/agent-gateway/configuration).

```json
{
  "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](https://docs.getbifrost.ai/features/governance/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](https://docs.getbifrost.ai/enterprise/access-profiles) and [projects](https://docs.getbifrost.ai/enterprise/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](https://www.getmaxim.ai/ai-governance) budgets and rate limits. The [Bifrost governance resource page](https://www.getmaxim.ai/resources/governance) 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](https://www.getmaxim.ai/articles/a2a-protocol-gateway/) covers the four-step registration flow.

Teams comparing options can review the [open-source agent gateways for MCP and A2A](https://www.getmaxim.ai/articles/best-open-source-agent-gateways-for-mcp-and-a2a-in-2026/), the criteria for [choosing an agent gateway](https://www.getmaxim.ai/articles/how-to-choose-an-agent-gateway/), and the requirements for an [enterprise agent gateway](https://www.getmaxim.ai/articles/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.

![The A2A context ID maps to x-bf-session-id and the task ID maps to x-bf-agent-correlation-id on the agent's LLM and MCP requests, which Agent Logs groups by session and task](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/what-is-a2a-protocol/what-is-a2a-protocol-agent-logs-correlation.png)

*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](https://docs.getbifrost.ai/features/agent-gateway/integrating-your-agent):

```bash
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](https://docs.getbifrost.ai/features/agent-gateway/observability), 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](https://docs.getbifrost.ai/features/agent-gateway/connectors), including OpenTelemetry, Prometheus, Datadog, BigQuery, Kafka, Pub/Sub, and Splunk, so agent traffic appears beside the rest of the [gateway-layer AI observability](https://www.getmaxim.ai/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](https://www.getmaxim.ai/articles/agent-gateway-vs-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](https://www.getmaxim.ai/resources/mcp-gateway) 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](https://docs.getbifrost.ai/overview) 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](https://www.getmaxim.ai/enterprise) for in-VPC and air-gapped environments. To see Agent Gateway running with your own agents, [book a demo](https://www.getmaxim.ai/book-a-demo) with the Bifrost team.

## More in the blog

[![Best HIPAA-Compliant LLM Gateways](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/best-hipaa-compliant-llm-gateways-bifrost-1920x1080@2x.png) A HIPAA-compliant LLM gateway routes protected health information only to BAA-covered models and applies PHI guardrails, access control, and audit logging in one place. This guide compares Bifrost, Kong AI Gateway, Azure API Management, Google Apigee, and Cloudflare AI Gateway.](https://www.getmaxim.ai/articles/hipaa-compliant-llm-gateways/)

[![A2A vs MCP: Differences, When to Use Each, and How to Run Both](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/a2a-vs-mcp-differences-when-to-use-each-and-how-to-run-both-bifrost-1920x1080.png) A2A vs MCP is a question of direction: MCP connects an agent to its tools and data, while A2A connects independent agents to each other. This guide compares their message models, transports, auth, discovery and task handling, and shows how to govern both at one gateway.](https://www.getmaxim.ai/articles/a2a-vs-mcp-2/)

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "publisher": {
        "@type": "Organization",
        "name": "Maxim Articles",
        "url": "https://www.getmaxim.ai/articles/",
        "logo": {
            "@type": "ImageObject",
            "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w256h256/2025/08/thumbnail.png",
            "width": 60,
            "height": 60
        }
    },
    "author": {
        "@type": "Person",
        "name": "Kuldeep Paul",
        "image": {
            "@type": "ImageObject",
            "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2025/08/1727978381919.jpeg",
            "width": 800,
            "height": 800
        },
        "url": "https://www.getmaxim.ai/articles/author/kuldeep/",
        "sameAs": []
    },
    "headline": "What Is the A2A Protocol? How Agent-to-Agent Communication Works",
    "url": "https://www.getmaxim.ai/articles/what-is-the-a2a-protocol-how-agent-to-agent-communication-works/",
    "datePublished": "2026-10-29T19:03:35.000Z",
    "dateModified": "2026-10-29T19:03:35.000Z",
    "image": {
        "@type": "ImageObject",
        "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/what-is-the-a2a-protocol-how-agent-to-agent-communication-wo-bifrost-1920x1080.png",
        "width": 1200,
        "height": 675
    },
    "description": "The A2A protocol (Agent2Agent) is an open Linux Foundation standard for agent-to-agent communication. This guide covers its history, core objects, task states, three transports, streaming and push updates, security schemes, the MCP relationship, and production operation.\n",
    "mainEntityOfPage": "https://www.getmaxim.ai/articles/what-is-the-a2a-protocol-how-agent-to-agent-communication-works/"
}
```