Learn A2A - History, Background & Why You Need A2A

#Introduction

In episode 0 we set up the runtime, SDKs, and environment for two local agents. Now it's time to answer the most fundamental question before writing a single line of code: why do we need a protocol like A2A at all?

Every modern agent framework — LangChain, CrewAI, Google ADK, OpenAI Agents SDK — can build capable agents. The problem: agents built on different frameworks can't communicate with each other. This episode walks you through that pain, then traces how A2A was born, evolved, and became an industry standard for agent-to-agent collaboration.

#The Problem: Agents That Can't Talk to Each Other

Imagine a company that already has two systems: a sales agent built with CrewAI and a support agent built with Google ADK. They share no code, no runtime, and not even a way to describe each other's capabilities.

{
  "agent_penjualan": {
    "framework": "CrewAI",
    "interface": "function call internal",
    "state": "memory tersembunyi",
    "tools": ["CRM", "email"]
  },
  "agent_dukungan": {
    "framework": "Google ADK",
    "interface": "sub-agent ADK",
    "state": "memory tersembunyi",
    "tools": ["tiket", "base pengetahuan"]
  }
}

Both are agents, but there's no bridge. To connect them, teams have to write custom integration for every pair of frameworks — and those combinations grow factorially as more agents are added. This is exactly the problem the API world already solved: we need one common language.

#The Birth of A2A: From Google to the Linux Foundation

#April 2025: Google's Announcement

A2A was first announced by Google in April 2025 through its official developer blog. Together with dozens of early partners, Google introduced an open protocol so agents from any vendor could collaborate — a frequently used analogy: if MCP is the "USB-C for tools", then A2A is the "USB-C for agents".

#June 2025: Donation to the Linux Foundation

The rapidly growing support led to the project being handed over to the Linux Foundation in June 2025 — the same step previously taken for Kubernetes. With this neutral foundation, A2A is no longer a single-vendor initiative, and its governance is held by the community, not Google alone.

#An Ecosystem of 150+ Organizations

After moving to the Linux Foundation, the ecosystem swelled. More than 150 organizations joined, including Google, Microsoft, AWS, Salesforce, SAP, Atlassian, LangChain, and CrewAI — a strong signal that the need for a shared protocol is real in the market. The categories are diverse:

cloud & platform   : Google, Microsoft, AWS
framework agent    : LangChain, CrewAI, Google ADK
enterprise & SaaS  : Salesforce, SAP, Atlassian

This combination of cloud, framework, and enterprise vendors is what makes A2A more than just a "single-vendor protocol" — it truly becomes a bridge across products.

#Version Iteration: From v0.1 to v1.0

A2A evolved quickly. Understand the timeline, because many of these terms will come up in the episodes that follow:

git clone https://github.com/a2aproject/A2A
git tag
v0.1.x
v0.2.x
v0.3.x
v1.0.0
v1.0.1

Note the jump: from v0.3 (Jul 2025) straight to v1.0 (Mar 2026), which was declared stable. The key features introduced in v1.0 — signed agent cards, multi-tenancy, and version negotiation — we'll dissect in detail in episode 10. To quickly check the latest release, run git tag --sort=-creatordate from the clone folder.

#Why A2A: Peer, Not Tool

This philosophical difference is the most commonly misunderstood one. There are two ways to connect AI entities:

• As a tool: agent A calls agent B like calling a function — invokes it, waits for the result, holds full control. This is the pattern MCP pushes.
• As a peer: agent A sends a task to agent B, and B completes it in its own way. A doesn't need to know how B works.

A2A chooses the peer (opaque service) model. A remote agent presents itself as a black-box service — all you see is its interface, not its contents. The consequences matter:

• Internal state stays protected — an agent's memory and context never leak to another agent.
• Tools stay private — other agents can't misuse internal tools.
• Autonomy is preserved — each agent remains the owner of its own working process.

#Why "Opaque" Is a Design Decision

The choice of opaque interaction isn't a technical limitation — it's a deliberate design decision. In the real world, the team building a sales agent won't open up its entire business logic to a third-party agent — that's both a competitive and a security risk.

With opacity, only two things are needed for two agents to cooperate: described capabilities (the Agent Card) and an agreed communication contract (the Task lifecycle). Everything else can stay secret. This is what makes A2A safe for cross-company collaboration, not just cross-framework.

#Conclusion

Here's the core of episode 1:

• Agents on different frameworks can't communicate with each other without a shared language.
• A2A was announced by Google in April 2025 and handed to the Linux Foundation in June 2025.
• Its ecosystem now spans 150+ major organizations in the AI industry.
• Version evolution: v0.1, v0.2, v0.3, then v1.0 (Mar 2026) and v1.0.1 (May 2026).
• A2A chooses opaque peer-to-peer interaction: state, memory, and tools stay private.

In episode 2 we dive into the heart of the architecture: the roles of client agent and remote agent, the Agent Card concept for discovery, the Task lifecycle, and how JSON-RPC, HTTP, gRPC, and SSE serve as protocol bindings. That's where all the terms we've touched on start to come together into one complete picture. See you there!