A2A and Agent Communication

What it is

The protocol layer by which one agent asks another — built by a different team, deployed on a different schedule, frequently owned by a different organisation — to take on a piece of work, and by which the two track that work to a conclusion. It covers how a party advertises what it can take on, how a request becomes a tracked unit with a lifecycle rather than a single response, how intermediate output and clarifying questions travel, and how either side cancels.

Why it matters

Work that crosses an ownership boundary cannot assume anything the inside of a system assumes. The peer's prompt, model, and behaviour change without notice; its output is a claim rather than a computed result; it may take minutes or days; it may come back asking a question instead of answering. A protocol that models all of this explicitly is what makes delegation across organisations possible at all — and its absence is why most cross-boundary agent integrations degrade into brittle request-response wrappers that break the first time a peer needs to think for longer than a timeout.

Separate ownership is the whole difficulty

Coordinating agents inside one deployment is an architecture problem: you control the lifecycle, you can read the state, you can change both sides together. Once the peer is run by someone else, every one of those disappears, and what remains is a wire contract plus a trust decision. That is why the mechanics here are about advertisement, task identity, status transitions, and cancellation rather than about who decides what — and why the peer's output has to be treated as an assertion from an external party, not as the return value of a call you made.

Key decisions

• The interaction shape. A request held open until completion is simple and breaks for anything long-running; submitting a task and tracking its status accommodates work of any duration and requires both sides to manage identity and state.
• What a peer advertises and how fresh it is: a machine-readable description of what it accepts and produces, fetched when, cached for how long, and validated against what it actually does.
• The unit of exchange. A conversational message is flexible and unverifiable; a task carrying typed outputs can be checked, stored, and attributed.
• Whether a peer may ask the requester a question mid-task, and whether the requester's side has anywhere to route it when no human is present.
• Cancellation and termination: whether a requester can withdraw, whether a peer must honour it, and what the requester may assume about effects already produced.
• How much the requester verifies. Treating a peer's output as authoritative is fast and transitive — their mistakes become your answers; verifying costs a step and bounds the damage.
• Identity, attribution, and cost: who the peer believes it is acting for, and which side pays for the work performed.

Failure modes

• A peer is integrated as though it were a deterministic service, so its first clarifying question is parsed as a malformed response and the integration fails.
• No cancellation exists, the requester abandons a task after a deadline, and the peer continues working and billing against a request nobody will read.
• Two peers delegate to each other through a cycle neither can see, and the loop is only found when someone looks at the bill.
• A peer's free-text output is spliced into the requester's prompt without a boundary, so the peer — or whoever influenced it — can direct the requester's subsequent actions.
• The advertised description says the peer handles a category of work it quietly stopped handling, and failures present as poor answers rather than as errors.
• Task identifiers are generated per attempt, so a retried submission creates a duplicate unit of work rather than rejoining the existing one.
• Status is polled on a fixed interval chosen for a fast peer, and a slow one is polled tens of thousands of times for one result.
• Partial output is returned and treated as final because nothing in the exchange distinguishes an interim artefact from a completed one.
• Neither side records which party's work produced a given conclusion, so a wrong answer cannot be attributed to the peer that produced it.

Related capabilities

• Webhook and Event Connectors — the event plumbing a long task's completion often rides on
• MCP Client — the consuming pattern for capabilities exposed as a tool surface instead
• MCP Authentication — identity across a boundary where neither side administers the other
• Tool Timeout and Retry — deadlines and repeat safety for work delegated outward
• Tool Result Normalization — treating a peer's reply as content rather than direction

Applies: Production readiness · Design questions