{"slug": "google-adk-2-0-is-stable-why-that-makes-the-openai-split-matter-more", "title": "Google ADK 2.0 Is Stable — Why That Makes the OpenAI Split Matter More", "summary": "Google released Agent Development Kit (ADK) 2.0.0 stable and a2a-sdk 1.0.3 stable, signaling a complete production-ready multi-agent framework. The coordinated release contrasts with OpenAI's decision to decline a pull request implementing Google's Agent-to-Agent (A2A) protocol, highlighting divergent strategies: Google focuses on agent-to-agent coordination via an open protocol, while OpenAI emphasizes per-agent capability with Sandbox Agents.", "body_md": "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.\n\nThis matters more than it looks because of what it exposes: OpenAI and Google are building agent infrastructure for fundamentally different problems.\n\nGoogle'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.\n\nWhat 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.\"\n\nHere'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.\n\nA2A 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?\n\nOpenAI'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.**\n\nGoogle is betting on **agent-to-agent coordination** — a protocol layer that lets you build systems where agents specialize and delegate to each other.\n\nOpenAI 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.\n\nBoth are real problems. They're just orthogonal.\n\nIf you're evaluating frameworks for a production AI agent system, here's what stability means:\n\n| Framework | Status | Multi-Agent Story | Interop |\n|---|---|---|---|\nGoogle ADK 2.0.0 |\nStable | A2A protocol (1.0.3 stable) | A2A-based; open protocol |\nOpenAI Agents 0.17 |\nStable | Sandbox Agents + handoff-based | SDK-internal only |\nLangChain 0.3 |\nStable | LangGraph composition | Adapter-based for A2A |\nMicrosoft Semantic Kernel |\nStable | Plugin-based orchestration | Native A2A support |\n\nADK 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.\n\nOpenAI'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.\n\nThree questions to ask yourself:\n\n**1. Do you need single-agent or multi-agent?**\n\nIf 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.\n\n**2. Do you need portability?**\n\nA2A 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.\n\n**3. Do you need capability stability?**\n\nADK 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.\n\nHere's how the approaches differ in practice:\n\n**With OpenAI agents and handoff:**\n\n``` python\nfrom openai.agents import Agent\n\nagent_a = Agent(\n    model=\"gpt-4-turbo\",\n    tools=[retrieve_docs],\n)\n\nagent_b = Agent(\n    model=\"gpt-4-turbo\",\n    tools=[reason_and_execute],\n)\n\n# Coordination is SDK-internal\nresponse = agent_a.run(\"Get docs and ask agent_b to reason about them\")\n# Agent A has to decide to hand off; agent B has no standard way to discover agent A\n```\n\n**With Google ADK + A2A:**\n\n``` python\nfrom google.genai.adk import Agent\nfrom a2a_sdk import A2AClient\n\nagent_a = Agent(\n    name=\"document_retriever\",\n    model=\"gemini-2.0-pro\",\n    tools=[retrieve_docs],\n)\n\nagent_b = Agent(\n    name=\"reasoner\",\n    model=\"gemini-2.0-pro\",\n    tools=[reason_and_execute],\n)\n\n# A2A-based discovery and calling\nclient = A2AClient()\nagent_b = client.discover(\"reasoner\")\nresponse = agent_b.call(query=\"Reason about these docs\", context=docs)\n```\n\nThe 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.\n\nThis is the moment where framework choice locks you into an architectural commitment. If you're building:\n\nGoogle'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.\n\nThe 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*.\n\n**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.", "url": "https://wpnews.pro/news/google-adk-2-0-is-stable-why-that-makes-the-openai-split-matter-more", "canonical_source": "https://dev.to/peytongreen_dev/google-adk-20-is-stable-why-that-makes-the-openai-split-matter-more-3c6l", "published_at": "2026-07-04 08:45:03+00:00", "updated_at": "2026-07-04 08:48:35.906199+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools", "large-language-models", "ai-products"], "entities": ["Google", "OpenAI", "Agent Development Kit (ADK)", "Agent-to-Agent (A2A) protocol", "Sandbox Agents", "LangChain", "Microsoft Semantic Kernel"], "alternates": {"html": "https://wpnews.pro/news/google-adk-2-0-is-stable-why-that-makes-the-openai-split-matter-more", "markdown": "https://wpnews.pro/news/google-adk-2-0-is-stable-why-that-makes-the-openai-split-matter-more.md", "text": "https://wpnews.pro/news/google-adk-2-0-is-stable-why-that-makes-the-openai-split-matter-more.txt", "jsonld": "https://wpnews.pro/news/google-adk-2-0-is-stable-why-that-makes-the-openai-split-matter-more.jsonld"}}