A2A Protocol: What It Is, MCP vs A2A, and When to Use It

Use the A2A protocol when your agent needs to delegate work to an independently operated agent. Use Model Context Protocol (MCP) when it needs access to tools or data. A2A v1.0 changes the integration contract, so the decision is about both the boundary you are crossing and the versions your endpoints support.

MCP vs A2A: Tools, Data, and Delegated Work

MCP gives an agent access to capabilities. A2A lets it ask another agent to take responsibility for a piece of work. They can belong in the same system.

Model Context Protocol (MCP) standardizes how an AI application connects to external systems, including tools and data sources. Agent2Agent (A2A) standardizes communication between independent agents. The official documentation describes them as complementary. MCP introduction, A2A and MCP.

MCP Example: Look Up an Order

Imagine a customer-support agent answering a delivery question. An MCP server exposes an order-lookup tool. The agent supplies an order identifier, receives the order data, and writes the customer response.

The business benefit is a reusable connection to the order system. There is no need to introduce another agent just to retrieve a record. The MCP server guide covers the tool-connection side of this decision.

A2A Protocol Example: Delegate a Supplier Shortlist

Imagine a purchasing assistant that needs a shortlist of suitable suppliers. A separate sourcing agent, operated by another vendor, owns the research workflow. The purchasing assistant sends the requirements, answers a clarification about delivery needs, and receives a structured shortlist.

The purchasing assistant does not need to know how the sourcing agent searches, which model it uses, or how its internal steps are arranged. It needs an agreed request and a useful result. That is the boundary A2A is designed to support.

The sourcing agent could use MCP internally to retrieve catalog data. In that design, A2A carries the delegation; MCP supplies the data access.

The distinction concerns the interface you need. An MCP tool can have sophisticated implementation logic behind it. Choose A2A when you want the other system exposed as an agent with discoverable skills and a work lifecycle, rather than deciding based on how intelligent its internals seem.

What Is A2A Protocol?

A2A is a common communication contract for agents built by different vendors or with different frameworks. It lets the caller interact with an agent without requiring access to its internal memory, tools, or decision logic. The protocol site calls these internals opaque. A2A overview.

The caller is the A2A client; the system accepting the request is the A2A server, also called the remote agent. For a founder buying a specialist capability, this means integration can focus on the service boundary instead of rebuilding the specialist's implementation.

Who Developed A2A, and Who Governs It?

The official site's wording is precise: “A2A was originally developed by Google and donated to the Linux Foundation.” It says a Technical Steering Committee maintains the project. The project therefore has a governance structure beyond its original developer. Governance and open source.

The a2aproject/A2A repository is the project entry point for the specification, SDK links, and samples. A2A itself is a protocol; you still choose the software that builds and operates your agents.

A2A Protocol Specification: The Terms You Need

The central distinction is between the conversation, the work being tracked, and its deliverable. Keeping them separate makes the protocol easier to design around.

Agent Card: How a Client Learns What an Agent Offers

An Agent Card is a JSON metadata document describing an agent's identity, skills, capabilities, connection information, and authentication requirements. It helps a client decide whether and how to contact that agent. Core concepts.

For the sourcing example, the card might advertise supplier-research skills. It is the starting point for integration, not proof that the resulting shortlist meets your purchasing criteria.

The documented well-known discovery path is /.well-known/agent-card.json. Cards can also be obtained through direct configuration or a curated registry. A2A does not prescribe a standard API for those registries. Agent discovery.

Tasks, Messages, Parts, and Artifacts

A task is a stateful unit of work with an identifier and a lifecycle. A message is a turn of communication. A Part contains the actual text, file content or reference, or structured data. An artifact is a concrete output produced during a task. Core concepts.

In the supplier example, “Which delivery region?” is communication. The tracked sourcing job is the task. The completed shortlist is an artifact. Your purchasing workflow should consume the shortlist as a deliverable, rather than search a conversation transcript for something that looks finished.

An agent can return a self-contained message or create a task. Related interactions are grouped by contextId. Once a task reaches a terminal state, a refinement starts a new task rather than restarting the old one. Life of a task.

That distinction matters when the buyer changes requirements after delivery. Keep the original shortlist identifiable and treat its revision as new work, so downstream users can tell which result they approved.

