Google ADK Memory: What's There and What's Missing

Google's Agent Development Kit ships with strong opinions about how agents should work. Tool orchestration is clean. Safety guardrails are built in. The execution model gives you visibility into what agents are doing and why. For teams already embedded in Google's ecosystem, ADK is a natural starting point for building production agents.

But ADK treats memory the same way every other framework does: as someone else's problem. The framework provides clear extension points for custom memory handlers, but no batteries-included solution. You get orchestration and safety. You don't get persistence.

What ADK Handles Well

ADK's strength is structured agent execution. It gives you a well-defined lifecycle for agent runs, with hooks for pre-processing, tool selection, and post-processing. The safety layer is particularly thoughtful—guardrails that prevent agents from taking harmful actions or leaking sensitive data aren't afterthoughts but first-class features.

The framework also integrates naturally with Google Cloud services. If your infrastructure already runs on Vertex AI, BigQuery, and Cloud Storage, ADK slots in without friction. Tool calling is clean, and the agent loop is predictable enough to debug in production.

Where Memory Is Missing

ADK doesn't include a persistence layer. Each agent invocation is independent. The framework doesn't maintain state between runs, doesn't track what an agent learned about a user, and doesn't provide mechanisms to recall past interactions. If you need an agent to remember that a user prefers concise answers or works in the automotive industry, you're building that retrieval pipeline yourself.

There's no temporal reasoning either. ADK can't distinguish between a fact that was true yesterday and one that's true today. If your agent needs to understand that a user's budget changed between Q2 and Q3, you need external infrastructure to manage versioned knowledge. Why agent frameworks ship without real memory explains why this pattern repeats across every major framework—orchestration and memory are fundamentally different problems, and frameworks optimize for orchestration.

Cross-agent memory sharing is also absent. If you build a multi-agent system where a research agent and an executor agent collaborate, neither has access to what the other learned in previous runs. Each agent starts fresh every time.

The Pattern Is the Same

ADK follows the same trajectory as LangChain, CrewAI, AutoGen, and the OpenAI SDK. The framework solves the execution problem it was built for and leaves memory as an infrastructure concern for your team. That's not a flaw—it's a scope decision. But it means production teams using ADK will eventually need a separate memory layer to handle cross-session persistence, user-level personalization, and temporal reasoning.

The good news is that ADK's clean extension points make integration straightforward. The framework doesn't fight you when you add external memory. It just doesn't provide it. And context windows are not memory is worth reading before you try to solve this by stuffing more history into your prompts.

FAQ

Does ADK have any memory features at all?

ADK provides session-level state within a single agent run. Agents can track context during execution, but nothing persists after the run completes. For cross-session memory, you build your own integration.

Can I use ADK with an external memory platform?

Yes. ADK's extension points let you inject context before each agent run and save learned facts afterward. The framework is memory-agnostic by design, which means you're free to integrate whichever memory infrastructure fits your use case.