Google ADK Agent Memory: What's Built In

You deploy an agent using Google's Agent Development Kit. It connects to your Vertex AI models, calls BigQuery for data analysis, and uses Cloud Storage for document retrieval. The agent handles a customer's analytics question perfectly—querying the right tables, interpreting results accurately, and presenting findings in the format the customer prefers. The session ends well.

The next day, the same customer asks a follow-up question about the same dataset. The agent doesn't remember which tables it queried, what format the customer liked, or that it already analyzed half the relevant data yesterday. It starts the entire analysis from scratch, and the customer notices.

This is Google ADK in production. The framework excels at orchestration, tool calling, and safety guardrails. But persistent memory isn't part of the package. In this guide, I'll walk you through what ADK actually provides for state management, where the memory gaps are, and how to architect memory that works with ADK's strengths.

What ADK Provides

Agent Execution Lifecycle

ADK gives you a well-structured agent execution model. Each agent run follows a predictable lifecycle: receive input, select tools, execute actions, generate response. You can hook into each stage with custom logic—preprocessing inputs, post-processing outputs, validating tool calls. The lifecycle is clean and debuggable.

Within a single run, ADK maintains execution state. The agent tracks which tools it has called, what results it received, and what reasoning steps it has taken. This intra-run state enables multi-step workflows where the agent plans, executes, evaluates, and iterates before responding.

Safety Guardrails

ADK's safety layer is one of its distinguishing features. Guardrails prevent agents from taking harmful actions, leaking sensitive data, or exceeding defined boundaries. These aren't afterthoughts—they're integrated into the execution lifecycle, checking each action before it's taken.

For enterprise teams, this is significant. Safety guardrails that work at the framework level are more reliable than application-level checks. ADK handles this well, and it's a genuine reason to choose the framework for production deployments. Read more on how to make AI agents remember across sessions with long-term LLM memory

Google Cloud Integration

ADK integrates naturally with Google's cloud ecosystem. Vertex AI for model hosting. BigQuery for data queries. Cloud Storage for documents. Pub/Sub for event-driven architectures. If your infrastructure runs on Google Cloud, ADK reduces integration friction significantly.

This ecosystem integration extends to tool calling. You can define tools that query any Google Cloud service, and the agent can reason about when and how to use them. For data-heavy applications, the combination of ADK's orchestration and Google Cloud's data services is particularly strong.

Session State (Within a Run)

During a single agent run, ADK maintains state that agents can read and write. This includes the conversation context for the current interaction, tool call results, and any custom state your agent logic sets. This state is available throughout the run and enables complex multi-step reasoning within a session.

But this state is scoped to the current run. When the run completes, it's gone. The next run starts with a clean state, regardless of what was learned in prior runs. Google ADK Memory: What's There and What's Missing covers this boundary in detail.

Where Memory Is Missing

No Cross-Session Persistence

ADK has no mechanism to persist learned facts between agent runs. When a run completes, the execution state—including everything the agent learned about the user—disappears. The next run for the same user starts completely fresh.

You can build persistence yourself. Store state to a database at the end of each run, load it at the start of the next one. But ADK provides no infrastructure for this—no user identity management, no state serialization, no retrieval mechanisms. The framework ends where the run ends.

No User Identity

ADK doesn't have a concept of "this request is from the same user as yesterday's request." Every run is anonymous from the framework's perspective. If you need to know that request #47 and request #148 came from the same person, you manage that mapping in your application layer.

Without user identity, personalization is impossible at the framework level. The agent can't adapt to individual users because it doesn't know who they are. It can't recall prior preferences because it doesn't know which preferences belong to which person.

No Temporal Reasoning

ADK doesn't track when facts were learned or whether they've changed. If you inject context from a prior session, the agent processes it as current truth with no temporal metadata. A fact from six months ago and a fact from yesterday have the same weight.

For agents serving users over time, this creates silent failures. The agent references outdated information because it can't distinguish old from current. User preferences evolve, project scopes change, and team dynamics shift—but the agent treats all injected context as equally valid. Why agent frameworks ship without real memory explains why this temporal gap exists across all major frameworks.

No Self-Improving Retrieval

If you build a retrieval mechanism to load context before each ADK run, that retrieval is static. The same query returns the same context every time, regardless of whether that context was useful last time. There's no feedback loop from retrieval quality to retrieval strategy.

Production memory systems should learn which context leads to good outcomes and prioritize it. They should detect when retrieved context causes errors and adjust accordingly. ADK's architecture supports plugging in such a system, but provides none of this intelligence itself.

What Production Memory Requires

Adding memory to ADK means solving the same five problems every framework leaves unsolved.

Persistent user profiles. Store everything the agent learns about each user: preferences, domain context, communication style, past decisions, ongoing projects. Load the relevant profile before each run. The agent should know who the user is before processing their first message.

Temporal versioning. Tag facts with timestamps. When facts change, create new versions instead of overwriting. Retrieve the correct version based on the query's temporal context. An agent that can answer "what was true last month?" is fundamentally more trustworthy than one that can only serve the latest value.

Cross-session continuity. Each run should build on prior runs. The agent should know what it recommended last time, what worked, and what didn't. Consistency across sessions is what separates a useful tool from a frustrating one.