Transports: How the Same Contract Travels

A transport or protocol binding defines how the operations travel over the connection. The specification defines JSON-RPC, gRPC, and HTTP+JSON/REST bindings. The Agent Card's interfaces identify the endpoint, binding, and protocol version. A2A specification.

Polling, streaming, and push notifications concern how task updates arrive. They are a separate choice from the binding. For a purchasing dashboard, polling may be enough; for an interactive experience, incremental updates may matter. Check the actual endpoint's supported features before designing the interface around them.

What Changed in A2A v1.0?

Existing integrations need a compatibility review; changing a version string is insufficient. The following changes are those described in the official What's New page, comparing v0.3.0 with v1.0:

• A shared definition: a2a.proto becomes the authoritative protocol definition, with formal specifications for the protocol bindings.
• Different wire shapes: a unified Part replaces separate content types; member names replace kind discriminators, and enum values use SCREAMING_SNAKE_CASE.
• Reorganized Agent Cards: supportedInterfaces groups connection details, with the protocol version declared per interface.
• Updated operations: message/send becomes SendMessage; ListTasks adds filtered listing with cursor pagination.
• Enterprise changes: tenant fields, Agent Card signature-verification rules, and updated OAuth flows affect integration design.

These changes were verified against the project's What's New in v1.0 page on 12 October 2026.

For an existing connector, review serialized requests, response parsing, card discovery, and the operations you use together. A working connection alone does not establish that every interaction still behaves correctly.

Which Frameworks and Platforms Support A2A?

There are documented implementations, but their version and feature coverage differs. Choose by the behavior your workflow needs. The following support and limitations were checked against each maker's public documentation on 12 October 2026; no signed-in product test was performed.

Google Agent Development Kit

Google Agent Development Kit (ADK), a framework for building agents, documents to_a2a for exposing an agent and generating its Agent Card. Its Python A2A integration is labeled Experimental. The docs support a2a-sdk 0.3.x and 1.x.x, and direct new integrations toward 1.x.x. ADK exposing guide.

ADK also documents RemoteA2aAgent for consuming a remote agent. That gives an ADK builder documented entry points on both sides of a handoff. The experimental status belongs in the deployment decision even when the wrapper is convenient. ADK consuming guide.

LangGraph Through LangSmith Agent Server

LangSmith Agent Server, the serving layer documented for LangGraph deployments, exposes an A2A endpoint at /a2a/{assistant_id}. Its documentation specifies the v1.0 JSON-RPC binding and acceptance of v0.3 method names. The graph needs a messages field in its state. LangSmith A2A documentation.

The same page lists limits: gRPC and HTTP+JSON are not implemented, and SubscribeToTask and push-notification configuration are not yet supported. Streaming a message is supported, but that does not imply every subscription or notification operation exists. This is a concrete reason to inspect operation coverage before choosing a background-job design.

CrewAI and CrewAI AMP

CrewAI, a framework for coordinating agents, documents A2AClientConfig for remote delegation and A2AServerConfig for exposing agents. An agent can be configured for both roles. CrewAI delegation documentation.

CrewAI AMP, its deployment platform, labels A2A server agents early release and lists protocol versions 0.2 and 0.3. It also describes persistent distributed storage in place of the open-source implementation's in-memory state. Do not translate the existence of CrewAI A2A support into an assumption that an AMP endpoint supports v1.0. A2A on AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service, a managed agent platform, documents a generally available a2a tool type for protocol 1.0. Its older a2a_preview tool type supports 0.3 and remains in preview. Microsoft recommends the generally available type for new integrations. Foundry A2A documentation.

The page also states that Foundry agent targets support text only and do not support streaming responses. A workflow that needs a streamed multimedia deliverable must account for that limitation. A protocol's possible content types are not a promise that every hosting platform implements them.

Use the AI agent frameworks comparison for the broader framework decision. These integration notes answer a narrower question: what A2A interface does the serving system document?

What This Means for Builders, Operators, and Buyers

The payoff is a more reusable integration boundary, provided the added service is worth operating. The consequence differs by who owns the decision.

