Skip to main content

Session State & Memory for Google ADK Agents

The official ADK sessions / state guide and memory guide describe a powerful but unforgiving model: misuse a state prefix and you can leak one user's data into another user's session.

This page covers how to use ADK's three state scopes correctly and how to choose between the available MemoryService implementations.

The three state prefixes​

ADK organizes session state by prefix. The prefix is not decorative — it changes who can read the value and how long it persists.

PrefixScopePersistenceExample
No prefixThis session onlyUntil the session endsstate["last_search_query"]
user:All sessions for this userAcross sessions for the same userstate["user:preferred_language"]
app:All sessions for all users in this appTenant-widestate["app:enabled_features"]
temp:This single LLM call onlyWiped after one turnstate["temp:retry_count"]

Get the prefix wrong and either:

  • A user's preference leaks to another user (app: when you meant user:)
  • Settings vanish unexpectedly (no prefix when you needed user:)
  • Per-turn state pollutes across turns (no temp: prefix on transient data)

Checklist​

1. Audit every state[...] write in your agent​

Before deploying a Google ADK agent to production, grep your agent code for state[ and verify each write uses the intended prefix. Treat this like a security review — because it is one.

2. Choose the right MemoryService for cross-session recall​

ADK ships three implementations of MemoryService for long-term memory beyond the active session:

ServiceWhen to useTradeoffs
InMemoryMemoryServiceLocal development, demosWiped on restart; not for production
VertexAiMemoryBankProduction with cross-session recallManaged by Google; pay-per-store
RAG-backed (Vector Search / custom)Large knowledge corpora the agent should "recall"You own infra; needs embedding pipeline

Default: VertexAiMemoryBank for production unless you specifically need RAG over a large document corpus.

3. Audit memory before each release​

In TraptureIQ's Sessions module, playback a representative session and verify:

  • The agent recalls user-level facts (preferences, prior decisions)
  • The agent does not recall facts from other users
  • The agent does not treat temp: state as durable

This 5-minute review catches most state-leak bugs.

4. Bound session length​

Long sessions create three problems: cost (tokens grow), latency (longer context = slower), and state pollution (more chances for prefix bugs). Enforce a session length cap aligned to your use case:

Use caseSuggested cap
Customer support chat30 minutes or 50 turns
Internal assistant4 hours or 200 turns
Long-running workflowUse the A2A pattern, not one giant session

5. Set a state-key naming convention​

Every team eventually invents user:lang and user:language for the same thing. Prevent it:

<scope>:<feature>.<sub_feature>
user:preferences.language
user:preferences.timezone
app:features.flags.beta_search

Document the canonical key list. Treat additions like schema changes.

Anti-patterns​

  • Storing PII without a prefix — Lives only in the current session, which is correct in scope, but is then often duplicated into logs anyway. Use TraptureIQ's AgentGuard → PII redaction on the log path.
  • Storing tokens or credentials in any state — Use a secret manager, not session state.
  • Mixing memory and prompt — Don't dump memory content into the system prompt. Use ADK's MemoryService retrieval at runtime so the agent reads the relevant slice.
  • Mutating app: state from request handlers — Treat app: as feature-flag-grade config, not as a write target on every request.

Where to investigate​

  • Session playback → Sessions
  • Sessions table for cross-session inspection → Session Dashboard
  • Auditing state writes → Logs (filter by state.write events)

References​