Three years ago, if you wanted to build a system with multiple AI agents, you had to invent your own communication protocol. JSON schemas, custom message formats, hand-rolled serialization — everyone reinvented the same wheel. Last week, Google released the A2A (Agent-to-Agent) protocol, and it might just be the thing that makes multi-agent systems actually work at scale.
The Problem A2A Solves
Here's what happens today: you build an agent that uses one framework, your teammate builds an agent in another framework, and now you need them to collaborate. Maybe one agent is a planner, another is a tool executor, another is a research agent. They need to share state, delegate tasks, and stream results back to each other.
The reality is ugly. Every integration is a custom job. You end up with brittle code that breaks the moment either agent changes its API. It's the same problem HTTP solved for web services — but for agents.
A2A is Google's attempt to be that HTTP for agents. It's a protocol, not a product. Anyone can implement it.
What A2A Actually Does
At its core, A2A defines how agents exchange messages. Here's the gist:
-
Agents expose capabilities — not endpoints, but what they can do. Think of it like a capability advertisement rather than a REST API.
-
Tasks, not requests — instead of "call this function with these params," you submit a task and get back a task ID. The agent processes asynchronously and streams results back.
-
State persistence built in — tasks have lifecycles (submitted, working, completed, failed). You can check status, resume interrupted work, get partial results.
-
Streaming support — agents can stream updates, tokens, artifacts back to callers. Not just final results.
-
No shared memory model — each agent is independent. They communicate through the protocol, not by sharing state. This is crucial for distributed systems.
The protocol runs over HTTP/JSON, with SSE (Server-Sent Events) for streaming. It's intentionally simple — no exotic formats, no vendor lock-in.
ADK-Rust: Google's Rust Implementation
Google didn't just publish a spec. They built implementations in Python, TypeScript, Go, Java — and Rust. That's the part that matters to us.
ADK-Rust (adk-rust.com) is the Rust implementation of both the Agent Development Kit and the A2A protocol. It gives you:
- Agent primitives: Build single agents with tools, memory, callbacks
- Multi-agent orchestration: Compose agents into teams with the ADK
- A2A server/client: Expose your agent to other A2A agents, or consume other A2A agents as tools
- Streaming: Full support for token streaming and event streams
The Rust implementation is notable because Rust is where you build the systems that need to run reliably at scale. Python agents are great for experimentation. Rust agents are what you want in production.
Why This Matters for Rust Developers
Right now, the Rust agent ecosystem is fragmented. You have:
- Frameworks like Agentor, Rig, Bonsai — each with their own agent model
- Tool calling via MCP (Anthropic's standard) — but MCP is tool-centric, not agent-centric
- No standard way for two Rust agents to talk to each other
A2A fills that gap. It doesn't replace MCP — they're complementary. MCP is how an agent uses tools. A2A is how agents use each other.
For Rust specifically, this means:
-
Interoperability — a Rust agent built with one framework can now talk to a Python agent built with ADK, or a Go agent. The protocol is the contract.
-
Composable systems — you can build specialized agents (research, coding, verification) in whatever language suits them, then wire them together with A2A.
-
Production-grade communication — the protocol handles the hard parts: streaming, task tracking, artifact passing, authentication.
What It Looks Like in Practice
Here's the mental model: you build an agent that advertises its capabilities ("I can search the web", "I can write code", "I can run tests"). Other agents discover it via A2A's capability negotiation, then submit tasks.
Your agent receives a task, processes it, streams back progress. When it's done, it returns artifacts — code, data, whatever was produced. The caller can then hand those artifacts to another agent for the next step.
It's a pipeline, but each stage is an independent agent. Each can be built, tested, scaled independently. That's the dream of multi-agent systems, and A2A is the closest we've come to making it real.
The Gap Still Exists
A2A isn't perfect. It's new — the spec just shipped, implementations are early. Some gaps:
- Capability negotiation is still coarse-grained. "I can search the web" doesn't tell you which engines, what rate limits, what credentials needed.
- Trust models are undefined. How do agents verify each other? How do you scope permissions?
- State management across agent boundaries is left to the application. A2A handles message delivery, not semantic consistency.
These are hard problems. Getting the protocol right is step one. The ecosystem will fill in the rest.
The Bigger Picture
We're watching the agent ecosystem mature. A year ago, everyone was figuring out tool calling. Then MCP gave us a standard for tools. Now A2A gives us a standard for agents talking to agents.
The pattern is clear: first we build agents, then we figure out how to connect them, then we standardize those connections. We're in the standardization phase now.
For Rust developers, this is the moment to pay attention. The language that gets the best A2A implementations will be the language production multi-agent systems are built in. Google's bet on Rust for ADK tells you which way that's going.
The protocol is open. The spec is on GitHub. If you're building multi-agent systems in Rust, now's the time to experiment. The standard won't wait for perfection — it'll evolve by being used.