A2A protocol: how agents exchange work

Agent2Agent (A2A) gives agents on different platforms a shared way to exchange work. Learn how a handoff works, how the A2A protocol differs from MCP, and what to check before deployment.

Your support agent needs a product specialist’s answer before you can update a customer. The specialist runs on another platform, with its own tools and workflow. How do you ask for help, follow the work, and get back something you can use?

Without a shared interface, your team must agree those communication details for each integration. The A2A protocol provides common rules for that exchange without requiring either agent to expose its internal workflow.

You’ll follow a support request from discovery to an accepted answer, compare A2A with MCP, and build a deployment checklist. Once the handoff makes sense, you can decide what information may cross it and who owns an unfinished result.

TLDR

• A2A helps independently built agents discover capabilities, exchange requests, and return results.
• A2A and MCP serve different primary interactions: agent collaboration and access to tools, resources, and prompts.
• A usable handoff needs a clear request, supporting evidence, and an owner for interrupted work.

What is the A2A protocol, and why does it matter?

The A2A protocol is an open standard that lets independently built AI agents describe capabilities, exchange messages, track tasks, and return results. Agents can collaborate across platforms without sharing their internal implementation.

The requester asks for work. The remote agent receives that request and performs work through its own implementation. In the support example, your support agent is the requester; the product specialist is the remote agent.

This agent to agent protocol gives both sides a common interaction model. Your support workflow doesn’t need to reproduce how the specialist investigates a product issue.

That’s the payoff of agent interoperability: different implementations can cooperate through an agreed interface. Business-specific decisions still sit around that interface, including which evidence makes a result useful.

This article uses the released A2A 1.0.0 specification for protocol behavior. Check your counterpart’s supported version rather than assuming changing documentation describes the deployment you’re connecting to.

How does A2A work?

An A2A handoff moves from finding a suitable agent to requesting work and receiving a result. Longer tasks can include progress updates or requests for additional input.

Find the specialist through an Agent Card

An Agent Card is a published description of an agent’s capabilities and connection requirements. It tells your client what skills the agent advertises and how to interact with it.

The specification describes discovery through a well-known address, a registry or catalog, or direct configuration. The well-known path is /.well-known/agent-card.json.

For the support task, look for a skill that can investigate product status, not merely generate general product explanations. The relevant question is whether this specialist can return evidence for the issue you need checked.

Check the interface and supported features

Check the declared version, connection interface, authentication requirements, and capabilities before sending the request. An interface describes how the systems exchange protocol operations.

For example, a client expecting streaming updates needs a counterpart that advertises that feature. Otherwise, use another supported way to retrieve progress and results.

A card is an advertisement, not a test report. Verify the destination and exercise the relevant skill before trusting it with production work.

Send a focused request

Specify the question, the relevant identifiers, and the result you need. A support-status request might identify the product issue and ask for its current status, source references, and effective time.

Pass the minimum permitted context. If a product reference is sufficient, the specialist doesn’t need the customer’s entire conversation history.

The shared knowledge context matters when the relationship between a customer request and a product issue needs explanation. Include that relationship where permitted, not unrelated records.

Follow progress when the task takes time

Sending a message can return a direct reply or a tracked task. A task gives the requester an identifier for following ongoing work.

Depending on supported features, the requester can retrieve task state, receive streamed updates, or use webhook notifications. A webhook is a callback sent to a configured receiving endpoint.

The client also needs to handle interruptions. Missing input calls for a different response from a rejected task or a request to satisfy authentication requirements.

Receive the result and check it

Task results can arrive as artifacts, such as returned text or structured data. A protocol task reaching completion tells you about the task’s state, not whether your business should accept its answer.

Your support workflow checks the requested issue, evidence, and freshness before using the result. That check turns a technically successful exchange into useful work.

A2A vs MCP: which interaction do you need?

Use A2A for collaboration with an independently implemented agent. Use the Model Context Protocol, or MCP, to expose tools, resources, and prompts to an AI application.

The MCP architecture specification describes that application–server relationship. A product specialist could use MCP to retrieve an issue while using A2A to communicate with your support agent.

