We Called It: How Our 2024 Agent Communication Proposal Mirrors Google's A2A Protocol
Back in December 2024, we shared a speculative proposal on Dev.to laying out a future where AI agents communicate through standardized API channels. It was a vision rooted in necessity—a world where agents from different systems could interoperate cleanly, securely, and with shared context. Fast forward to April 2025: Google has just announced Agent2Agent (A2A), a communication protocol that not only echoes the same goals but implements them in a remarkably similar fashion. It’s exciting—and honestly validating—to see this vision move from independent proposal to industry-backed protocol. Below, we break down the parallels and explore what this means for the future of agent interoperability. From Proposal to Protocol: A Shared Vision Emerges note to reader: “we” = “myself and chatGPT” When we wrote Proposal: Standard Communication API Channels for AI Agents, it came from a simple question: What would it take for agents to truly understand each other, regardless of who built them? The concept was inspired by both human conversation and established API design—agents should speak in defined schemas, follow intent-driven threads, and be able to authenticate and recognize each other. With the announcement of Agent2Agent (A2A), Google and several partners introduced a specification aiming to solve the very same problem. You can view the current A2A JSON schema here. Core Alignment: Proposal vs. A2A Here's a quick look at how the key ideas line up: Concept Our 2024 Proposal Google A2A Protocol Agent Identity Proposed identity header for agent metadata, with fields for name, origin, and type. Uses "sender" and "recipient" objects with id, name, type, authenticity. Intent Signaling Each message includes an intent tag, scoped to domain-specific action (e.g., intent: "query.weather"). "intent" is a core field, describing agent action purpose (e.g., "intent": "provide.answer"). Message Structure JSON-based payload with meta, data, intent, and optional session fields. JSON spec with id, timestamp, intent, sender, recipient, payload, and optional thread. Threading / Context Support for conversation threads and referencing previous messages. Built-in thread and in_reply_to fields for stateful conversations. Extensibility Encouraged domain-specific schemas layered on top of a shared base. A2A allows "metadata" and "payload" to be customized per domain. Security / Authenticity Mentioned optional auth tokens, public key exchange ideas. Formalized "authenticity" with fields like "authenticated_by" and "verified" status. The symmetry is striking. While their implementation is more robust (and naturally more mature thanks to partner contributions), the direction is unmistakably similar. Why This Matters It’s encouraging to see the conversation move toward shared foundations. Interoperability is a necessary step if we want agents that collaborate rather than compete for dominance. This announcement means: The ecosystem is recognizing that no agent can exist in isolation. There’s real momentum toward open standards in the agent space. Developers and teams working on agent infrastructure now have a concrete reference to build on. At the same time, it’s worth emphasizing: this is just the start. Inter-agent coordination will need to solve for far more than communication—it will involve trust, adaptability, negotiation, and shared context over time. A2A is a strong foundational move, but like all protocols, it’s an invitation to build. Looking Ahead The idea behind our original post was never about staking a claim—it was about imagining what could be useful. Seeing A2A emerge is a reminder that many minds are likely thinking along similar lines, and that when an idea’s time comes, it tends to show up in more than one place. We’ll be watching A2A’s evolution closely—and continuing to build with these principles in mind.

Back in December 2024, we shared a speculative proposal on Dev.to laying out a future where AI agents communicate through standardized API channels. It was a vision rooted in necessity—a world where agents from different systems could interoperate cleanly, securely, and with shared context.
Fast forward to April 2025: Google has just announced Agent2Agent (A2A), a communication protocol that not only echoes the same goals but implements them in a remarkably similar fashion.
It’s exciting—and honestly validating—to see this vision move from independent proposal to industry-backed protocol. Below, we break down the parallels and explore what this means for the future of agent interoperability.
From Proposal to Protocol: A Shared Vision Emerges
note to reader: “we” = “myself and chatGPT”
When we wrote Proposal: Standard Communication API Channels for AI Agents, it came from a simple question: What would it take for agents to truly understand each other, regardless of who built them? The concept was inspired by both human conversation and established API design—agents should speak in defined schemas, follow intent-driven threads, and be able to authenticate and recognize each other.
With the announcement of Agent2Agent (A2A), Google and several partners introduced a specification aiming to solve the very same problem. You can view the current A2A JSON schema here.
Core Alignment: Proposal vs. A2A
Here's a quick look at how the key ideas line up:
Concept | Our 2024 Proposal | Google A2A Protocol |
---|---|---|
Agent Identity | Proposed identity header for agent metadata, with fields for name, origin, and type. | Uses "sender" and "recipient" objects with id , name , type , authenticity . |
Intent Signaling | Each message includes an intent tag, scoped to domain-specific action (e.g., intent: "query.weather" ). |
"intent" is a core field, describing agent action purpose (e.g., "intent": "provide.answer" ). |
Message Structure | JSON-based payload with meta , data , intent , and optional session fields. |
JSON spec with id , timestamp , intent , sender , recipient , payload , and optional thread . |
Threading / Context | Support for conversation threads and referencing previous messages. | Built-in thread and in_reply_to fields for stateful conversations. |
Extensibility | Encouraged domain-specific schemas layered on top of a shared base. | A2A allows "metadata" and "payload" to be customized per domain. |
Security / Authenticity | Mentioned optional auth tokens, public key exchange ideas. | Formalized "authenticity" with fields like "authenticated_by" and "verified" status. |
The symmetry is striking. While their implementation is more robust (and naturally more mature thanks to partner contributions), the direction is unmistakably similar.
Why This Matters
It’s encouraging to see the conversation move toward shared foundations. Interoperability is a necessary step if we want agents that collaborate rather than compete for dominance. This announcement means:
- The ecosystem is recognizing that no agent can exist in isolation.
- There’s real momentum toward open standards in the agent space.
- Developers and teams working on agent infrastructure now have a concrete reference to build on.
At the same time, it’s worth emphasizing: this is just the start. Inter-agent coordination will need to solve for far more than communication—it will involve trust, adaptability, negotiation, and shared context over time. A2A is a strong foundational move, but like all protocols, it’s an invitation to build.
Looking Ahead
The idea behind our original post was never about staking a claim—it was about imagining what could be useful. Seeing A2A emerge is a reminder that many minds are likely thinking along similar lines, and that when an idea’s time comes, it tends to show up in more than one place.
We’ll be watching A2A’s evolution closely—and continuing to build with these principles in mind.