A2A Protocol: How Agent2Agent Communication Works

The A2A Protocol (Agent2Agent Protocol) is an open standard that allows independent AI agents to discover each other, exchange information, and collaborate on tasks. Originally developed by Google and now governed under the Linux Foundation, it enables agents built with different frameworks to communicate without exposing their internal code, tools, or memory.

Think of a customer support agent that needs help from a separate billing agent operated by another company. A2A provides a standardized way to request that work, track its progress, and receive the result.

What interests me most about A2A isn't simply that agents can exchange messages. It's that they can work together while remaining independent systems. That's the part that changes how developers can design products around AI agents.

How the A2A Protocol Works

A2A uses a client-server model. An agent acting as a client requests work from another agent operating as an A2A server.

The remote agent receives the request, performs its work, and returns a response or task status. The client doesn't need to know which AI model the remote agent uses or how its internal tools operate.

The communication process has three main stages: discovery, authentication, and task execution.

Agent Discovery

Before sending a request, the client needs to identify an agent capable of handling the required task.

A2A uses an Agent Card, a JSON document describing an agent's capabilities and how to communicate with it.

An Agent Card includes information such as:

• The agent's name and description

• Available skills and supported input formats

• Service endpoints and protocol versions

• Authentication requirements

• Optional capabilities such as streaming and push notifications

Agents can also be discovered through configured URLs or agent registries.

I would treat the Agent Card as a service contract. It tells the client what an agent offers and how to reach it, but the client still needs to verify whether that agent is trusted and authorized to perform the requested work.

Authentication and Authorization

Once the client identifies a suitable agent, it follows the authentication requirements declared in the Agent Card.

A2A works with established security mechanisms, including OAuth 2.0 and other supported authentication schemes.

Authentication establishes the caller's identity. Authorization determines which resources and actions that identity can access.

These controls are separate from the AI model.

A client with permission to request an invoice summary should not automatically receive permission to modify invoices or initiate refunds.

I would enforce these boundaries at the service level rather than relying on instructions inside an agent's prompt.

Task Execution

After authentication, the client sends its request to the remote agent.

The receiving agent processes the message and can return an immediate response or create a task that continues through a defined lifecycle.

For a straightforward request, such as retrieving a prepared document summary, the response can arrive within the initial interaction.

For longer work, the client can monitor progress and retrieve the result when processing finishes.

This task-based design is what makes A2A more useful than a simple message exchange between chatbots.

It gives two independent systems a shared way to manage work that extends beyond one request and response.

Core Components of the A2A Protocol

Several objects define how A2A agents communicate. Understanding their responsibilities makes the protocol easier to work with.

The distinction between a Message and a Task deserves attention.

A Message represents communication. A Task represents work being performed.

An agent can exchange multiple messages while completing one task. It can also produce several artifacts before the task reaches its final state.

That separation lets an application maintain a conversation without confusing messages with completed work.

A2A Task Lifecycle and Status Management

An A2A task has a unique identifier and a defined state. The client uses these values to understand whether processing has started, finished, failed, or requires further input.

The protocol defines several meaningful states.

Submitted and Working

A task enters the SUBMITTED state when the server acknowledges it.

Once processing begins, the state changes to WORKING.

For a long-running research assignment, this allows the client to distinguish between a task waiting to begin and one actively being processed.

Input Required and Authentication Required

Some tasks cannot proceed without additional information.

An agent preparing an insurance quotation, for example, might need a missing policy detail.

The INPUT_REQUIRED state communicates that the task is waiting for further input.

A separate AUTH_REQUIRED state handles work that needs additional authorization.

This distinction matters in business applications. Missing information and missing permission require different responses from the client.

Completed, Failed, Rejected, and Canceled

A successful task reaches COMPLETED.

A task that encounters an execution error can enter FAILED, while an agent that declines the requested work uses REJECTED.

Cancellation has its own terminal state, CANCELED.

I would map these states directly to application behavior. A failed task should generate a visible failure result rather than leaving users waiting for work that has already stopped.

These states also help operations teams investigate where a distributed workflow broke down.

Communication Methods in A2A

A2A supports different methods for delivering task results and progress updates.

Choosing the appropriate method depends on how long the task runs and how quickly the client needs updates.

Request-Response Communication

The client sends a message and receives a response from the remote agent.

This is the simplest interaction model and works well for tasks that can return a result without a continuing stream of updates.

For tasks that continue in the background, the client can use the task identifier to retrieve their current status.

Streaming

Streaming allows the remote agent to deliver progress updates while work is underway.

This is useful for interactive applications where the user needs to see results as they become available.

For example, a research agent can report progress as it completes different stages of an investigation.

In the JSON-RPC and HTTP+JSON bindings, streaming uses Server-Sent Events (SSE). The protocol also supports streaming through its gRPC binding.

Streaming support must be declared in the agent's capabilities.

Push Notifications

Push notifications allow an agent to notify a client about task updates through a configured webhook.