Choose the interaction you need to standardize, rather than treating the protocols as competing products.

These are primary roles, not rigid architectural categories. An agent capability can also be exposed through a tool interface, and using one protocol doesn’t require adopting both.

The MCP protocol guide covers tool connectivity. For routing work among several agents, use the separate agent orchestration guide.

A support handoff from request to accepted answer

Here’s what a completed exchange could look like. The records below are illustrative; this is not a customer deployment or an A2A wire-format payload.

The support owner has linked customer issue 417 to product issue P-82. They need a draft update, not a new record or a message sent to the customer.

The handoff produces a usable answer because the evidence supports its claims, not merely because a task completed.

Notice what the specialist did not conclude. “Merged” did not become “released,” and missing timing did not become an invented delivery promise.

The support owner now has the status they needed and a specific uncertainty to explain. They don’t have to reconstruct the specialist’s investigation from an unsupported summary.

Acceptance of the draft remains separate from sending it. The example’s requested work ends at a supported answer ready for the appropriate communication step.

What should you check before deployment?

Group implementation checks around access, evidence, and recovery. State the boundaries once, then test how each changes the handoff’s behavior.

Establish who may do what

Talking to an agent doesn’t grant it authority. Authentication identifies the caller; authorization determines which operations and resources that identity may use.

A task ID identifies work, and a context ID groups related interactions. Neither is an access grant. A verified card signature can establish origin and integrity under your trust configuration, not operational permission or performance.

The acting identity might represent a person or an approved background service. Define its resource scope and permitted operations rather than assuming every task has a live human session.

The agent authorization guide covers enforcement. Your handoff record should identify the responsible identity and policy, without reproducing a complete permission model.

Handle missing evidence and additional authorization differently

If the specialist cannot find RN-12, it should report what remains unverified. Missing evidence does not justify borrowing a status from a different issue.

A request for additional authorization is a different interruption. A2A 1.0.0 defines TASK_STATE_AUTH_REQUIRED and describes authorization requests during a task in its in-task authorization section (7.6).

For example, a specialist may need credentials for a protected source. The request must communicate what authorization is needed, unless that detail was agreed separately.

The pinned specification describes out-of-band credential delivery unless an in-band method has been negotiated. In plain language, use the agreed secure channel rather than casually inserting credentials into task messages.

Section 7.6 also allows human-approval requests, such as approval before a destructive action. That doesn’t make every business review an authentication event, or make the state itself a permission grant.

Your implementation must identify the requirement and how it is satisfied. An approval to use an answer does not automatically supply credentials for the source behind it.

Assign cancellation, duplicate prevention, and recovery

Now change the task: the specialist is authorized to create a follow-up item, but result delivery is interrupted after creation. The requester doesn’t know whether the item exists.

A cancellation request is an attempt. The A2A cancellation behavior explicitly says success is not guaranteed.

Even successful cancellation does not prove that the earlier follow-up item was removed. Check the task outcome and the external record before deciding what happens next.

Likewise, resending the original request can repeat work. A2A does not guarantee that message submission is idempotent, meaning repeated requests have no additional effect.

Your application needs a duplicate-prevention strategy appropriate to the downstream operation. That may combine request correlation, supported deduplication controls, and reconciliation of existing records.

None of those words promises exactly-once execution. Test retries after uncertain delivery, and assign someone to inspect completed effects before retrying or repairing them.

The agent delegation guide covers attribution and recovery responsibilities. Here, record which owner resolves the external effect and which owner updates the waiting support team.

These answers address common design choices without assuming every implementation supports the same features.

Is your handoff ready to test?

Use this handoff readiness worksheet for one handoff, then test a supported result, missing evidence, denied access, uncertain delivery, and a duplicate request.

A handoff is ready to test when both sides know what useful completion and recoverable failure look like.

If you’re evaluating Computer, by DevRev, bring this readiness worksheet to the discussion with the people who will accept the handoff result and own its recovery. Ask which proposed connections and controls can be demonstrated for your workflow, including any required protocol support.

The next step isn’t another architecture diagram. It’s a review of one handoff, with the people who will accept its result and own its recovery.