By Google’s Agent Development Kit reached version 1.0 stable in April 2026, landing across Python, Go, Java, and TypeScript at the same time. For the past year, most developers have been treating ADK as experimental — useful for prototypes, not production. The 1.0 release is Google’s formal claim that the framework is ready. Whether it’s ready for your team is a different question, and the answer depends on which features actually shipped and what the framework still can’t do.
What “Stable” Actually Bought You
The 1.0 release isn’t a marketing milestone. Three concrete features crossed from missing to available, and together they change the production calculus for ADK.
The most significant addition is Event Compaction. Long-running agents — customer service bots, research assistants, coding agents that persist across sessions — run into context window limits fast. Beta ADK had no good answer for this. Event Compaction introduces a sliding-window mechanism that uses an LLM to summarize older conversation history and writes that summary back into the session, transparent to the agent. In production benchmarks, Google reports a 38% reduction in token usage and 18% improvement in latency. Those numbers matter when you’re paying per token at scale. The full technical implementation is in the ADK compaction docs.
The second addition is the Service Registry. Previously, swapping from a local in-memory session store during development to Vertex AI Memory Bank in production required code changes. Now you declare your backends in a services.yaml file and switch with a config change. If you’ve used Docker Compose to abstract environment differences, the mental model is similar. The caveat: the available backends are Google Cloud backends. This is where the portability argument starts to have edges.
Third: the core went fully async. Python’s BaseSessionService, BaseArtifactService, and BaseMemoryService are now async-first. For concurrent agent deployments, this isn’t optional — it’s what makes the framework scale.
Multi-Language Parity: The Enterprise Unlock
Most agent frameworks are Python-only. That’s fine for startups and AI-native teams, but it creates a hard barrier for enterprises running Java or Go services that have been in production for years. ADK 1.0 closing the gap across all four languages simultaneously is the feature that unlocks the framework for those organizations.
ADK for Java 1.0 ships with a full plugin architecture, Human-in-the-Loop tool confirmations, a ContainerCodeExecutor for sandboxed code via Docker, and a ComputerUseTool for browser automation. ADK Go 1.0 adds native OpenTelemetry integration — every model call and tool execution generates structured traces and spans that feed into any OTel-compatible backend. Google claims a Python agent can be ported to Go or Java “with zero logic changes.” That deserves skepticism in practice, but the cross-language feature parity is real.
A2A: When Your Agents Need to Talk to Someone Else’s Agents
ADK agents natively implement the Agent2Agent (A2A) protocol, which surpassed 150 organizations in production as of April 2026 and is now governed by the Linux Foundation. The practical implication: an ADK agent can discover and call an agent built on LangGraph, CrewAI, or AWS Agentcore through a standardized interface. Microsoft, AWS, Cisco, IBM, Salesforce, and SAP are all running A2A in production. This is no longer a Google-only story.
It helps to distinguish A2A from MCP here. MCP (Model Context Protocol) handles agent-to-tool and agent-to-data connections. A2A handles agent-to-agent communication across organizational boundaries. Together, they form the interoperability stack for multi-vendor agent systems. If your agents need to coordinate with agents you don’t control, A2A native support is a meaningful differentiator for ADK.
Where ADK Still Falls Short
One architectural quirk that will catch you off guard: ADK allows only one built-in tool per agent. You cannot combine Google Search with a custom function tool in the same agent. This is a hard limit, not a configuration issue, and it surfaces in real use cases faster than you’d expect. Workarounds exist — sub-agent delegation — but they add complexity.
The developer experience still has rough spots. Error messages, unit testing scaffolding, and edge-case documentation need more work. The community consensus as of April 2026 is that ADK needs another 6-12 months of polish before the DX feels fully production-grade. One developer after building with it put it plainly: a genuine framework with genuine ideas, but not perfect. That’s an honest description.
The Verdict
Use ADK 1.0 now if you’re on Google Cloud, need Go or Java support for agents, or are building systems that require cross-vendor agent coordination via A2A. Event Compaction alone changes the economics for long-running agents enough to justify moving from beta.
Wait — or use LangGraph — if you need complex conditional workflows with time-travel debugging, you’re running primarily on AWS or Azure, or you need a larger community and more battle-tested patterns. LangGraph remains the most mature choice for complex production agent graphs. CrewAI remains the fastest path from zero to a working agent.
Google ADK 1.0 is no longer a prototype framework wearing a production label. But “stable” doesn’t mean “best for everyone.” Know which column you’re in before you commit. For more on the full ADK release notes, the official docs have the complete changelog.
