Where A2A fits in the open agent ecosystem

Imagine a restaurant manager agent coordinating an urgent ingredient order. Through A2A, it works with supplier agents that can quote price and delivery while managing the order as a stateful task. The manager agent

uses MCP to read the restaurant’s inventory system. Once it chooses a supplier, UCP structures the checkout and AP2 provides verifiable proof that the purchase was authorized.

No single protocol needs to own that entire interaction; each needs to make its part precise enough that another part can connect to it.

That principle has guided A2A from the beginning. A2A gives independent agents a shared way to communicate and manage work. It leaves tool access and other specialized concerns to protocols built for those jobs.

With A2A now part of the Agentic AI Foundation, we have an opportunity to make those boundaries easier to understand and the tooling around them more interoperable. We also have more work to do with neighboring communities so the boundaries hold up in deployed systems.

Give independent agents a contract for work

An agent interaction often begins before either side exchanges a message. A client first needs to know what a remote agent can do and how to reach it. An A2A server can publish an Agent Card for public discovery. The card describes the agent's skills, supported interfaces, protocol versions, and security requirements.

The Agent Card is a contract for starting an interaction. It helps a client decide whether the remote agent is suitable for a task, tells the client which A2A binding the agent supports, and describes the security scheme required by the server.

The interaction then moves through A2A messages and tasks. A simple request can receive a direct message, and work that takes longer can become a stateful task with its own identifier. A single interaction isn't limited to one task. A client can spawn several related tasks toward a larger piece of work, each tracked independently. Any task can report progress, produce artifacts, and even pause when the remote agent needs more input or authorization.

Those details distinguish agent collaboration from a single function call, long running tool, or local subagent. The remote agent owns its execution and may reason over private context or call several internal tools. But the client doesn’t need access to that implementation. It only needs a stable contract for assigning work and following the result.

And that contract is independent of a single wire format. The A2A specification defines a canonical data model and a set of abstract operations, allowing the same collaboration semantics to work across different protocol bindings.

A task remains a task whether a deployment chooses gRPC or an HTTP endpoint. It also gives the community room to develop custom bindings without changing the core collaboration model.

Let MCP connect an agent to its tools

MCP and A2A are often placed next to each other because both support agentic systems. However, they operate at different relationships in those systems.

MCP defines how an AI application connects to servers that expose tools, resources, and prompts. An MCP tool has a described input and output, and the host controls the connection and the security boundary around it.

A2A defines how one independent agent works with another. The remote agent can negotiate the scope of a request and maintain a task over time. It can request additional input and produce intermediate updates. The remote agent decides how to complete the work behind its endpoint.

The restaurant example uses both relationships. Through A2A, the manager agent asks a supplier agent to source an ingredient. The supplier can manage the work over several turns, including suggesting a substitution when the requested item is unavailable. The manager agent uses MCP to connect to its internal inventory system and retrieve the data needed to make the request.

The boundary depends on the interaction rather than the code behind the endpoint. MCP provides a standard way for an AI application to use tools and access context. A2A provides a standard way for independent agents to delegate and manage work. The same system may expose both interfaces for different kinds of interaction.

An A2A skill (not to be confused with an Agent Skill) which advertises an agent’s capabilities could be represented as an MCP resource or tool when the skill has simple invocation semantics. Protocol boundaries should support practical composition without pretending that every interaction has the same shape.

Add domain rules through extensions

Agent collaboration becomes more demanding when an interaction enters a regulated or specialized domain. A generic task model cannot define every rule for commerce and financial services. Adding every domain rule to the A2A core would make the protocol harder to implement and slower to evolve.

A2A extensions provide a controlled way to add those rules. An agent declares supported extensions in its Agent Card. A client requests an extension by URI, and a required extension must be understood by both sides before the interaction proceeds. Extensions can add structured data or extra methods. They can also add requirements to the task state model.

Commerce provides a concrete example. The Universal Commerce Protocol (UCP) defines an A2A binding for checkout. A business advertises UCP support through an extension in its Agent Card, then exchanges structured checkout data within A2A messages. When Agentic Payment Protocol (AP2) is used, the UCP binding defines an AP2 mandates extension for carrying verifiable payment authorization within the same interaction. A2A manages the messages and task context, while UCP and AP2 define the commerce-specific data and authorization rules.

Reuse the web below the agent layer

A2A depends on standards that have already solved common infrastructure problems. Production deployments use HTTPS or TLS. Agent Cards can declare OAuth, SPIFFEE, and other security schemes. Signed Agent Cards use JSON Web Signatures so clients can verify that the published metadata has not been changed.

Discovery follows the same approach. A2A standardizes the Agent Card and its well known URL. It does not prescribe one global agent registry. Organizations can use a public catalog or an internal registry. They can also configure Agent Card locations directly. The Agent Card remains the common description that each discovery system returns.

The transport model follows the same principle. A2A 1.0 defines bindings for HTTP with JSON, JSON-RPC, and gRPC. The custom binding framework also gives the community a path to explore other transports while preserving A2A’s collaboration semantics.

Reusing established standards reduces the amount of new infrastructure every A2A implementation must invent. It also allows existing gateways, identity systems, and observability tools to participate in an A2A deployment.

Keep the seams open

The open agent ecosystem will continue to add protocols. Some will describe new domain objects. Others will address identity or user interfaces. A2A should give those efforts a dependable collaboration layer and clear places to connect.

Becoming an AAIF project puts A2A alongside communities working on other parts of agentic infrastructure. The useful outcome will come from technical coordination, and that coordination happens in the details. AAIF gives maintainers a place to work through overlap with neighboring projects in public. Clearer boundaries and shared guidance will help developers choose the right protocol for each interaction and understand how the pieces work together.

If you maintain another open protocol that needs agents to delegate work, we want to understand the interaction you are trying to support. Bring a concrete flow to the A2A project on GitHub and let’s explore where the protocols meet.