Agent-to-agent communication

Agent-to-agent communication is the exchange of requests, observations or work products between agent systems. It needs an interface that the participants interpret consistently. A2A version 0.3.0 provides one such contract: an Agent Card advertises identity, capabilities, skills and connection information; messages, tasks and artifacts represent interaction and outputs. The card describes a service’s claims and interface, rather than certifying that it can perform every advertised task correctly. 1

Separate a message from completed work

In an original reference-library example, one agent asks another to compare two specification revisions. A message can acknowledge receipt before the comparison is finished. A later artifact might contain the proposed differences and evidence references. A useful interface would preserve which event means “received,” which means “needs input” and which means “finished.” Treating every response as final would collapse those distinct states.

The pinned A2A specification describes task states including working, input-required and terminal outcomes, and distinguishes messages from artifacts. Those types help participants represent progress under that contract. They do not establish the factual correctness of an artifact or grant access to a protected source. Both sides still need compatible versions, supported interaction modes and an authorization arrangement. 1

Correlation is not a delivery guarantee

JSON-RPC 2.0 defines request and response objects with matching identifiers, while a notification omits an identifier and receives no response. It is transport agnostic. Those rules help match a reply to a call; they do not establish that a business task completed, nor do they supply exactly-once execution for an external effect. 2

A2A supports multiple protocol bindings, so one should inspect the selected binding rather than assume all exchanges use JSON-RPC. 1

Suppose the comparison service becomes unreachable after receiving a request. The caller could know that it sent bytes while remaining uncertain whether work began. Retrying requires an agreed identity for the work and a policy for duplicate handling. Durable execution examines that broader problem. A network acknowledgment and a completed comparison are different evidence even if they arrive on the same connection.

Interfaces have different scopes

The cited MCP architecture defines host, client and server components for connecting an AI application with capabilities and context. It offers a different interface example from A2A’s task exchange. An application can combine protocols or wrap one behind another, so their names alone do not establish a universal boundary between “tools” and “agents.” Inspect actual messages, version support and responsibilities. 3

Orchestration concerns how the overall work is coordinated. Communication concerns what crosses a particular interface. A coordinator could exchange messages with several services without sharing its complete internal state. Conversely, a multi-component system might coordinate everything within one process and have no external agent protocol at all. This entry focuses on the exchange boundary rather than prescribing a multi-agent topology.

Evaluate the whole exchange

For the original example, useful tests would include an unsupported skill, a request needing clarification, duplicate submission and a validly formatted artifact with an unsupported claim. The receiving agent should distinguish these cases instead of treating every problem as a transport failure. Structured outputs covers form; evaluation covers outcomes and evidence.

A participant’s message also remains untrusted input with respect to the receiver’s authority. An instruction to fetch a private document should pass the applicable identity and delegation and permission checks. Communication is useful when it makes task state and responsibility explicit. It cannot supply missing authority, consistent semantics or reliable results merely by adding another agent.