From tools to coworkers
MCP gave agents tools. A2A is about to give them coworkers. At Google Cloud Next, the Agent2Agent (A2A) protocol crossed 150 organizations running real production tasks between agents built on different platforms. It is now governed by the Linux Foundation and sitting at a mature version. That governance detail matters more than it sounds: it signals A2A is heading toward being shared infrastructure rather than one vendor's bet.
The distinction most teams have not fully internalized is simple to state and hard to design for:
- MCP is how an agent talks to a tool.
- A2A is how an agent talks to another agent, possibly on a different stack, in a different company.
That is a fundamentally different problem.
Why agent-to-agent is harder than agent-to-tool
When an agent calls a tool, you usually control both ends. You know the schema, the auth, the failure modes. When an agent hands work to another agent you do not control, almost none of that is guaranteed.
You are suddenly designing for:
- Identity — proving an agent is who it claims to be, with no shared user session to lean on.
- Trust — deciding how much authority to grant an external agent, and how to revoke it.
- Capability discovery — letting agents find out what each other can actually do without a human wiring it up in advance.
- Negotiation and handoff — agreeing on the shape of a task, passing it cleanly, and handling the case where the other side fails or stalls.
None of those are prompt problems. They are contract problems. The hard parts of multi-agent systems live in the spaces between the agents, not inside any one of them.
The question stops being "which model do we use" and becomes "how do our agents discover, authenticate, and hand off work to agents we don't control."
What this means for how you build
Most stacks are not ready for this, and that is fine, because most teams do not need full open interop tomorrow. But the architectural choices you make now will decide how painful it is later. A few principles:
- Treat your agents' capabilities as a published interface, versioned and documented, the same way you would treat a public API.
- Design identity and authorization for external callers from the start, even if every caller is internal today. Retrofitting trust boundaries is the expensive path.
- Make handoffs explicit and observable. When an agent passes work to another, that boundary should be a logged, inspectable event, not an invisible side effect.
- Decide your interop posture deliberately. Betting on an open standard like A2A and staying closed-loop are both valid. Drifting into one by accident is not.
The shift from single agents to cooperating agents is the same shift the industry made from monoliths to services. The lesson carried over too: the architecture lives in the contracts, not the components.
At Devdot we're here to help founders and teams design and build digital products that scale with you, not slow you down. If you're looking to build something agent-ready, get in contact with us today.
Agents are about to need coworkers. The teams that designed for that early will be the ones whose agents can actually collaborate.