A2A: Handing Work to Another Agent Without Losing the Task Boundary

A travel-planning assistant can ask a specialist agent to assemble an itinerary. That is a different interaction from calling a simple fare-lookup tool: the specialist may work asynchronously, request more information and return several artifacts. A2A gives these interactions a shared structure.

If the specialist charges for its work, task communication and commercial agreement must remain distinct. “The remote agent accepted the task” should not quietly mean “the user approved any resulting bill.”

Research boundary: official A2A documentation reviewed November 1, 2026. This is a conceptual integration review, with no remote agent invoked, reservation made or payment executed.

Discovery tells you what a service advertises

The A2A overview positions the protocol around agent communication and collaboration. Its discovery guide describes Agent Cards: service descriptions containing information such as capabilities, skills, endpoints and authentication requirements. Cards can be found through a well-known endpoint, a registry or direct configuration.

For a commercial client, discovery is the start of evaluation. A service advertising itinerary planning still needs to agree on the task’s scope, acceptable inputs, expected deliverables and any price. Keep that agreement in application data rather than relying on a skill description to function as a contract.

Conceptual paid-service workflow using A2A, not a tested implementation. Scope agreement and acceptance are application responsibilities.

A task has a lifecycle, not just a response body

The task-lifecycle guide distinguishes immediate messages from stateful tasks. A task can report progress, require input or authorization, and eventually reach a terminal state. Context and task identifiers help relate the exchanges.

For the itinerary example, a request for travel dates should pause the dependent work. It should not encourage the calling agent to invent missing preferences. Likewise, a request for authority should return to an appropriate authorization process, not be treated as a retryable network error.

Keep three kinds of status separately:

Record	Question it answers
Remote task state	What is the other agent currently doing?
Commercial/payment state	What was agreed, authorized or charged?
Client acceptance state	Does the delivered artifact meet the request?

This is our proposed integration model. A task marked completed may still need output review; a canceled task does not, by itself, establish that a charge was reversed or a booking canceled.

Losing a stream should not create a second job

A2A’s asynchronous-operation documentation covers streaming and push-based updates for longer-running work. Those channels improve observability, but an application still needs a recovery plan when a client disconnects or a notification is delayed.

Persist the remote task reference before handing control back to the caller. On reconnect, inspect the known task using the chosen implementation’s supported mechanism. Do not turn “I stopped receiving updates” into “the provider never started.” That distinction is especially important if submitting a new task could incur another charge.

A proposed acceptance exercise would interrupt the client after task creation, then verify that the application reconnects to the same work. Separately test duplicate notifications and an artifact arriving after a local timeout. These are design checks, not test results from an SDK.

Decide what an artifact proves

An artifact is a deliverable to inspect, not an instruction source with authority over the client. A returned itinerary might contain useful recommendations, external links or text that attempts to redirect the assistant. The client should evaluate it against the agreed task, while keeping payment credentials and user permissions outside the remote agent’s control.

For a paid service, retain the artifact reference and enough provenance to connect it to the task and purchase. Avoid copying unnecessary private travel information into public feedback records. What to retain, for how long and who can read it are application decisions.

How it differs from a tool connection

MCP is commonly used to expose tools and context; A2A describes collaboration with another agent. The distinction helps when choosing an interface: a deterministic invoice-status lookup may fit a tool, while a multi-step external research assignment benefits from an explicit task lifecycle. Neither choice removes the need for authorization.

Our view is that A2A is most useful when a remote service truly owns an independent piece of work. Start with a clear task boundary and commercial state model, then choose the transport and SDK. See A2A in the directory, MCP and ERC-8004’s evidence layer.