Skip to content
Forward Deployed
Forward Deployed
Lessons and contents
A2A: Agent-to-Agent ProtocolLesson 1 of 6
6 lessons
Learn

A2A: Agent-to-Agent Protocol: overview

Source
From the RAG & Agents Engineering course
By
Sourav Banerjee
Last updated
8 Nov 2026

Report an issue

Larkspur delegates a handbook question to another agent whose tools and framework are private to it. You will discover that agent through its card, read Message and Task replies and extract the answer before passing it to a second hop. The tutorials separate A2A delegation from MCP tool access.

The running example is Larkspur Cloud, the fictional cloud host whose handbook runs through T5.1 to T5.3. Its handbook agent, the agentic RAG graph from T9.1 to T9.4, becomes a service: it publishes an Agent Card and answers over A2A, and the support desk agent, built in another framework, calls it. The lab asks every agent the T5.1 golden question Can I export my data after I cancel my plan? All protocol details on these pages come from the installed a2a-sdk 0.3.26 (the protocols uv group) or from the notebooks.

In short

  • An Agent Card is a JSON document at /.well-known/agent-card.json: name, URL, version, capabilities such as streaming, and skills. The client reads it before sending anything. In 0.3.26 the notebooks' path /.well-known/agent.json still answers, with a deprecation warning in the server log.
  • Work travels as JSON-RPC 2.0 over HTTP: message/send, message/stream, tasks/get, tasks/cancel. The reply is either a Message (a one-shot answer) or a Task with a state such as working or completed.
  • On the server, the only code you write is an AgentExecutor. The LangGraph graph, a plain LLM call or a Google ADK agent behind it is invisible to the caller.
  • A Task keeps its answer in status.message. In the lab, a client that reads result.parts the way notebook 3 of T12.4's connector does forwards 1,492 characters of Python repr to the next agent instead of the 185-character answer.
  • MCP and A2A sit at different layers: the capstone's host agent loads its tools over MCP (stdio) and delegates documents to the RAG agent over A2A (HTTP).

Mental model

One A2A exchange, from discovery to reply The support desk agent fetches the handbook agent’s Agent Card, then sends message/send. The A2A server calls the AgentExecutor, which publishes a Task in submitted and then working, runs the handbook graph, and publishes completed. The server returns the Task with the answer in status.message. Support desk agent A2A server AgentExecutor Handbook graph GET agent-card.json Agent Card message/send execute() Task: submitted, working invoke(question) answer status-update: completed Task, answer in status.message
  1. The caller knows one base URL. It fetches the Agent Card and reads the skills and the streaming flag.
  2. It posts message/send with the question. The server hands the request to the AgentExecutor.
  3. The executor publishes a Task in submitted, then a working update, before any model runs.
  4. The executor invokes the handbook graph. The server never sees which framework built it.
  5. The executor publishes completed, with the answer as the status message.
  6. The caller gets the Task back, with the answer in status.message.

The caller sees two things: a card and a stream of task events. Everything to the right of the A2A server, the executor and the graph, can be rewritten in another framework without the caller changing a line, as long as the card and the task events stay the same.

Interactive lab

What comes back over A2A: open the file in a browser. Pick Handbook agent (41.2) and message/send, then switch the reader from result.parts to status.message and watch the forwarded text drop from 1,492 characters to 185. Then pick Echo agent (41.1) and tasks/get: the reply had a task id, and the server still answers -32001 Task not found. Last, pick Handbook agent, index missing and compare message/send, which returns only an error, with message/stream, which shows the task fail.

How it connects

  • Before: T7.2 builds the ReAct agents that notebooks 41.2 and 41.3 put behind A2A. T9.4 turns retrieval into an agent's tool; here the whole agent becomes a service. T11.1 teaches supervisors and handoffs inside one process; A2A is how a supervisor reaches a worker that runs in another process, team or framework. T12.3 serves retrieval as an MCP tool, the other way to share a RAG system.
  • Next: T13.1 to T13.3 return to retrieval itself: hierarchical indexes, memory-augmented retrieval and knowledge graphs. Any of them can sit behind the same A2A executor.

Key Takeaways

  • Publish an Agent Card and let clients discover it; hard-code a base URL, never a list of skills.
  • Read replies by kind: a Message has parts, a Task has status.message and artifacts. Never forward str() of a protocol object.
  • Keep the A2A code in one AgentExecutor and keep the agent behind it framework-specific. That boundary is what lets you swap LangGraph for anything else.
  • Use MCP for tools and data, A2A for agents. A system needs both once one agent's answer depends on another team's agent.

Rate your confidence and keep notes on the module page.