# Google ADK 2.0 Is Stable — Why That Makes the OpenAI Split Matter More > Source: > Published: 2026-07-04 08:45:03+00:00 Last week, Google shipped Agent Development Kit (ADK) 2.0.0 stable, and the same week, a2a-sdk hit 1.0.3 stable. Together, they're a statement: Google has a complete, production-ready agent framework and is willing to build it without OpenAI alignment. This matters more than it looks because of what it exposes: OpenAI and Google are building agent infrastructure for fundamentally different problems. Google's jump from 1.29 to 2.0 signals a defined breaking-change boundary. The API surface is stable enough to commit to. You can now build production agents on ADK without prerelease churn risk. What makes this significant isn't the version bump — it's the timing. ADK 2.0 stable and a2a-sdk 1.0.3 stable landed in the same week. That's coordinated messaging. Google's narrative is clear: "We have a complete, stable, production-ready multi-agent framework." Here's what changed the conversation: In March 2026, OpenAI received a 1,200-line pull request implementing Agent-to-Agent (A2A) protocol support in their agents SDK. They declined it. A2A is Google's answer to multi-agent coordination. It's a standardized protocol for agents to discover, call, and share context with each other. It solves a concrete problem: if you want to compose capabilities across multiple AI agents (and you do — no single agent model is good at everything), how do you do that without reinventing message protocols every time? OpenAI's "no thanks" wasn't hostile — it's still an open community feature request. But it signals something fundamental: **OpenAI and Google are optimizing for different things.** Google is betting on **agent-to-agent coordination** — a protocol layer that lets you build systems where agents specialize and delegate to each other. OpenAI is betting on **per-agent capability** — Sandbox Agents (shipped in the same window) that let a single agent operate a filesystem, run arbitrary code, and persist snapshots. Both are real problems. They're just orthogonal. If you're evaluating frameworks for a production AI agent system, here's what stability means: | Framework | Status | Multi-Agent Story | Interop | |---|---|---|---| Google ADK 2.0.0 | Stable | A2A protocol (1.0.3 stable) | A2A-based; open protocol | OpenAI Agents 0.17 | Stable | Sandbox Agents + handoff-based | SDK-internal only | LangChain 0.3 | Stable | LangGraph composition | Adapter-based for A2A | Microsoft Semantic Kernel | Stable | Plugin-based orchestration | Native A2A support | ADK 2.0.0's stability matters because it means you can adopt the A2A protocol without worrying about breaking changes. If interoperability across agent systems matters to your architecture (and it should — monolithic agents are a bottleneck), ADK gives you a stable foundation. OpenAI's refusal of A2A doesn't make OpenAI agents bad. Sandbox Agents are genuinely powerful — they let your agent run code, modify files, and operate an environment. For single-agent, high-autonomy workloads, that's valuable. But if you need your agent to collaborate with specialized agents built by your team or third parties, you're back to handoff-based coordination inside the SDK. Three questions to ask yourself: **1. Do you need single-agent or multi-agent?** If a single agent with sandbox access solves your problem, OpenAI agents work great. If you're building a system where agents specialize (e.g., one reads docs, one retrieves, one reasons, one executes), ADK + A2A gives you a protocol-based way to compose them. **2. Do you need portability?** A2A is a protocol. It means your agents can interoperate with frameworks that speak A2A (Google ADK, LangChain, Semantic Kernel). OpenAI's handoff model is SDK-specific — your orchestration logic lives in OpenAI agent code, not in a portable protocol. **3. Do you need capability stability?** ADK 2.0.0 stable and a2a-sdk 1.0.3 stable mean you can depend on these APIs. OpenAI's agent SDK is stable too, but multi-agent coordination still relies on feature requests and community pressure. Here's how the approaches differ in practice: **With OpenAI agents and handoff:** ``` python from openai.agents import Agent agent_a = Agent( model="gpt-4-turbo", tools=[retrieve_docs], ) agent_b = Agent( model="gpt-4-turbo", tools=[reason_and_execute], ) # Coordination is SDK-internal response = agent_a.run("Get docs and ask agent_b to reason about them") # Agent A has to decide to hand off; agent B has no standard way to discover agent A ``` **With Google ADK + A2A:** ``` python from google.genai.adk import Agent from a2a_sdk import A2AClient agent_a = Agent( name="document_retriever", model="gemini-2.0-pro", tools=[retrieve_docs], ) agent_b = Agent( name="reasoner", model="gemini-2.0-pro", tools=[reason_and_execute], ) # A2A-based discovery and calling client = A2AClient() agent_b = client.discover("reasoner") response = agent_b.call(query="Reason about these docs", context=docs) ``` The second approach is more portable — agent_b doesn't have to live inside the same process or SDK context as agent_a. It's a network boundary that frameworks can standardize around. This is the moment where framework choice locks you into an architectural commitment. If you're building: Google's stability release says: "We're committed to this direction." OpenAI's rejection of A2A says: "We're optimizing for something else." Both are valid bets. Your architecture decides which one wins for you. The real shift is that you now have two stable, competing visions for what agent infrastructure should be. ADK 2.0.0 stable didn't change what's possible — it changed what's *dependable*. **Next:** If you're upgrading to newer agent frameworks, watch for breaking changes. OpenAI's 0.13 → 0.17 window introduced two silent breaks that will bite you if you're not careful.