Agent-to-Agent Protocols

Interoperability means systems built separately can work together. Inside one codebase, agents call each other as functions (modules 16 to 18). That stops working when agents:

• are built by different teams or companies;
• run on different frameworks and languages;
• must stay opaque: the other side should not see their prompts, tools or memory;
• do long-running work that outlives a single request.

An agent communication protocol is an agreed way for such agents to describe themselves, accept work and report results.

Without a standard, every pair of agents needs a custom integration, the same M times N problem MCP solved for tools.

• A travel agent that wants to use an airline's booking agent should not need the airline's source code.
• A standard lets each side change its internals freely as long as the contract holds.
• It also puts security in a known place: the boundary.

The two are often confused. They connect different things:

• MCP connects an agent to tools and data. The other end is a passive capability: it does what it is called to do and returns.
• An agent-to-agent protocol connects an agent to another agent. The other end is autonomous: it has its own model, plans its own steps, may take a long time, and may ask questions back.

They are complementary and usually used together.

• An agent uses MCP to reach its own tools, and an agent-to-agent protocol to hand a whole sub-goal to a peer.
• The test: are you asking for a function to be run (a tool) or for a goal to be achieved (an agent)?
• A tool call returns in one response. A delegated task has a lifecycle: accepted, working, needs input, done.

Before delegating, an agent must find a suitable peer and learn what it can do:

• Agent discovery is finding that an agent exists and where it is. Usually through a registry (a directory of agents) or a well-known address on a website.
• Capability discovery is learning what it can do, in what formats, and how to authenticate. In A2A this is the agent card.

An agent card is a JSON document an agent publishes about itself: its name and description, its skills (what it can do, with examples), the service address, supported features such as streaming, and the security schemes it requires. By convention it is served at /.well-known/agent-card.json on the agent's domain.

The card is what lets one agent choose another at run time.

• The delegating agent's model reads skill descriptions exactly as it reads tool descriptions, and picks.
• The same writing rules apply: say what the skill does, when to use it, and what it returns.
• The card is also an attack surface: it is text from another party that a model will read. A card can be signed so its origin can be verified.

A2A models the work with four objects:

• A message is one turn of communication, from the client agent ('user' role) or the remote agent, made of parts.
• A part is one piece of content: text, a file, or structured data.
• A task is a unit of work the remote agent has accepted. It has an id, a status and a history, and it persists while the work runs.
• An artifact is an output the task produces: a report, a file, a result object. Also made of parts.

Separating conversation from work is what makes long tasks manageable.

• Messages are how the two agents talk. The task is the thing being tracked.
• A quick request can be answered with a message alone, with no task created.
• A long one returns a task at once; the caller checks on it, or is told when it changes.
• Artifacts keep results distinct from chatter, so the caller knows what the deliverable is.

A task moves through defined states. In A2A 1.0:

• submitted: received, not yet started;
• working: in progress;
• input required: paused; the remote agent needs something from the caller;
• auth required: paused; further authorisation is needed;
• completed, failed, canceled, rejected: finished, one way or another. These are final.

Named states are what let two independent systems agree on where things stand.

• 'Input required' is the protocol's form of human-in-the-loop: the task waits, across the boundary, until an answer arrives.
• 'Rejected' lets an agent decline work it should not do, which is different from failing at it.
• Final states tell the caller it can stop waiting and decide what to do next.
• This is the state machine of module 6, standardised between organisations.

Delegating to an agent you do not control has five steps:

• Discover: fetch the agent card from a trusted source.
• Select: match the sub-goal to one of its skills.
• Authenticate: obtain credentials using the scheme the card declares.
• Send: pass the task as a message, with only the context the peer needs.
• Follow: stream updates, receive notifications or poll; answer questions; collect artifacts; handle every final state.

Everything from module 16 about briefing still applies, with less trust.

• The peer cannot see your context, so the message must be self-contained.
• You should send the minimum: this is another organisation, and what you send may be stored.
• What comes back is untrusted input. An artifact from another agent can contain instructions aimed at yours.
• Authority should not travel by default: the peer acts with the rights you grant it for this task, not with your user's full rights.

They fit when the boundary between agents is real:

• Across companies: a travel agent working with airline, hotel and payment agents.
• Across departments: an onboarding agent coordinating HR, IT and facilities agents, each owned by its team.
• Across frameworks: agents built on different stacks that must cooperate.
• Agent marketplaces: choosing a specialist agent at run time by its advertised skills.
• Opaque specialists: an agent whose prompts, tools or data its owner will not expose.

The gain is organisational more than technical.

• Each team ships and changes its agent on its own schedule.
• Specialist knowledge stays with the team that has it.
• New capabilities are added by registering an agent, not by redeploying a central system.
• The costs are real too: each hop adds latency, a failure point and a trust question, and end-to-end debugging needs tracing that crosses organisations.

An agent that accepts tasks from other agents is a public interface. It needs:

• Authentication: who is calling? The card declares schemes such as OAuth 2 or mutual TLS.
• Authorisation: what may this caller ask for, on whose behalf?
• Scoped delegation: the peer receives only the rights needed for this task, for a limited time.
• Input and output checks: messages and artifacts from peers are untrusted and may carry injection.
• Limits: rate limits, cost limits and a maximum delegation depth, so agents cannot call each other in a loop.
• Audit: a record of which agent asked which agent to do what, tied to a task id.

Chains of agents spread both capability and risk.

• If agent A can ask B, and B can ask C, then A can reach whatever C can do, unless each hop limits it.
• A compromised or confused agent in the chain can pass poisoned content onwards.
• Responsibility must be traceable: when a wrong refund is issued three hops away, someone has to be able to say who asked for it.
• The specifications are young and still moving; pin versions and keep the protocol behind a thin layer of your own code.

The questions interviewers ask about agent-to-agent communication, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.