Agent-to-Agent Communication and A2A

Every multi-agent system in this module so far has lived in one codebase. Your orchestrator called workers as functions, your subagents shared your tools file, and your pipeline passed handoffs through your own folders. Now picture the agent you need belonging to someone else: the finance team's reconciliation agent, a vendor's travel-booking agent, or a partner's research agent built on a framework you've never used. You can't import it. You may not even be allowed to see how it works.

That's the problem A2A (the Agent2Agent protocol) solves. It's an open standard for agents to discover each other, hand off tasks, and return results across team and company boundaries. In this lesson you'll learn its core ideas (agent cards, tasks, messages, and artifacts), how it fits alongside MCP, and you'll wrap your own agent in a minimal A2A server and call it from a client.

The problem: agents that can't share a codebase#

Inside one program, connecting agents is easy: you call a function. Across organizations, you need answers to questions a function call never asks:

• Discovery. What agents exist, what can each one do, and where do I send requests?
• A task contract. How do I describe the work, and in what shape does the result come back?
• Long-running work. A research task might take ten minutes. How do I check progress without holding a connection open?
• Back-and-forth. What if the other agent needs a clarification or an approval before it can continue?
• Trust. How do I authenticate, and how does the other side decide what I'm allowed to ask for?

A2A standardizes the answers, so any compliant client can work with any compliant agent, whatever language, framework, or model each one uses.

A key design idea is that agents stay opaque. The caller never sees the remote agent's prompts, tools, memory, or reasoning, only what it chooses to publish and return. That lets a company expose an agent without exposing its internals.