Connecting work with MCP, A2A, and AG-UI: what has finished?

Once connected, who is waiting for what?

Consider a hypothetical refund workflow: find an invoice, investigate an exception, and present an amount to the user. Splitting it across services can obscure how much has actually finished, even when communication succeeds. Has the investigator delivered a proposal, has the user approved it, or has the refund been issued? The same completion label can leave a person with very different work to do next.

On March 13, AWS announced AG-UI support in AgentCore Runtime, alongside existing MCP and A2A support. Common specifications increasingly connect tools, other agents, and user interfaces. The announcement describes those connections; it does not measure whether a refund workflow became faster.

My judgment is that common protocols derive their value from passing work in progress and results between implementations. Counting supported protocol names tells us less. To realize that value, applications must align what a call, an investigation, and a display each mean by completion, so users understand why they are waiting and what to do next.

MCP aligns tool inputs and outputs

The MCP 2025-11-25 tools specification defines tool discovery, input formats, invocation, and returned results. An invoice search receives search parameters and returns what the service found. Whether its implementation queries a database or uses AI is a separate choice. An AI implementation alone does not establish a reason to use A2A.

An outputSchema describing the result is optional, but a server providing one must return conforming structured results. The specification also distinguishes protocol errors from execution errors reported through isError. A receiver preserving these distinctions can handle an empty search differently from a search service that could not be called.

Still, a numeric amount field does not prove that the right invoice was selected. In this example, the application must check the invoice number, relevant period, currency, and amount before treating the result as grounds for a refund. A returned tool result cannot stand in for completion of the entire business process.

A2A tracks the other party's work as a task

An agent investigating an exception may need more information than an invoice retrieval does. A2A 1.0, released on March 12, was announced as the first stable version for agent communication. It changes interactions from the earlier 0.3 series; the announcement describes advertising both versions for an incremental migration. A stable release does not guarantee compatibility with every counterpart.

The 1.0.0 specification uses an Agent Card to describe abilities and interfaces, and exchanges task states and artifacts. A task can pause for additional input, with identifiers connecting the answer to the relevant task and conversation. Requests, clarification, and results can continue without directly operating the investigator's internal implementation.

Suppose the investigator asks which contract clause applies. The user's answer should return to that investigation. Sending it as an unrelated new request could leave two investigations running. A successful investigation task, meanwhile, indicates success within that task's scope. Receiving a refund proposal as an artifact need not mean money has been transferred.

Nor does an Agent Card advertising invoice investigation prove the quality of that investigation. Information used to select a worker differs from checks used to accept its output. The common format provides a way to contact the counterpart; the business application still has to establish what its result means.

Duration alone does not choose the protocol

MCP introduced experimental Tasks in its 2025-11-25 version, supporting status tracking and deferred results. Both ends must support the relevant capabilities. Servers identifying the same protocol version need not all implement task listing or cancellation. A rule such as “use A2A whenever the work takes a long time” therefore misses overlapping features.

A task-enabled tool may suffice when the caller needs a predefined invoice search result later. A2A becomes a useful comparison when the caller needs to discover a counterpart's abilities, answer questions during its work, and delegate an investigation involving conversation and artifacts. These are selection criteria proposed here, rather than three strictly separate layers mandated by the protocols.

Cancellation deserves particular care. MCP Tasks requires the task to transition to cancelled for a valid cancellation request, and to retain that state even if execution continues. A screen saying “cancelled” therefore does not establish that an external refund has been reversed. Requesting a stop, proving execution stopped, and reversing an already completed operation require separate checks.

AG-UI aligns events reaching the interface

An investigation running and a result ready for judgment are different experiences for the user. AG-UI's event documentation pinned to March 28 defines events for run lifecycle, text fragments, tool calls, and results. A consequential distinction is between TOOL_CALL_END, which ends transmission of the arguments, and TOOL_CALL_RESULT, which delivers the execution result.

In this example, a screen interpreting the former as “refund completed” could lead the user to believe the process was finished. Ending one run also need not complete the entire request. The application must map events to business states: “review the refund proposal” when the investigation arrives, or “select a contract” when more input is required.

Displaying an approval button does not itself authorize execution. The executing application needs to associate the approving person with the invoice, amount, and destination being refunded. Connecting the display, the user's response, and the actual refund result remains application work.

Follow one refund request through four exchanges

These four exchanges form a hypothetical illustration, not a requirement for four agents or all three protocols. Passing information that identifies the same invoice and request could reduce the effort of reconstructing the process from separate service logs. That benefit should be checked against actual outcomes and the time people spend investigating them.

Can the outcome still be checked after disconnection?

Closing the screen or losing the connection does not imply that every intermediate update will be replayed. A2A 1.0 explicitly warns that a reconnecting client may miss status messages and that messages must not serve as a reliable delivery mechanism for critical information. In this example, the application needs a way to retrieve the current task and artifacts using the investigation's identifier, then reconcile them with business records.

AG-UI's state synchronization distinguishes snapshots replacing the full current state from incremental changes applied in order. Its documentation describes requesting a fresh snapshot if interface and agent state diverge. Separately, the application must establish whether that refreshed state correctly includes the external refund outcome.

If only the refund response was lost, assuming failure and issuing a new refund could duplicate the operation. Tell the returning user that the original outcome is being checked. A proposal with a changed invoice or amount also needs more than the old approval. Common communication formats leave the distinction between continuing a request and starting a new operation to the application.

Start with necessary connections and measure the cost of change

Use an existing search API and interface as the baseline if they already retrieve invoices effectively. Compare A2A when an investigation needs another worker, and AG-UI when several execution environments need to report progress to the same interface. AWS's announcement does not specify an A2A version: do not infer 1.0 support, and check versions and optional capabilities at both ends.

A trial should include ordinary investigations, additional input, disconnection, cancellation, and replacing a counterpart. Alongside final correctness, measure waiting time, repeated inputs, and the time people spend rechecking outcomes. Examine what must change in the interface and invoice retrieval when the investigator is replaced. These are proposed checks, not measured improvements demonstrated for a particular product.

If common specifications confine changes to a manageable part of the connection, they can make it easier to update the implementation while preserving the user's workflow. If ambiguous intermediate states still force people to reconstruct what happened, adding connections may leave their burden intact. Protocol selection should consider what an exchange allows the next person to understand and do, as well as what it can transmit.