A2A Protocol FAQ

These are the questions developers ask most often when they first meet the A2A Protocol. Each answer gives a short conclusion and links to the topic that covers it in depth.

Basics

What is A2A, and who maintains it?

The Agent2Agent (A2A) Protocol is an open standard for communication and collaboration between agents. Whichever vendor built an agent and whichever framework it uses, if it implements A2A it can discover other agents, delegate tasks, and exchange results without exposing its internal memory, tools, or proprietary logic.

A2A was originally developed by Google and donated to the Linux Foundation. It is now a Growth Stage project at the Agentic AI Foundation (AAIF), maintained by a Technical Steering Committee (TSC), and licensed under the Apache License 2.0. See What is A2A? and the Community Hub .

How does A2A relate to MCP? Do I have to choose?

No, you do not have to choose; they complement each other. MCP is vertical: it connects a single agent to tools and data. A2A is horizontal: it connects an agent to other agents. An agentic application can use A2A to talk to other agents while, inside each agent, MCP gives access to that agent’s own tools and resources. See A2A and MCP .

How does A2A relate to agent frameworks such as LangGraph, CrewAI, or ADK?

A2A is a communication protocol and is independent of the framework used to build an agent. Whether you use LangGraph, CrewAI, ADK, or a custom stack, an agent that implements A2A can work with other agents; the protocol does not depend on, or favor, any single framework. The frameworks with built-in A2A integrations are listed in the Community Hub .

Do I have to expose my agent’s internals to use A2A?

No. A2A is built on opaque execution: collaborating agents work from declared capabilities and shared context, and never expose their internal logic, memory, or tools. To a client, a remote agent is a black box. See Key Concepts .

Protocol and design

How are agents discovered, and where does the Agent Card live?

An agent describes itself with an Agent Card, which covers its identity, service interfaces, capabilities, authentication requirements, and skills. The protocol describes three discovery strategies:

• Well-Known URI: the server hosts the Agent Card at the standard path /.well-known/agent-card.json on its own domain.
• Registry: a central directory manages Agent Cards, and clients query it by skill, tag, and similar criteria. The current A2A specification does not define a standard registry API.
• Direct configuration: the client gets Agent Card information from configuration files, environment variables, or a private API.

See Agent Discovery and Specification: Discovery .

Which transports (protocol bindings) does A2A support?

A2A defines three protocol bindings: JSON-RPC 2.0, gRPC, and HTTP+JSON/REST. They share one canonical data model defined in Protocol Buffers (a2a.proto is the single normative source). An agent declares the interfaces it supports in the Agent Card’s supportedInterfaces, and the client picks one. See the Specification .

Can agents exchange files, images, and structured data?

Yes. The content of messages and artifacts lives in Part objects. A Part must contain exactly one of text, raw (inline binary), url (a reference to external file content), or data (structured JSON), and can also carry mediaType, filename, and metadata. This is why A2A is modality-independent. See Key Concepts .

What is the difference between an Artifact and a Message?

A Message is one turn of communication between a client and an agent, with a role (user or agent), and it conveys instructions, context, questions, answers, or status updates that are not necessarily formal deliverables. An Artifact is a tangible output the agent generates during a task, such as a document, an image, or structured data. It has a unique artifactId and a name, its content is also made of one or more Part objects, it is tied closely to the task lifecycle, and it can be streamed to the client in increments. Task results should be returned as artifacts rather than relying on messages to carry critical information. See Key Concepts .

Can A2A be extended?

Yes. Extensions are identified by URI. An agent declares the extensions it supports in its Agent Card, and a client opts in per request through the A2A-Extensions header. Extensions can add new data, requirements, RPC methods, and state machines. See Extensions and Extension and Protocol Binding Governance .

Can I run A2A over another transport such as WebSocket or MQTT?

Yes, with a custom protocol binding. Extensions change the behavior of interactions; a custom binding changes the transport layer itself, for example WebSockets for low-latency bidirectional communication, or MQTT for IoT environments with constrained connectivity. A custom binding is declared in the Agent Card’s supportedInterfaces, and its protocolBinding should be a URI that uniquely identifies the binding. It must support every core operation of the abstract operations layer, keep the data model functionally equivalent to the canonical definitions (JSON uses camelCase field names, and timestamps are ISO 8601 strings in UTC), and give semantically equivalent results for semantically equivalent requests across bindings. Clients parse supportedInterfaces in order and pick the first transport they support, so list entries in order of preference. See Custom Protocol Bindings .

