---
Title: "A2A protocol: agree the handoff before agents act"
Url: "https://devrev.ai/blog/a2a-protocol"
Published: "2026-10-05"
Last Updated: "2026-10-05"
Author: "DevRev Editorial"
Category: "Product & Engineering"
Excerpt: "Two agents can exchange a task without agreeing on who may change a record or what proves completion. Follow one specialist handoff, separate protocol behavior from deployment decisions, and establish who owns the result when the work stops halfway through."
Reading Time: 11
---

# A2A protocol: agree the handoff before agents act

An agent can receive your task without receiving permission to do everything that task might involve. Your architecture needs to preserve that distinction.

The A2A protocol gives independently built agents a shared way to exchange work. Your deployment still needs decisions about access, acceptable results, and unfinished effects.

Consider a hypothetical support workflow. Your agent asks a product specialist on another platform to check an issue before you update a customer.

Reading the issue, creating a follow-up, and sending the update are separate operations.

A compatible interface makes the conversation possible. It doesn’t settle who may perform each operation.

## TLDR

- An Agent Card advertises what another agent supports; it does not independently prove trustworthy performance.
- Task identifiers track work. Authentication, authorization, and business acceptance require their own checks.
- A cancellation request can fail, and successful cancellation does not guarantee reversal of earlier external actions.

## What is the A2A protocol?

The A2A protocol is an open agent-to-agent communication standard. It defines how independent agents describe their capabilities, exchange messages, track tasks, and provide results. It supports collaboration without exposing every internal implementation detail. Authentication, authorization, and the criteria for accepting completed business work still need appropriate deployment controls.

