A2A is a contract, and most agents break it
I registered two of my own agents in Gemini Enterprise over the A2A protocol. Registration failed on validation because the agent's responses were off-spec. What broke, how a small proxy fixed it, and what it means for agent interoperability in the enterprise.
Most enterprises will not run one agent platform. They will run several: one from their productivity suite, one from their cloud provider, a few from software vendors, and some they build. For those agents to work together, they need a shared protocol. Today that protocol is A2A, Agent2Agent, which Google introduced in 2025 and later handed to the Linux Foundation.
I wanted to see how far that promise holds in practice. So I took agents I run on my own agent stack, gave them names (Carlos and Elena) and registered them in Google’s Gemini Enterprise as A2A agents.
What happened
Registration failed. Not with a network error, but with validation errors: Gemini Enterprise checks the agent’s responses against the A2A schema using strict Pydantic models, and my agents’ responses did not match.
| Symptom | Cause | Where it was caught |
|---|---|---|
| Validation errors on registration | Response shape did not match the A2A schema | The client’s Pydantic models |
| Fields rejected | Field names differed from the specification | Same |
| Agent worked fine in its own client | The agent’s own client was lenient about the shape | Nowhere, until a strict client arrived |
The last row is the real lesson. The agent was not broken. It worked every day in its own tools. It was only non-compliant, and nobody knew until a strict client showed up.
The fix
I did not fork the agent framework. I put a small normalising proxy in front of it, deployed on Cloud Run, and published it as hermes-adapter. It forwards requests unchanged and rewrites responses into the shape the specification requires.
Figure 1. The proxy sits between a strict A2A client and a useful but off-spec agent. Requests pass through; responses are normalised.
With the proxy in front, the agents get through Gemini Enterprise’s validation without any change to the agent itself. I have also tried the same agents against Microsoft Copilot Studio’s A2A support, which is the next test of whether “write once, register anywhere” holds.
| Before | After | |
|---|---|---|
| Registration in Gemini Enterprise | Failed on validation | Passes the schema checks |
| Changes to the agent framework | n/a | None |
| Extra moving parts | None | One stateless proxy |
| Upgrade path | n/a | Remove the proxy when the framework becomes compliant |
What this means for enterprise buyers
A protocol is a contract, and contracts need enforcement. Three things I would put in any agent procurement or internal standard today:
Ask for conformance evidence, not a logo. “Supports A2A” should mean the vendor runs the agent against a strict client in their own test pipeline. Ask to see it.
Test against the strictest client you have. Lenient clients hide problems. Strict ones, like the validation layer I hit, surface them on day one instead of in production.
Keep adapters thin and temporary. A normalising proxy is a fine bridge. It should be stateless, owned by someone, and have a removal date. Otherwise it becomes the place where every interoperability problem quietly goes to live.
Agent interoperability is going to be one of the defining architecture problems of the next few years. The protocols are good. The implementations are early. Plan for that gap.