This avoids requiring the client to maintain a continuous connection for the entire execution period.

For a document review that takes several minutes, the client can submit the request, continue other work, and receive an update when the task changes state.

I would choose push notifications for long-running backend integrations where maintaining an open stream adds unnecessary connection management.

A2A Protocol Architecture and Transport

A2A defines shared operations and data structures independently of the transport used to expose them.

The 1.0 specification supports three standard protocol bindings:

JSON-RPC: Uses JSON-RPC 2.0 over HTTP(S), with standard method calls and SSE for streaming.

gRPC: Uses Protocol Buffers and gRPC service operations. It is relevant to environments that already rely on gRPC infrastructure.

HTTP+JSON: Maps A2A operations to REST-style HTTP endpoints and JSON representations.

A remote agent declares its supported interfaces in its Agent Card. The client selects a compatible interface before communicating.

I prefer keeping transport decisions separate from agent responsibilities. The business logic should not depend on whether a client communicates through JSON-RPC or gRPC.

The same principle applies to the model itself. A2A doesn't require two agents to use the same model provider or development framework.

That independence is its primary interoperability advantage.

A2A Protocol Example in a SaaS Business

Consider a SaaS company that provides software procurement services to business customers.

A customer wants to purchase additional software licenses and requests a quotation.

The company's procurement assistant understands the request but doesn't have direct access to every software vendor's pricing and licensing systems.

Instead of integrating separately with each vendor's internal tools, the platform communicates with vendors that expose compatible A2A agents.

Vendor Agent Discovery

The procurement assistant identifies an approved vendor's A2A endpoint and retrieves its Agent Card.

The card confirms that the vendor agent supports pricing requests and quotation generation.

The procurement system then checks whether the vendor is approved for the customer.

Quotation Request

The procurement agent sends the vendor agent a request containing the product, license quantity, and relevant purchasing requirements.

The vendor agent creates a task and begins checking the available licensing options.

The client stores the returned task identifier so it can track the request.

Pricing and Approval

The vendor agent prepares a quotation and returns it as an artifact.

The procurement platform validates the quotation against the customer's purchasing requirements and checks whether the amount exceeds the approval threshold.

If approval is required, the application routes the proposed purchase to an authorized person.

The A2A protocol handles the interaction with the vendor agent. The procurement platform remains responsible for its own purchasing rules.

Final Result

After receiving quotations from approved vendors, the procurement assistant presents the available options to the customer.

The customer sees one coordinated purchasing experience even though the underlying information came from independent agent systems.

This is the connection between A2A and AI Agent Orchestration: A2A standardizes communication with independent agents, while the orchestration layer decides which agents to use, how their work fits together, and how the overall process reaches completion.

A2A Protocol and MCP

A2A and Model Context Protocol (MCP) address different integration requirements.

MCP standardizes how AI applications access tools, resources, and external context.

A2A standardizes how independent agents communicate and collaborate on tasks.

For example, a vendor agent could use MCP to retrieve pricing information from its internal systems while using A2A to communicate with a procurement agent operated by another company.

Both protocols can work in the same application.

I would not introduce A2A simply to replace an existing MCP tool connection. The decision depends on whether the remote system is exposing a specific capability or operating as an independent agent with its own task lifecycle.

Building an A2A Agent

The official A2A project provides SDKs and implementation guidance for developers building clients and remote agents.

I would begin with one agent acting as a client and another exposing a single well-defined skill.

That keeps the integration manageable while testing the essential protocol behavior.

Define the Agent's Capabilities

Start by identifying the work the remote agent can perform.

For a document-processing agent, this could be extracting invoice information or validating submitted documents.

Define accepted inputs, expected outputs, and the limits of each skill.

Avoid advertising capabilities that the agent cannot reliably execute.

Configure the Agent Card

Create an Agent Card that describes the agent and its supported interfaces.

Include accurate skill descriptions, authentication requirements, and optional capabilities.

For the 1.0 specification, supported interfaces identify their endpoint URL, protocol binding, and protocol version.

This information allows clients to choose a compatible connection without requiring knowledge of the agent's internal implementation.

Implement the Agent Server

The server receives protocol requests, validates credentials, and passes accepted work to the agent's execution system.

It also manages the task lifecycle and exposes the appropriate operations for retrieving status and results.

The agent framework handles the internal reasoning and tool execution. The A2A server provides the standardized external interface.

These responsibilities should remain separate.

Connect an A2A Client

Build a client that retrieves the remote agent's card, selects a supported interface, and authenticates according to the declared requirements.

The client can then submit tasks and process responses.

Start by testing a successful request, followed by a rejected request, missing information, and a server failure.

These cases provide a clearer picture of interoperability than a successful demonstration alone.

Test Protocol Compatibility

A2A 1.0 includes explicit protocol version handling.

Clients should declare the required version, and servers must handle supported versions according to the specification.

I would test the exact client and server versions planned for deployment rather than assuming compatibility based on the A2A name alone.

A2A Protocol Security and Trust

