Track 04 · Multi-agent & integrationLesson 04 of 11
Agents talking to other vendors' agents
A2A interoperability, and what to agree before agents trust each other.
- Lesson library · reference
- 45 min read
- 60 min hands-on
- Halden Freight
- Pro
What you'll be able to do
01- Explain the problem A2A solves and its core model as of the v1.0 specification: Agent Card, task, message, part, artifact, context, and the task lifecycle states.
- Write a valid v1.0 Agent Card for an enterprise agent, including skills, supported interfaces and security schemes, and publish it at the well-known path.
- Choose an interaction mode (blocking, non-blocking with polling, streaming over SSE, push notifications) for a long-running cross-organisation task, and handle interrupted states.
- Distinguish A2A from MCP and decide which one a capability should be exposed through.
- Design authentication, authorisation, tenancy and trust for an agent that another organisation's agent will call, and defend it to a CISO.
- Map A2A onto the platforms you will meet: Google ADK, Lyzr and the A2A SDKs.
Before you start
- Supervisor, router or swarm?: A2A is message passing across a trust boundary.
- MCP: connecting agents to the customer's systems: the agent-to-tool protocol you will compare against.
- Tools with scoped, auditable access: scopes and identity at the tool boundary.
- Workflows that survive restarts: A2A tasks can run for minutes or days.
- Working knowledge of HTTP, JSON-RPC 2.0 and the OAuth 2.0 client credentials flow.
The short version
A2A (Agent2Agent) is an open protocol for agents built by different teams, vendors and organisations to discover each other, delegate work and exchange results without sharing their internal prompts, memory or tools. An agent publishes an Agent Card, a JSON document at https://{domain}/.well-known/agent-card.json describing its skills, endpoints, supported protocol bindings and required authentication. A client agent sends a message made of parts (text, files, structured data). The server either replies with a message or creates a task with its own ID and lifecycle (submitted, working, input-required, auth-required, completed, failed, canceled, rejected), and delivers outputs as artifacts. Clients follow long tasks by polling, streaming over Server-Sent Events, or registering a webhook for push notifications. The v1.0 specification (March 2026) defines the data model once and binds it to JSON-RPC, gRPC and HTTP+JSON/REST. A2A is complementary to MCP: MCP connects an agent to its tools; A2A connects agents to other agents. The protocol standardises the conversation; trust, authorisation and data sharing across organisations remain your design.
Key takeaways:
- Expose a capability over A2A when the capability is itself agentic, long-running, multi-turn or owned by another organisation; over MCP when it is a tool call.
- The Agent Card is self-asserted metadata. Trust comes from authentication, signed cards, allow-lists and contracts, not from the card's contents.
- Authorise every operation server-side and scope every task to the caller; A2A requires it.
- Design for long-running tasks from day one: non-blocking sends, push notifications with verified credentials, idempotent handling of duplicate events.
- Expect mixed versions in the field (0.3 and 1.0) and version-negotiate explicitly.
Pro lesson
The rest of this lesson is in Pro.
The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.
- Every stage and specialisation, in full
- Every lab and every role project
- Halden weeks 2–10, on your record
- Every drill, live in the playground
- All solutions, plus the server judge
- Lab Assistant and every Teach with AI