A business connecting two AI agents should define who owns each task, how an uncertain outcome is reconciled and what cancellation can actually stop. A shared protocol makes communication possible. It does not make a purchase order reversible or prevent two agents from completing the same business action.
That distinction matters as agent integration moves beyond one assistant calling internal tools. A product team can now assemble specialised agents owned by different suppliers. The interesting architectural change is the new boundary between systems: the user sees one request, while execution and evidence may live in several places.
Interoperability exposes the unfinished parts of a workflow
The A2A version 0.3.0 specification defines task objects, status retrieval, streaming and cancellation. Its cancellation method is explicitly an attempt; a task may already have finished or reached a stage that cannot be cancelled. This versioned reference is useful for defining an integration contract without assuming every deployed agent supports the same moving specification.
A valid task identifier gives the application a reference to tracked work. Inspect the returned status before treating that work as accepted: a task can already be rejected or failed. It does not prove the task is authorised for every downstream system, nor that its result has been committed to your application. Record those decisions separately.
For a team already familiar with MCP enterprise integration, the new question is less about discovering a tool and more about managing work that continues beyond a single tool response.
Follow an illustrative order exception across two agents
Consider a fictional distributor. Its internal service agent receives a request to investigate a delayed order. A logistics agent operated by a supplier checks dispatch records and proposes an alternative delivery. Neither agent may alter the customer's order without a staff member approving the exact proposed change.
The internal system creates a business request identifier and records the authorised scope. The supplier returns its own task identifier. A durable mapping connects the two, along with the customer account, requesting user, permission snapshot, agreed response format and protocol version. That mapping survives a browser refresh and an application restart.
The supplier later returns a delivery proposal as an artifact. The internal application validates the referenced order and displays the proposal for review. Approval creates a separate, narrowly scoped command in the order system. Separating investigation from commitment prevents a descriptive answer from silently becoming an operational instruction.
A timeout is an unknown result
Suppose the connection breaks after the supplier has started work. Retrying the original request blindly may create a second task. An integration should first reconcile the known task identifier where available, then decide whether a new attempt is necessary.
There is a harder case: the server accepted the request, but the response containing its task identifier never arrived. Resolve this in the commercial and technical contract. The supplier might support an agreed client correlation key, a lookup endpoint or an application-level deduplication record. Do not label a transport request identifier as an idempotency guarantee without testing its semantics.
Keep three different identifiers visible to operators: the business request, the remote task and the individual transport attempt. This lets support staff distinguish one job retried several times from several jobs accidentally created for one customer.
Cancellation has two clocks
The first clock is the user's request to stop. The second is the remote system's acknowledgement that execution has stopped. Displaying “cancelled” when only the first event has happened misleads the user.
The official A2A JavaScript SDK documents cancellation handling inside the agent executor, including checking for cancellation between units of work and publishing a final cancelled state. That supports cooperative stopping; application designers still need to define boundaries around irreversible work.
In our example, a delivery proposal can be abandoned. A change already committed to an external order system may need a compensating action governed by that system's rules. The application should show “stop requested,” “stopped before update” or “update already completed,” according to evidence. These are proposed business states, not additional claims about the protocol.
Design the operator's view before adding another agent
The most useful screen is often a modest task ledger. For each request, show its owner, latest confirmed state, last successful contact, artifacts awaiting review and next permitted action. Avoid a transcript dump that forces an operator to reconstruct the transaction.
An investigation should answer concrete questions:
- ▸Did the supplier acknowledge this request, and under which task identifier?
- ▸Is the displayed proposal complete, partial or replaced by a later artifact?
- ▸Did anyone approve a business change?
- ▸Which downstream system confirmed that change?
- ▸Is a cancellation pending, confirmed or no longer possible?
Retain enough evidence to resolve those questions without storing every sensitive message indefinitely. Restrict operator access by the same customer and business boundaries used in the main application.
When this architecture is worth buying
A cross-agent protocol is useful when independently managed systems must discover capabilities and exchange long-running work through a shared interface. It is less compelling when a small internal workflow already has a reliable API and a single owner. Adding agent coordination there may simply add failure modes.
A sensible first project connects one remote agent, one business action boundary and one human review step. The deliverable should include interrupted connections, duplicate notifications, late artifacts and cancellation after completion. A polished conversation is only one part of that demonstration.
Ask the engineering partner to hand over the task-state mapping, protocol compatibility assumptions and recovery runbook. Our software handover guide explains how to make that operational knowledge transferable.
TuniCyberLabs can help scope AI integration work around a concrete workflow. Describe the agents and systems you need to connect, including which changes must remain under human control.