This guide uses the [released A2A 1.0.0 specification](https://a2a-protocol.org/v1.0.0/specification/) for protocol claims. A versioned source matters because changing documentation can include material beyond a released snapshot.

You don’t need to rebuild another agent’s internal workflow to collaborate with it. You do need to understand its supported interface and the terms of the interaction.

An agent to agent protocol therefore solves a narrower problem than an enterprise operating policy. It gives systems shared communication rules, while leaving consequential business decisions with their owners.

For agent interoperability, that separation is useful. Your counterpart can keep its internal implementation while exposing a task interface you can verify.

## What does your agent need from the other side?

Start with the result you need, not the connection you can establish. For the support example, you need verified product-status evidence for the correct customer issue.

The specialist might use a different model, knowledge source, or tool stack. That internal difference need not prevent cooperation, but it doesn’t excuse an unverifiable answer.

Define the request before discovery: identify the issue, the permitted customer context, the evidence required, and information that must not cross the boundary.

If the specialist only needs a product issue reference, don’t send an entire customer conversation. If access to customer-specific records is necessary, establish the permitted scope explicitly.

The [shared knowledge context](https://devrev.ai/blog/ai-knowledge-management) matters here because an identifier alone may not explain the relationship between a customer request and a product issue. Pass the permitted relationship, not every available record.

### An Agent Card starts discovery, not trust

An **Agent Card** describes advertised capabilities and interaction requirements. The A2A protocol supports discovery through a well-known location, registries or catalogs, and direct configuration.

The well-known path is `/.well-known/agent-card.json`. Finding a document there is the beginning of verification, not its conclusion.

Check the destination, the supported version, and the interface your client will use. Then inspect declared skills and authentication requirements against your intended task.

Optional capabilities deserve particular attention. Streaming support advertised by one agent doesn’t mean another agent supports it, so test what your chosen counterpart actually implements.

A verified card signature can help establish origin and integrity under your trust configuration. It cannot demonstrate that the advertised skill works correctly or handles information appropriately.

Treat the card as a set of claims you can inspect and test. Your acceptance record should identify which claims matter to the specific handoff.

An outdated card also creates an operational question. If the counterpart changes its interface or permissions, who detects the change and decides whether the integration may continue?

That responsibility belongs in your operating agreement, even when discovery itself is automated.

## A2A vs MCP: which interaction are you standardizing?

Use A2A when the interaction involves an independently operated agent. Use MCP when an AI application needs a standard interface to tools, resources, or prompts.

Those are primary roles, not an absolute architectural boundary. An agent capability can appear through a tool interface, and a specialist agent can use MCP internally.

The [official A2A and MCP comparison](https://a2a-protocol.org/latest/topics/a2a-and-mcp/) describes their complementary use. It does not require every architecture to adopt both protocols.

In your support workflow, A2A could carry the request to the product specialist. That specialist might use MCP to access an approved information tool.

| Decision | A2A’s primary interaction | MCP’s primary interaction |
| --- | --- | --- |
| Who is the counterpart? | Another agent with its own implementation | A server exposing capabilities to an AI application |
| What is exchanged? | Messages, task-related updates, and results | Tool calls, resources, prompts, and related protocol interactions |
| What remains your responsibility? | Trusted counterpart, authorized task, accepted evidence, and recovery ownership | Approved server, permitted capability use, data handling, and application controls |
| What should you test? | The actual handoff, including interruption and result acceptance | The actual exposed capability and its access/action boundaries |

In short: the A2A protocol standardizes the interaction you need; you still test the controls surrounding that interaction.

Keep transport terminology separate from business authority. The inspected [MCP transport specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports) defines stdio and Streamable HTTP. HTTP responses can use server-sent events; SSE is not the entire architecture.

The [MCP protocol](https://devrev.ai/blog/mcp-protocol) guide covers tool connectivity in more depth. Your A2A design should not become a second MCP implementation tutorial.

Likewise, [agent orchestration](https://devrev.ai/blog/ai-agent-orchestration) covers coordination patterns. A protocol supplies interaction conventions; it doesn’t decide every routing rule or choose your business process.

Avoid selecting a protocol by drawing a horizontal arrow and a vertical arrow. First identify the counterpart, the operation, the evidence, and the failure you need to handle.

Then decide whether a standard interface improves that relationship. A small, stable integration may not need the same architecture as a changing network of independently operated agents.

## Agree the responsibilities before sending the task

Write down what protocol conformance supplies and what your deployment must establish. Otherwise, each owner may assume the other side handles the missing control.

The A2A protocol includes authentication and authorization requirements. It doesn’t prescribe one universal authorization model for every receiving agent.

For the hypothetical support task, define who may request the lookup, which records the specialist may access, and what result the support owner will accept.

Use this responsibility ledger before testing. The deployment column contains proposed review questions, not capabilities guaranteed by adopting A2A.

| Review item | Protocol support | Evidence your deployment owner needs |
| --- | --- | --- |
| Discovery | Agent Card, declared skills, and supported interfaces | Trusted destination, compatible version, and a tested skill matching the task |
| Authentication | Declared security requirements and authenticated request handling | Appropriate credential, validation, expiry, and identifiable caller |
| Authority | Authorization checks under the receiving agent’s model | Permitted operation and resources, including any applicable delegation limits |
| Context | Messages, parts, and identifiers relating the interaction | Minimum necessary records, tenant boundaries, source age, and handling rules |
| Result | Task status and artifacts where applicable | Required source match, actual result, and a named acceptance owner |
| Interruption | Input requests, authorization requests, and cancellation operations | Response owner, cancellation outcome, completed effects, and recovery responsibility |

In short: a shared message format does not remove the need to assign and test each responsibility.

### Identity and task references answer different questions

Authentication establishes the caller’s identity under the configured scheme. Authorization determines whether that caller may perform the requested operation against the relevant resources.

A task ID identifies work. A context ID connects related interactions. Neither identifier is an access grant, even when it appears in an authenticated request.

Your deployment might act for a person or use an approved service identity for background work. Don’t manufacture a human session to make the authority chain look familiar.

Define the relevant principal, purpose, permitted resources, and operations in either case. When authority is delegated, preserve its actual limits rather than treating delegation as unrestricted impersonation.

The deeper [agent authorization](https://devrev.ai/blog/ai-agent-authorization) question is whether the policy is enforced at the operation that could expose data or change state. A descriptive field alone cannot do that work.

Human approval adds another decision. It doesn’t create a resource permission that the acting identity lacks.

### Define the result your team will accept

A completed protocol task is not necessarily an accepted customer outcome. Your specialist could finish successfully while returning evidence for the wrong issue.

Require the source references your workflow actually needs. In this example, that includes the requested product issue, the applicable status, and the evidence’s effective time.

Decide what the specialist should return when evidence is missing. An explicit inability to verify status can be the correct response. A confident substitute from another account cannot.

The acceptance owner should distinguish a supported draft from permission to send it. That final operation may have a separate reviewer and a different risk boundary.

Keep the record useful without collecting everything. Store necessary identifiers, decisions, and results under appropriate access and retention rules. Don’t assume every deployment needs immutable storage or cryptographic hashes for every field.

## When the specialist cannot finish the task

An interrupted task needs a decision, not a hopeful retry. Inspect what happened and which operations remain authorized before sending more work.

A2A task handling includes states beyond submitted, working, completed, failed, and canceled. Input-required, auth-required, and rejected states change what the caller should do next.

Your client needs explicit handling for the states its counterpart returns. Otherwise, an authorization request can become an unexplained timeout or a repeated operation.

### An authorization request is not authorization

Suppose the specialist can read the issue but needs additional authorization to create a follow-up item. It returns an authorization-required state rather than proceeding.

That state signals a requirement; it doesn’t grant permission. Your configured workflow must determine who can satisfy the requirement and how that authority is established.

Keep the requested operation specific. Approval to create a tracking item does not also approve sending a customer message or updating another account’s record.

If the necessary authority cannot be established, the useful outcome may be a supported explanation of the limitation. Avoid turning every refusal into a recovery loop.

The [agent delegation](https://devrev.ai/blog/ai-agent-delegation) guide explores grants, attribution, and repair. A2A adds the interoperable interaction contract; it does not replace those responsibilities.

### Cancellation leaves a recovery question

Now suppose an authorized tracking item was created, but the specialist’s result delivery stalls. Your support workflow sends a cancellation request.

The [A2A cancellation operation](https://a2a-protocol.org/v1.0.0/specification/) attempts to cancel the task. The specification does not guarantee that the attempt succeeds.

Check the returned outcome instead of assuming the request took effect. The task may no longer be cancelable, or the work may already have completed.

Even successful cancellation does not establish that the tracking item disappeared. Record the completed effect and decide whether it should remain, be amended, or be removed through an authorized operation.

Retrying the entire workflow without that check can create another item. A transport timeout doesn’t tell you whether the external change succeeded.

Assign an owner for reconciling the actual state. Also assign someone to communicate the result to the customer-facing team, which may still be waiting for a usable answer.

## Review one handoff before expanding the network

Test the agreement against cases that could change the result. A successful demonstration of one lookup leaves interruption, denial, and evidence failure unexamined.

Run a permitted task with the expected source. Then run a task with missing evidence, a request outside the permitted scope, and an interrupted result delivery.

Add a duplicate-request case where an earlier action may already have happened. Specify the expected record state and acceptance evidence before running it.

A refusal can pass the intended control test. A fluent answer can fail it. Your test results should preserve that distinction rather than reward completion at any cost.

Keep the responsible owners in the review. A platform engineer can confirm the A2A protocol behavior at the interface while the service owner rejects inadequate customer evidence.

Neither review substitutes for the other. Together, they establish whether this particular handoff is ready for the work you intend to assign.

These questions separate protocol features from decisions you must make in the deployment. Use the answers to resolve disagreements before expanding access.

Start with the handoff your team already wants to trust. Name its permitted work, minimum context, acceptance evidence, and recovery owner.

If any row lacks an answer, that is the next architecture decision. Adding another agent can wait.

## FAQ

### Does A2A replace MCP?

No. Their main roles differ: A2A supports interactions between independent agents, while MCP exposes tools, resources, and prompts to AI applications. You can use them together or choose only the interaction your architecture needs. An agent capability may also be exposed through a tool interface, so avoid rigid architectural categories.

### Does an Agent Card prove an agent is trustworthy?

An Agent Card advertises capabilities and connection requirements; it does not independently validate performance or safe behavior. A verified signature can establish origin and integrity under your trust configuration. You still need to test the relevant skill, verify the destination, and decide which data and actions the counterpart may receive.

### Do task and context IDs transfer permissions?

No. Task identifiers locate work, while context identifiers relate interactions. They do not authorize access to a customer record, tool, or external system. The receiving agent must apply its authentication and authorization requirements. Any delegated authority needs an explicit, enforceable scope appropriate to the operation, rather than an identifier alone.

### Does canceling an A2A task undo completed actions?

No. The cancellation attempt may fail, and a successfully canceled task may still have earlier external effects. Check the resulting task state and any completed operations before retrying. Reversing or repairing an external change requires a supported mechanism and appropriate authority; cancellation alone does not establish either of those conditions.