Can one endpoint host several agents or tenants?

Yes. The protocol does not prescribe a routing implementation; it supports three complementary approaches:

• URL-based routing: each agent gets its own URL prefix, and its Agent Card advertises that url in supportedInterfaces.
• Authentication-based routing: when several agents share one URL, a gateway uses the credentials already in the request (for example, claims in a token, or an API key mapped to an agent) to pick the target.
• Body-based routing with the tenant field: request messages carry an optional tenant field, an opaque string whose value the server operator defines. The value is advertised in the tenant field of the AgentInterface, and the client must echo it in every request; if it is not advertised, the field must be omitted.

The approaches can be combined. See Multi-Tenancy and Multi-Agent Routing .

Tasks and interaction

When should an agent return a Message and when a Task?

• Message: for immediate, self-contained exchanges that leave no state to manage afterwards.
• Task: for substantial work that takes a while and needs tracking, with a well-defined lifecycle in which the agent reports progress, asks for input, or delivers results.

An agent can return only messages, always return tasks, or mix the two: negotiate the scope of the work with messages first, then create a task to track execution. See Life of a Task .

How do multi-turn conversations and follow-ups work? How do contextId and taskId relate?

A contextId groups related Task and Message objects so a series of interactions stays continuous. A taskId identifies one specific task and is always generated by the server.

• When a client sends its first message, the agent returns a new contextId (and a taskId too, if it starts a task). Clients should not generate a contextId themselves in general.
• Later messages that carry the same contextId continue the conversation. A message with a contextId but no taskId starts a new task within that context.
• A message that carries a taskId continues that specific task. The taskId must refer to an existing task, otherwise the server returns TaskNotFoundError; if contextId and taskId do not match, the server must reject the message.
• Several tasks can run in parallel within one contextId, and referenceTaskIds explicitly references related tasks.

See Life of a Task and the Core Protocol Specification .

Can I keep modifying a task after it finishes?

Once a task reaches a terminal state (TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, or TASK_STATE_REJECTED), it cannot be restarted. Refinements and follow-ups start a new task in the same contextId and reference the original task through referenceTaskIds. That keeps every task an immutable unit of work that is easy to trace.

What happens if the agent needs more information partway through a task?

The task moves to TASK_STATE_INPUT_REQUIRED, which means the client must supply more input. Like TASK_STATE_AUTH_REQUIRED, it is an interrupted state, not a terminal one: the task has not ended. The client continues it by sending a new message with the same taskId and contextId. When the agent finds a referenced artifact ambiguous, it should also use input-required to ask the client for clarification. See Life of a Task .

Does SendMessage wait for the task to finish?

By default, yes. returnImmediately in SendMessageConfiguration defaults to false, so the operation must wait until the task reaches a terminal state or an interrupted state (TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED) and then return the latest task state with all artifacts. Set it to true to return right after the task is created; the caller then polls with GetTask, subscribes with SubscribeToTask, or receives push notifications. The field has no effect when the operation returns a direct Message, for streaming operations (which always return updates in real time), or on configured push notifications. See Data Structures and the Core Protocol Specification .

How do I cancel a task?

Call CancelTask to request cancellation of a task in progress; cancellation is not guaranteed to succeed. If the task is not in a cancelable state (for example, it has already reached a terminal state), the server returns TaskNotCancelableError. Cancellation is idempotent, and repeating it may return TaskNotFoundError (the task was canceled and then purged). See the Core Protocol Specification .

Does A2A support long-running tasks? How do I choose between streaming and push notifications?

Yes. A2A offers two mechanisms:

• Streaming (SSE): use it when the client can keep an HTTP connection open, to receive status updates and incremental artifacts in real time. The server declares capabilities.streaming in its Agent Card.
• Push notifications: use them for very long tasks, or when the client cannot hold a connection (mobile apps, serverless functions). The server calls a webhook the client provides when the task changes in a meaningful way. The server declares capabilities.pushNotifications.

If a stream drops while a task is still running, the client can resubscribe with SubscribeToTask. See Streaming and Asynchronous Operations .

Security

How does A2A handle authentication and authorization?

A2A does not invent a private security standard; it reuses standard web mechanisms:

• In production, all communication must use HTTPS.
• The agent declares its authentication schemes in the Agent Card’s securitySchemes and securityRequirements, consistent with the authentication options in OpenAPI.
• Credentials (such as OAuth 2.0 tokens or API keys) travel in standard HTTP headers, not in the A2A message payload.
• On failed authentication the server returns 401 Unauthorized; when the caller is authenticated but not permitted to act, it returns 403 Forbidden.
• Authorization is decided by the server from the authenticated identity. It can be controlled per skill, data, and operation, and follows the principle of least privilege.

When a task needs additional credentials while it runs, it moves to the TASK_STATE_AUTH_REQUIRED state. Entering this state is not, by itself, authorization for any operation: the scope of the resulting credential is defined by the implementation, the credential issuer, or an extension. See Authentication, Authorization, and Security Considerations and Enterprise-Ready Features .

Do push notifications introduce security risks?

They can, which is why the protocol gives specific guidance. A server should not blindly send requests to any URL a client provides (to guard against SSRF and DDoS amplification); it should validate the webhook URL and authenticate to the webhook with the agreed scheme. On the webhook side, verify that each notification really comes from a legitimate A2A server, prevent replay, and manage and rotate keys securely. See Streaming and Asynchronous Operations .

Can an Agent Card be protected against tampering?

Yes. An Agent Card can be signed with JSON Web Signature (JWS, RFC 7515), after canonicalizing its content with the JSON Canonicalization Scheme (JCS, RFC 8785). Clients use the signature to verify that the card has not been altered and comes from the claimed provider. For sensitive content, serve it through an extended Agent Card that requires authentication (GetExtendedAgentCard). See Agent Discovery .

Versions and migration

What is the latest version?

A2A v1.0.0 was released on March 12, 2026, and v1.0.1 on May 28, 2026. v1.0.1 is a bug-fix release with specification-level corrections and no new breaking changes. The protocol version is identified only by Major.Minor (for example 1.0); patch versions do not affect compatibility.

What changes when upgrading from v0.3.0 to v1.0?

v1.0 includes a set of breaking changes: renamed operations, TextPart/FilePart/DataPart merged into one Part, enum values moved to SCREAMING_SNAKE_CASE, stream events no longer use kind, the Agent Card’s interface declaration restructured into supportedInterfaces, the /v1 prefix dropped from HTTP paths, the error model moved to google.rpc.Status, and task lists switched to cursor pagination. The full comparison and a phased migration plan are in What’s New in A2A Protocol v1.0 .

How do clients and servers negotiate the protocol version?

Each AgentInterface declares its own protocolVersion, and an agent can expose several interfaces to support several versions at once. The client picks a suitable interface from the Agent Card and sends the A2A-Version header with every request. If the interface does not support the requested version, the server returns VersionNotSupportedError. See the Core Protocol Specification .

Getting started and community

How do I get started quickly?

1. Read What is A2A? and Key Concepts .
2. Follow the Python tutorial to build your first A2A agent from scratch (it needs Python 3.10 or later).
3. Consult the Specification when you need to check protocol details.

Which official SDKs and tools are available?

There are official SDKs for Python, Go, Java, JavaScript, C#/.NET, and Rust, plus the a2a-samples repository, the A2A CLI command-line client, and the A2A Inspector and A2A TCK for checking that an implementation conforms to the protocol. See Official SDKs .

How can I join the community or report a problem?

Join the A2A Discord, take part in GitHub Discussions, open an issue, or contribute code and documentation; the entry points are collected in the Community Hub . For suggestions or corrections about this site, email [email protected] .

Who governs the protocol, and how do I propose a change?

The Technical Steering Committee (TSC) is responsible for all technical oversight of the project. The TSC currently has nine seats, each held by one company; the list is in the upstream GOVERNANCE.md . TSC meetings are held on the Linux Foundation’s meeting platform and are intended to be open to the public. Discord suits everyday chat, but feature proposals and significant changes to the architecture or governance should be discussed on GitHub with adequate notice and time for comment; the project’s goal is for GitHub to be the source of truth for significant decisions. Extensions and custom protocol bindings also follow a tiered promotion process; see Extension and Protocol Binding Governance .

What is on the roadmap?

The upstream roadmap (last updated September 15, 2026) lists these near-term initiatives: v1.1 protocol enhancements and core robustness, bidirectional (BiDi) streaming, the A2A CLI and coding-harness integration, and elicitation and multi-turn workflows. Longer term it focuses on governance, validation tools (the A2A Inspector and the TCK), SDKs, and community best practices. See the Roadmap .

Source: A2A official documentation