Self-improving retrieval. Track retrieval quality over time. When retrieved context leads to positive outcomes, reinforce that retrieval pattern. When it leads to corrections, adjust. Memory that gets smarter with use is meaningfully better than static retrieval.

Multi-source ingestion. ADK's Google Cloud integration gives agents access to BigQuery, Cloud Storage, and other services through tool calls. But tool calls are point-in-time queries. Memory should continuously ingest context from these sources, maintaining an up-to-date picture of the user's world. Context windows are not memory explains why point-in-time queries don't replace persistent context.

Architecture Options

Custom Layer on Google Cloud

Build your memory infrastructure using Google Cloud services you likely already have. Use Firestore or Cloud SQL for user profiles. Use Vertex AI Vector Search for semantic retrieval. Use Cloud Functions to process conversations and extract facts after each ADK run.

This approach keeps everything in the Google ecosystem, which aligns with ADK's design philosophy. You manage the memory logic—extraction, versioning, retrieval—but leverage managed infrastructure for storage and compute. Expect 2-4 months of engineering effort for a production-quality implementation.

Open-Source Memory Frameworks

Tools like Mem0 and Zep integrate with any agent framework, including ADK. Mem0 handles personal memory extraction and retrieval. Zep's Graphiti engine provides temporal knowledge graphs. Both reduce the custom engineering burden while giving you control over the code.

The integration pattern: before each ADK run, query the memory framework for user context and inject it into the agent's system prompt. After the run, send the conversation to the framework for fact extraction and storage. The memory framework handles persistence; ADK handles execution.

Managed Memory Platforms

Platforms like HydraDB provide memory as a managed service, handling extraction, persistence, temporal reasoning, and retrieval quality end-to-end. The LongMemEval-s benchmark (ICLR 2025) measured this directly: managed platforms that treat memory as a first-class concern outperform ad-hoc implementations across all categories, with the widest gaps in temporal reasoning and preference understanding.

For teams using ADK in production, a managed platform complements ADK's strengths. ADK handles orchestration, safety, and Google Cloud integration. The memory platform handles everything the agent needs to know across sessions. The separation is clean.

FAQ

Does ADK support any form of memory?

ADK supports session state within a single agent run. Agents can track context, tool results, and custom state during execution. But nothing persists after the run completes. Cross-session memory requires external infrastructure.

Can I use Google Cloud's AI memory features with ADK?

Google Cloud offers various storage and retrieval services (Vertex AI Search, Firestore, BigQuery). You can use these as building blocks for a memory layer, but you still need to build the orchestration—what to store, when to retrieve, how to handle temporal changes. Google Cloud provides infrastructure; memory architecture is yours to design.

How does ADK's safety layer interact with memory?

ADK's guardrails apply to the current run's execution. If you inject memory context into the system prompt, guardrails will evaluate the agent's actions based on that context. But guardrails don't evaluate the memory itself—if you inject incorrect or outdated context, the guardrails won't catch that. Memory quality is your responsibility.

What's the simplest memory integration for ADK?

Store a JSON blob of user preferences and key facts in Firestore, keyed by user ID. Before each ADK run, load the blob and prepend it to the system prompt. After each run, use an LLM call to extract new facts and update the blob. This takes a day to implement and immediately makes the agent more useful for returning users.

Should I build memory or buy it?

If your team has 2-4 engineers and 3+ months, building gives you control over every architectural decision. If memory is blocking your roadmap today, a managed platform gets you unblocked faster. Most teams start building, discover the complexity of temporal reasoning and retrieval quality, and eventually evaluate managed options. Knowing this trajectory helps you make the right decision for your timeline.

How does ADK handle memory in multi-agent architectures?

ADK supports multi-agent setups where specialized agents collaborate on a task. But each agent's state is scoped to its own execution. If agent A learns that the user prefers concise responses and hands off to agent B, agent B doesn't inherit that preference—it starts with whatever context was explicitly passed in the handoff payload. For multi-agent systems that serve the same user repeatedly, a shared memory layer that all agents can read from is essential. The alternative—encoding everything in handoff messages—doesn't scale past two or three agents and completely breaks across sessions.

What about using Vertex AI's grounding features for memory?

Vertex AI offers grounding against Google Search and custom data stores. Grounding helps with factual accuracy, but it's retrieval, not memory. It answers "what's true about this topic?" not "what does this agent know about this user?" You can use grounding alongside memory—ground the agent's responses in current facts while also loading user-specific context from your memory store—but one doesn't replace the other. Teams that conflate grounding with memory end up with agents that are factually accurate but personally oblivious.

Conclusion

Google ADK is a strong framework for building production agents, especially within the Google Cloud ecosystem. Orchestration, safety, and tool calling are well-designed. Memory is deliberately out of scope, which means it's your problem to solve.

The memory layer you build—or integrate—determines whether your agent serves users once or serves them well over time. User profiles, temporal versioning, cross-session continuity, and self-improving retrieval are the difference between an agent that impresses in a demo and one that retains users in production.

Start with ADK for what it does well. Add memory for what it doesn't. The framework's clean extension points make integration straightforward. The harder question isn't how to connect memory to ADK—it's how to design memory architecture that actually serves your users. Answer that question first, then choose your implementation approach.