A2A enables independent systems to cooperate, but standardized communication does not establish trust by itself.

The remote agent still needs to authenticate callers and enforce authorization for every protected operation.

Agent Identity and Access

An agent's advertised capabilities are not proof that it should be trusted.

Applications need approved agent identities, secure endpoints, and authorization rules for the resources being accessed.

In a multi-customer platform, one customer must not be able to retrieve another customer's task by supplying its identifier.

Authorization checks must apply to task creation, retrieval, cancellation, and progress subscriptions.

Data Sharing

A remote agent does not need access to the requesting agent's internal memory, prompts, or private tools to perform an A2A task.

It receives the information supplied through the authorized interaction.

I would limit that information to the fields required for the requested operation.

A quotation agent needs licensing requirements. It does not need the customer's entire account history.

External Content and Agent Responses

Responses from remote agents should be treated as external data.

A document or message returned by another agent must not override the application's security rules.

Structured validation, output checks, and approval controls remain necessary when agent responses lead to financial transactions, account changes, or other consequential actions.

A2A Protocol Benefits and Limitations

The main benefit of A2A is interoperability.

Developers can connect independently operated agents through a standardized interface instead of creating a new communication format for every integration.

It also supports long-running tasks, structured outputs, and collaboration without requiring agents to reveal their internal implementation.

However, the protocol doesn't solve every problem involved in building reliable AI systems.

It doesn't guarantee that a remote agent's output is accurate, that a business transaction is authorized, or that a multi-agent workflow will reach the intended result.

Those responsibilities remain with the agents and applications using the protocol.

There is also an operational cost to distributed communication. Authentication, network latency, retries, monitoring, and remote service availability all affect performance.

I would evaluate A2A based on whether independent agent communication provides enough value to justify those dependencies.

Choosing A2A for an AI Agent Application

A2A is a strong fit when agents operate across service, team, or organizational boundaries.

For example, an internal procurement agent communicating with several independent vendors has a clear interoperability requirement.

A platform integrating third-party specialist agents faces the same challenge.

The decision changes when all agents run inside one application under the same development team.

In that situation, direct function calls or framework-managed agent delegation can provide simpler execution with fewer network dependencies.

I would introduce A2A when the application needs a standardized interface between independently managed agent systems, not merely because it contains more than one agent.

That distinction keeps the architecture aligned with the actual integration problem.

Final Thoughts

The A2A Protocol gives independent AI agents a shared way to discover capabilities, exchange messages, and manage collaborative tasks.

Its value is especially clear when different teams or organizations need their agents to work together without exposing internal implementations.

For developers, the most important design decisions remain outside the protocol itself: which agents to trust, what information to share, which actions to authorize, and how to handle failures.

I would start with one well-defined agent integration and expand only after validating communication, task handling, and access controls.

The goal isn't to connect every agent in a system. It's to make the connections that matter reliable, secure, and maintainable.

FAQ

Can I use A2A without putting my agents on the public internet?

Yes. A2A agents can communicate over a private network as long as the client can reach the server's endpoint. Public internet exposure is not required for internal agent communication.

Do I need to pay Google to use the A2A Protocol?

No. A2A is an open standard. There is no protocol licensing fee payable to Google. Hosting, model inference, cloud infrastructure, and commercial agent services can still generate costs.

Can I test A2A agents on my laptop before deploying them?

Yes. Developers can run an A2A client and server locally using compatible SDKs. Local testing should cover agent discovery, request handling, task transitions, and error responses before deployment.

Can I connect an older A2A agent to a newer one?

Compatibility depends on the protocol versions and bindings supported by both systems. A2A 1.0 provides explicit version handling. Clients and servers must agree on a supported version rather than assuming that all releases are interchangeable.

Is there one official directory where I can find every A2A agent?

No. A2A does not require a single global agent directory. Agents can be discovered through well-known URLs, configured endpoints, or registries maintained by service providers and organizations.

Can I connect A2A agents written in different programming languages?

Yes. A2A is language-independent. Agents implemented in different languages can communicate when their client and server implementations support compatible protocol bindings and versions.

Can I limit a partner to just one skill on my agent?

Yes. The agent server can enforce skill-level authorization based on the caller's identity and permissions. Advertising a skill in an Agent Card does not automatically grant every client permission to execute it.

What if an agent changes its Agent Card after my app has cached it?

The client should refresh its cached Agent Card according to the server's cache directives and its own refresh policy. After detecting changes, it must verify that the required skills, authentication methods, and protocol interfaces remain compatible.

Can A2A automatically handle payments between agents?

No. A2A standardizes agent communication and task exchange, not payment authorization or settlement. Financial transactions require separate payment infrastructure, explicit authorization, and appropriate transaction controls.

What happens if an A2A agent gets restarted during a long task?

Recovery depends on the server implementation. A2A defines task identifiers and status operations, but durable task storage and restart recovery must be provided by the application. A server without persisted execution state cannot guarantee that interrupted work will resume.