---
title: "Google ADK memory: sessions, state and Memory Bank"
description: "Google ADK offers session state, MemoryService and Vertex AI Memory Bank. What each stores, and how to add temporal memory through a function tool."
canonical: https://past.dev/integrations/google-adk
last-updated: 2026-09-02
---
# Add memory to Google ADK agents

Source: https://past.dev/integrations/google-adk

Google ADK separates session state from memory. State is a key-value scratchpad with user and app scope prefixes. MemoryService is a searchable cross-session archive, and Vertex AI Memory Bank implements it with LLM-extracted user memories. A function tool that calls past.dev over HTTP adds event-time records, supersession with both values queryable, and evidence with sources and a status value.

## Google ADK memory scope

The [Agent Development Kit](https://adk.dev/) documents short-term and long-term layers separately. [Session state](https://adk.dev/sessions/state/) is a key-value scratchpad with scope prefixes: unprefixed keys belong to the current session, `user:` keys follow a `user_id` across sessions, `app:` keys are shared across users, and `temp:` keys are discarded when the invocation ends. Whether state persists depends on the configured session service.

[MemoryService](https://adk.dev/sessions/memory/) is the long-term layer: a searchable archive drawing on many past sessions, exposed to agents through the `load_memory` and `preload_memory` tools. Documented implementations are `InMemoryMemoryService` (keyword matching, no persistence), `VertexAiMemoryBankService`, and `VertexAiRagMemoryService` (vector retrieval over stored conversations). Memory operates per user, keyed by `user_id` and `app_name`.

- State is a plain key-value map. Writing `user:plan` replaces the value, so it holds the current plan and no record of previous plans.
- Memory is scoped to one user in one app. A fact that concerns a whole team has no documented home beyond `app:` state, which is again a key-value map.
- Neither state nor the memory interface documents event-time fields, validity windows or supersession links.

## Memory Bank, and what a temporal store adds

[Memory Bank](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/overview) is the managed option on Vertex AI Agent Engine. It uses generative models to extract memories from conversations, stores long-term user preferences and facts, consolidates related memories, and returns them to the agent in later sessions. For a per-user personalization layer inside Google Cloud, that is the documented path.

past.dev covers a different shape of requirement. Each fact is recorded at its [event time](/glossary/event-time), taken from the source's own timestamp rather than ingestion time. A change closes the previous fact's [validity window](/glossary/validity-window) and links the replacement, and both values stay queryable with dates. Recall returns evidence with sources and one of four status values. Deployment is managed or self-hosted, with memory in your own Postgres.

| Dimension | Memory Bank (documented) | past.dev |
| --- | --- | --- |
| Stored unit | LLM-generated memories: user preferences and facts | Facts with event time, validity windows and supersession links |
| Scope | Per user and app | Per project key, shared by any agent that holds it |
| Updates | Related memories are consolidated | Superseded fact closed; both values stay queryable |
| Recall result | Fetched memories | Dated evidence with sources and a status value |
| Deployment | Managed on Vertex AI Agent Engine | Managed, or [self-hosted](/docs/memory-api/self-hosting) in your Postgres |

## The integration: two function tools, two endpoints

ADK wraps a plain Python function as a `FunctionTool` when you add it to an agent's `tools` list, building the declaration from the signature, type hints and docstring ([function tools](https://adk.dev/tools-custom/function-tools/)). So the integration is two functions that call past.dev over HTTP.

```python
import os, requests

BASE = "https://api.past.dev/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['PAST_API_KEY']}"}

def remember_fact(text: str, happened_at: str) -> dict:
    """Store a durable fact with the time it actually happened (ISO 8601)."""
    return requests.post(f"{BASE}/ingest", headers=HEADERS, json={
        "content": text,
        "timestamp": happened_at,
    }).json()

def recall_memory(question: str) -> dict:
    """Return ranked, dated evidence and a status value for a question."""
    return requests.post(f"{BASE}/recall", headers=HEADERS, json={
        "query": question,
    }).json()
```

Add `remember_fact` and `recall_memory` to the `tools` list and cover them in the agent's instruction: store durable facts with their original timestamps, recall before answering questions about people, decisions or history.

Applications can route on `status`. `Supported` means the evidence establishes the answer. `Conflicted` returns evidence from credible sources that disagree. `NoKnownSupport` means the stored evidence does not establish an answer. `UnknownBecauseDegraded` means retrieval could not complete and should be treated as an unknown result.

## Choosing per requirement

- Scratchpad for the current task: session state, with `temp:` for values that should end with the invocation.
- Per-user personalization memories inside Google Cloud: Memory Bank through `VertexAiMemoryBankService`.
- Facts that change over time, backfilled history on original dates, evidence with sources and a status value, or a store you host yourself: the function tool above.

The [quickstart](/docs/memory-api/quickstart) reaches a first recall in four calls. The [benchmarks](/benchmarks) document how recall is measured. [Facts that change over time](/guides/facts-that-change-over-time) covers the temporal model in depth.

## Frequently asked questions

### What is the difference between ADK session state and Memory Bank?

Session state is a key-value scratchpad for the current conversation, with user and app prefixes for wider scope. Memory Bank is a managed Vertex AI service that extracts long-term user memories from conversations and makes them searchable across sessions.

### Do I need Vertex AI to add memory to a Google ADK agent?

No. ADK function tools are plain Python functions, so an agent can call any HTTP memory service. Memory Bank is one documented option and runs on Google Cloud; an external memory API works from any deployment.

### Can a Google ADK agent remember what was true on a past date?

Session state and memory retrieval return present values. A temporal memory API keeps validity windows and superseded values, so the agent can ask what was true on a specific date and cite dated evidence.

## Related

- [Memory for the OpenAI Agents SDK](https://past.dev/integrations/openai-agents-sdk)
- [Memory for the Vercel AI SDK](https://past.dev/integrations/vercel-ai-sdk)
- [Memory for LangGraph](https://past.dev/integrations/langgraph)
- [Event time](https://past.dev/glossary/event-time)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)