Builders: define what you delegate before adding a transport. “Produce a shortlist with sources and reasons” is a service boundary. “Call this database lookup” is a tool boundary. Preserve that distinction even if both ultimately trigger model calls.

Operators: assign an owner to the task after handoff. In the purchasing example, someone must decide what happens if sourcing requests more information, stops responding, or returns a shortlist that fails acceptance criteria. A shared message format does not settle those responsibilities.

Buyers and founders: ask for the supported protocol version, binding, operations, content types, and deployment status. Put those details beside your workflow requirements. A compatibility claim without that detail is insufficient for an integration commitment.

How to Budget an A2A Deployment

A2A has no single deployment configuration from which to compute your monthly bill. A hosted specialist and a service you operate have different cost inputs, and the protocol documentation does not establish a universal platform price.

Use this planning equation over the same budget period:

Net integration benefit = avoided connector costs minus migration costs, added infrastructure costs, and ongoing operating costs.

Count model usage, hosting, task storage, monitoring, and incident ownership among those operating inputs. Use your own costs for each term. A2A earns its place when it removes enough repeated integration work to cover the new boundary you must maintain.

What's Overhyped About A2A?

A common protocol does not make unfamiliar agents trustworthy or distributed work automatically reliable. Its useful standardization still leaves application decisions with you.

An Agent Card advertises what a service offers. You still decide whether to trust its operator and accept its output. A2A's enterprise guidance assigns authentication and authorization enforcement to the implementation, including permissions on underlying actions. Enterprise implementation guidance.

For the sourcing workflow, allow research without silently granting purchasing authority. Returning a recommendation and placing an order should be separate permissions in your application.

Treat a returned artifact, its task status, and your own acceptance record as separate things to manage. Before allowing a delegated workflow to create a purchase order, decide how your application detects repeated business actions and recovers an uncertain outcome.

Another overreach is adding A2A to every internal sub-agent call. The project's own scope explicitly excludes prescribing an agent's internal sub-agent or tool calls. If the components live under the same application contract, your framework's native composition may already serve the job. A2A scope.

Do I Need A2A, MCP, or Both?

Start with the boundary that exists in your product today.

Choose MCP when an agent needs access to business systems, files, or APIs through reusable tool interfaces. If you need to expose a capability yourself, follow the Python MCP server guide. When the challenge becomes governing access across those connections, the MCP gateway explainer addresses that layer.

Choose A2A when another independently operated agent owns a meaningful job and you need a common way to discover its interface, exchange instructions, and follow the resulting work. Act now if you already have that integration requirement and the endpoints document compatible features.

Choose both when your agent delegates to a specialist that also needs tools and data. The sourcing example fits: A2A for the delegated research job, MCP for catalog access inside an agent.

Wait on A2A when the external specialist is still hypothetical. An agent that works adequately with its current tools is unaffected by the existence of a new inter-agent protocol. You also do not need either standard for every internal function call. Adopt the connection contract that solves an actual integration problem.

Your Next Build Step

Write the handoff contract for a narrow business result before migrating the surrounding stack. For a purchasing assistant, start with a supplier shortlist, leaving purchase execution outside the initial scope.

1. 1

   Define an acceptable artifact

   Specify the information the shortlist must contain, what makes it unacceptable, and which application records the accepted result. Give the remote agent a bounded responsibility.

2. 2

   Match the documented interfaces

   Record the client and server protocol versions, binding, authentication requirements, and required operations. Check whether the workflow needs streaming or push delivery and whether both endpoints support it.

3. 3

   Design the unfinished outcomes

   Decide who handles clarification, timeout, rejection, and an uncertain response after a retry. Define what the user sees while work is pending and how a revised artifact replaces an earlier one.

That contract gives you a concrete basis for adding A2A. If writing it reveals that the supposed specialist only retrieves a record, implement the tool connection first.

Questions Before You Add A2A

Can I use A2A without MCP?

Yes. A2A does not prescribe how the remote agent reaches its own tools and data. MCP is useful when you also need standardized tool connections. How they work together.

Do both agents have to use the same framework?

No. Cross-framework interoperability is a central purpose of A2A. What must align is the exposed interface and the features the interaction requires, not the agents' internal implementation. A2A overview.

For practical guides to building useful agent systems, join the newsletter.