#A2A
Google's Agent-to-Agent (A2A) protocol enables autonomous agents to discover, authenticate, and collaborate with each other across organizational boundaries. These articles explore A2A implementation patterns, broker-based coordination, and how A2A complements MCP for inter-agent communication in production multi-agent systems. Topics include agent card discovery, task lifecycle management, and secure cross-platform agent orchestration. Each post includes working Go code examples demonstrating real-world A2A integration scenarios.
14 posts tagged with a2a. ← All posts
The most common question about the two big agent protocols is which one to use — and the answer is almost always "both," because they solve different problems: MCP connects an agent to its tools, A2A connects an agent to other agents.
The most common question about the two big agent protocols is which to use — and the answer is almost always both, because MCP connects an agent to its tools and A2A connects an agent to other agents.
The two protocols people keep pitting against each other are actually two halves of the same architecture — MCP gives an agent its tools, A2A gives it collaborators, and real systems need both.
MCP gives an agent its tools, A2A gives it collaborators, and real systems need both. How the two protocols compose — tools within an agent, agents between — in one architecture.
When agents from different organizations delegate real work to each other, trust cannot be assumed, so A2A builds authentication into the Agent Card and demands it on every request.
When agents from different organizations delegate real work, trust cannot be assumed, so A2A builds authentication into the Agent Card and demands it on every request.
Long-running agent work needs a way to report progress without the client holding its breath, and A2A offers two: stream the updates live, or register a webhook and get called back.
Long-running agent work needs a way to report progress without the client holding its breath. A2A offers two: stream the updates live over SSE, or register a webhook and get called back.
A2A defines what agents exchange independently of how it travels, so the same operations work over JSON-RPC, gRPC, or plain REST — and the operation set is small enough to hold in your head.
A2A defines what agents exchange independently of how it travels, so the same operations work over JSON-RPC, gRPC, or plain REST — and the operation set is small enough to hold in your head.
Agents need to exchange more than plain strings — instructions, files, images, structured data, and finished deliverables — and A2A's content model handles all of it with three composable objects.
Agents exchange more than plain strings — instructions, files, images, structured data, and finished deliverables. A2A's content model handles all of it with three composable objects.
Delegating real work between agents is rarely a quick round trip, so A2A makes the task a first-class object with an explicit lifecycle that survives long-running, interruptible, asynchronous collaboration.
Delegated work is rarely a quick round trip, so A2A makes the task a first-class object with an explicit lifecycle that survives long-running, interruptible, asynchronous collaboration.
Before one agent can delegate to another it has to find it and understand what it can do, and in A2A that self-description is a single structured document called the Agent Card.
Before one agent can delegate to another it must find it and understand it. In A2A that self-description is a single structured document — the Agent Card.
Tools are one half of an agent's world and other agents are the other half, and A2A is the open standard that lets agents built by different teams, in different frameworks, discover and delegate to each other as peers.
A2A is the open standard that lets agents built by different teams, in different frameworks, discover and delegate to each other as peers — the agent-to-agent complement to MCP's agent-to-tools.
This lesson hosts one specialized Foundry agent over the A2A protocol, publishing an agent card the client can discover.
Host one Foundry agent over A2A: newMux pins the card interface URL, wraps the agent in an a2aprovider executor, and serves the card plus JSON-RPC routes.
This lesson builds a Foundry host agent that discovers remote A2A agents by their cards and calls each one as a tool.
A Foundry host agent resolves remote A2A agent cards and turns each remote agent into a callable tool with agenttool.New over the a2aprovider.
The reference architecture distinguishes request-based and message-driven agent communication. For in-process orchestration, the workflow IS the broker — and A2A is just the wire format.
Running agents on Cloud Run, exposing via A2A, and wiring into production systems.
Deploy Microsoft Agent Framework multi-agent systems on Cloud Run with A2A agent-to-agent communication, autoscaling, load balancing, and production observability dashboards.
Google's A2A spec standardises how agents talk to other agents (not just tools). The Go client is small; the conceptual shift is what matters.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.