Google ADK Stops Looking Like a Demo Kit and Starts Looking Like a Stateful Agent Platform

Google’s ADK team is starting to behave like it knows the hard part of agent frameworks begins right after the demo works once.

That is the real signal in adk-python v1.31.0, published on April 17. The release adds Firestore support, memory-ingestion hooks for VertexAiMemoryBankService, a sandbox integration for computer-use flows on Vertex AI Agent Engine, and a stack of improvements to ADK’s live debugging UI. None of that is headline bait in the way “new multi-agent framework” used to be. It is better than headline bait. It is evidence that Google is moving ADK deeper into the operational layer where state, observability, and controlled execution decide whether an agent system is usable by a real team or just impressive in a keynote.

The surface-level summary is easy enough. Google added a redesigned real-time chat and testing interface, session display names, a structured trace view, a graph view for agent architectures, event filtering, and a dedicated computer-use view for screenshots and logs. Underneath that UI pass, the framework now supports Firestore, exposes live_session_id in LlmResponse, supports memories.ingest_events in its Vertex AI memory service, and integrates Vertex AI Agent Engine Sandbox for computer-use tasks. It also bumps the minimum MCP version to 1.24.0, fixes the broken console URL path after adk deploy agent_engine, and cleans up BigQuery plugin behavior for A2A transfers, spans, and metadata.

That sounds like a mixed bag until you look at it through the lens that matters: what kind of platform is Google trying to build? Increasingly, the answer is not “an SDK for prompting Gemini with extra steps.” The answer is “a stateful runtime for agents that need memory, tooling, visibility, and an upgrade path into managed infrastructure.” That is a much more serious ambition, and v1.31.0 is the kind of release you ship when you are chasing it.

Firestore is the least glamorous feature here, which is why it may be the most important one

Agent-framework discourse still spends too much time on orchestration metaphors and not enough on persistence. But persistence is where the pain starts. Once an agent needs to survive across user sessions, retain relevant context, resume work, or hand state across services, the framework’s data layer stops being optional. Firestore support matters because it gives ADK another durable backing store inside a stack enterprises already know how to permission, monitor, and pay for.

That is not just a checkbox. It says Google understands that the buyer for ADK is increasingly not the solo hacker trying a graph workflow on a weekend. It is the team that wants an agent to keep enough memory to be useful without inventing its own storage conventions from scratch. LangGraph won a lot of early respect by taking persistence and checkpointing seriously. CrewAI has spent the last few releases sanding down checkpointing and runtime safety. Microsoft Agent Framework is leaning into workflows and packaged internal capabilities. Google adding Firestore support pushes ADK into the same grown-up conversation.

The memory-ingestion work matters for the same reason. Supporting memories.ingest_events in VertexAiMemoryBankService sounds narrow, but it is exactly the sort of hook you need if memory is supposed to become part of the system rather than an afterthought bolted onto prompts. The industry has mostly graduated from pretending that “just give the model more context” is a memory strategy. Event ingestion is a step toward explicit memory pipelines, which is where reliable agent behavior usually begins.

Google is quietly turning observability into a product feature

The biggest quality-of-life changes in v1.31.0 are in the live UI, and they are more strategic than they look. A cleaner chat interface is nice. A structured trace view, graph visualization, event filtering, and computer-use inspection are better. Those features turn debugging from “scroll through a wall of logs and guess” into something closer to an operator workflow.

This is one of the clearest market shifts in agent tooling right now. Frameworks are no longer judged only by whether they can call tools or route between agents. They are judged by whether a human can understand what the system just did, why it did it, and where it got weird. That is why LangSmith exists. It is why Microsoft keeps pushing workflow views and human approval surfaces. It is why Anthropic’s managed-agents pitch revolves around the harness and session boundary as much as the model. Google investing in trace and graph views suggests ADK is competing on that terrain now too.

There is also a subtler point here: better visibility changes who can operate the framework. A system that only the original author can debug does not scale organizationally. A system with named sessions, filtered events, and graph views can be handed to another engineer, a solutions architect, or an SRE without a ritual sacrifice. That is how internal platforms spread.

Computer use is moving from novelty to constrained infrastructure

The Vertex AI Agent Engine Sandbox integration for computer use is another meaningful tell. For the last year, “computer use” has mostly been sold as a flashy capability. Click the browser. Fill out the form. Watch the model act like a junior operator. The missing piece has been controlled execution. If the model is going to interact with a UI, inspect screenshots, and manipulate a live environment, the runtime boundary matters more than the demo.

By tying computer use to an Agent Engine sandbox, Google is making a statement that should sound familiar by now: useful agent systems need isolation. Anthropic is making the same argument from a hosted-runtime angle. LiteLLM’s recent nightly hardening says gateways are becoming part of the trust boundary too. Flowise’s recent MCP RCE advisory made the downside painfully concrete. In other words, the market is learning the obvious lesson the hard way: once agents touch tools, files, or UI surfaces, infrastructure matters more than prompt cleverness.

Google is not done proving this stack is battle-tested, but v1.31.0 pushes in the right direction. Sandboxed computer use is a more credible product story than generic “AI can use your desktop” theater.

The MCP bump is small, but the politics are large

One easy detail to miss is the minimum MCP bump from 1.23.0 to 1.24.0. That looks like packaging housekeeping. It is not. MCP compatibility is rapidly becoming a baseline expectation for agent frameworks that want to be treated as ecosystem infrastructure. If your framework falls behind on the dominant tool-interoperability layer, you start to look provincial fast.

Google’s broader ADK pitch has been openness: model-agnostic, deployment-agnostic, available in Python, TypeScript, Go, and Java, with graph workflows, evaluation, and deploy-anywhere flexibility. Keeping MCP current is part of making that pitch believable. So are the BigQuery plugin fixes for A2A transfers and metadata. They suggest ADK is not just trying to be a Gemini wrapper with a nice website. It is trying to sit at the center of a wider runtime graph where models, tools, memory, and services all need to interoperate without custom glue every sprint.

That does not eliminate the usual caution flags. The repo still has more than 19,000 stars and hundreds of open issues, which is both a sign of momentum and a reminder that fast adoption creates visible pressure. Rapid release cadence is good until it becomes a substitute for stability. Teams evaluating ADK should treat that honestly: the framework is maturing in public, and public maturation is messy.

Still, the direction is hard to miss. Google’s agent stack is becoming more coherent. Gemini is the model layer. ADK is the framework layer. Agent Engine is the managed runtime path. Firestore, memory services, traces, graph views, and sandboxed computer use are the connective tissue. That is a much stronger story than “Google also has agents now.”

If you are a practitioner, the advice is straightforward. If your team is already in Google Cloud, ADK deserves a more serious evaluation than it did a month ago, especially for stateful workflows that need durable storage and better operator visibility. If you are cross-cloud or wary of platform gravity, keep testing how portable the architecture really is before you commit. And if you are comparing ADK with LangGraph, CrewAI, or Microsoft Agent Framework, stop comparing only syntax and agent metaphors. Compare persistence, observability, isolation, and upgrade paths. That is where the real framework decisions live now.

Google did not ship the loudest release in the category this week. It may have shipped one of the more important ones. Because once a framework starts investing this heavily in state, traceability, and execution boundaries, it is no longer trying to win the demo. It is trying to earn the pager.

Sources: Google ADK v1.31.0 release notes, ADK documentation, Google ADK v1.30.0 release notes, GitHub issue #5336