A2A handover: what must travel with an agent request

Handing over a request

Connected specialists can still leave users unsure where the job went

“I would like three days off next month.” An internal assistant checks the balance and prepares the request. The employee still needs to distinguish a draft, a request sent to a manager, and approved leave. This is a hypothetical design combining several systems. More participants can return answers, yet if those distinctions disappear, the employee must reopen the HR system to find out what happened.

Google’s April 9 announcement of Agent2Agent (A2A) proposes a way to delegate work to agents on different platforms. Its Vertex AI announcement on the same day presents a development framework and a managed execution environment. Together with Semantic Kernel Agents becoming generally available and AWS’s implementation of human confirmation, these releases make combinations of development, connectivity, deployment, and review more concrete.

My conclusion is that making components easier to combine becomes useful handover only when the meaning of the request and its completion conditions travel with it. Calling a participant, following its response, and confirming a change each help. Deciding who revalidates the work when the user changes their intent connects those capabilities to a useful service.

Delegating work

A2A covers the progress of a request as well as how to call another agent

The A2A announcement describes client and remote agents exchanging capabilities, tasks, messages, and artifacts. An Agent Card advertises what a participant can do. A task may finish quickly or continue over a longer period, including human participation, while its status is communicated. Results return as artifacts. This expands the design question from receiving a single API response to entrusting work to another participant and following its progress.

Google illustrates the proposal with candidate sourcing. An agent takes a user’s requirements, asks specialists to find candidates, presents suggestions, and can then proceed to interview scheduling. This is an illustrated use case, not a measured reduction in recruitment time. The useful distinction is that a list of candidates and a request to arrange interviews are different jobs performed by different participants.

Applied to the leave-request scenario, a completed balance lookup does not mean the application is complete. The calling application must connect the remote participant’s definition of completion to what it displays. A format for transporting progress still leaves the work of aligning the meanings of a draft request and an approved record.

The announcement releases a draft specification and says a production-ready version is planned later in the year. The breadth of partner participation shows interest in common connectivity; it does not demonstrate dependable handover between every product. Adoption requires checking the particular implementation and the receiving system’s support.

Tools and participants

MCP data connections can work alongside A2A delegation

A connection to a tool differs from asking another participant to carry out a job. Anthropic’s Model Context Protocol (MCP) announcement describes servers exposing data and business tools to connected AI applications. The A2A announcement positions its protocol as complementary to MCP and describes collaboration without requiring participants to share the same tools or memory.

In the leave-request scenario, the assistant could call a balance-reading tool or ask an HR agent to prepare an application. That HR agent could itself use an MCP tool internally. The name of the connection method does not determine which component checks the number of days or stores the record.

The caller supplies information the participant needs and checks returned results against its own business conditions. It also defines access scope and what may cross an organizational boundary. The point is to distinguish implementation that a common connection format can remove from implementation still needed to align business meaning.

Development and deployment

An open framework does not determine a single execution destination

Google’s Vertex AI announcement makes that distinction concrete. Agent Development Kit (ADK) is an open-source framework for building agents. Released in Python, it describes local debugging and deployment choices including Cloud Run, Kubernetes, and Vertex AI. Agent Engine is presented as a service that manages deployment and execution infrastructure.

This combination separates code defining behavior from management of the environment running it. Portable code, however, does not make destination authentication, stored conversations, and monitoring configuration equally portable. Google describes reducing the burden of moving from development to deployment; the announcement alone does not establish a team’s migration effort. Comparing execution destinations requires checking which parts of the request and result survive the move.

The April 4 Semantic Kernel Agents announcement also needs to be read with framework and execution destination separated. The core Agent API becomes generally available in .NET 1.45 and Python 1.27, with Microsoft explaining its confidence in API quality and ongoing maintenance. The post includes connections to other platforms, but an SDK is not itself a managed execution service. General availability should not be extended automatically to the quality of every new collaboration feature or destination shown.

Both announcements offer ways to combine development frameworks with managed services. API stability, where behavior is defined, and what is managed after deployment are separate comparisons. The relevant choice is how independently a team can change the parts it needs to change.

Changes during human review

Execution after confirmation still needs a place to repeat validation

AWS’s implementation of human confirmation makes this issue concrete through a leave-request example. Reading balances and listing previous requests proceed automatically in that example. Creating, updating, and canceling requests modify the database and therefore require confirmation before execution. The interface presents the function and its parameters.

Simple user confirmation asks whether to approve or reject the proposed operation. Return of control instead passes operation information back to the application, which takes responsibility for executing it. In AWS’s example, an employee notices that the selected start date is a Sunday and edits the date in a form. Review can therefore include correcting an error, rather than only confirming the interpreted intent.

Editable input also makes earlier validation insufficient. The same post describes an employee with five days remaining changing a three-day request to 100 days. Final validation and enforcement take place at the API. An agent checking the original input does not establish that the edited request remains valid.

Return of control adds application work: an editing interface and execution handling must be implemented. Detailed editing is not always necessary; a clear operation may need only approval or rejection. Choosing how a person participates requires deciding where to pause and who validates the resulting input afterward.

A hypothetical multi-system design

Carry user confirmation, managerial approval, and stored results separately

Starting from AWS’s example, consider a design where managerial approval belongs to another system. This extension is my hypothetical design, not a reported implementation. An internal assistant reads the balance and asks an HR participant to prepare a draft. If the employee changes the dates, the final input is validated, the request is stored, and the interface shows that managerial approval is pending.

User confirmation does not mean the manager has approved the leave. A delayed managerial response does not necessarily mean delegation failed. Keeping a request identifier, its current stage, and the next required decision lets the employee wait without submitting another application. After approval arrives, the stored result is checked before reporting approved leave.

This design distinguishes connection failure, user rejection, pending approval, and failed persistence. Re-executing work that is merely waiting could create a duplicate request in another system. A2A’s progress communication and a confirmation mechanism that permits edits are components for expressing these distinctions. Duplicate prevention and business rules still need implementation and verification in the application.

When combinations help

Common connectivity matters when the necessary participant works elsewhere

Multiple agents are not needed for every job. If an application only calls a fixed HR API, a direct connection may reduce the number of points to check. Anthropic’s Building effective agents likewise recommends starting with the simplest structure that fits the problem and adding complexity when needed.

Common connectivity becomes more valuable when participants run on different platforms, responses take time, and artifacts or human input must move between them during execution. Even then, verification should follow one request from acceptance to the stored result. Add edited input, waiting for a remote response, and a broken connection to normal cases, then check where work can resume.

April’s announcements provide a path for combining different development and execution choices. Their value reaches people who need to know how far a request has progressed. Freedom to choose connection formats and execution environments becomes useful when the design preserves intent and results throughout the handover.