Google ADK

ADK’s memory service is an interface; Anona implements it. Wire AnonaMemoryService in as your agent’s memory_service and it can recall across sessions, deployments and restarts, scoped to the right user automatically, because ADK hands you user_id on every call.

pip install 'anona[adk]'

Setup

from google.adk.agents import LlmAgent
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from google.adk.tools import load_memory
from anona.integrations import MemoryBridge
from anona.integrations.google_adk import AnonaMemoryService

bridge = MemoryBridge(api_key="anona_live_...", space_id="my-agent")

async def save_to_memory(callback_context):
    await callback_context.add_session_to_memory()

agent = LlmAgent(
    name="assistant",
    model="gemini-2.0-flash",
    tools=[load_memory],                   # lets the model search memory
    after_agent_callback=save_to_memory,   # stores the finished turn
)

runner = Runner(
    agent=agent,
    app_name="my-app",
    session_service=InMemorySessionService(),
    memory_service=AnonaMemoryService(bridge=bridge),
)

Nothing here is automatic

Both directions require you to wire something. This is how ADK’s memory services work in general, not a limitation of this adapter. Reading: two options, different cost. Attach the built-in load_memory tool (above) and the model decides for itself when to call it, with zero calls if it never asks. Attach preload_memory instead (from google.adk.tools import preload_memory) and it runs on its own, with no model decision involved. But “automatic” here is more expensive than it sounds: it fires before every model call, not once per turn. A single tool-calling turn (the model calls one tool, then answers) measured 2 separate retrieve calls, both for the identical query, because ADK re-runs it once per model step, not once per turn. Unlike this SDK’s LangChain adapter, there is no per-turn cache to collapse that back down. A three-tool-call turn costs four retrieves for one logical question, all billed. Reach for preload_memory only once that cost is a deliberate choice; load_memory is the lower-cost default for most agents. You can also call await tool_context.search_memory(query) directly from inside your own tool or callback code if neither built-in shape fits. Writing. A session is never saved to memory just because a run finished. The supported hook is Context.add_session_to_memory(), reachable from any callback that receives a context. after_agent_callback, as above, is the natural place, since it fires once per runner.run_async() call, after any internal tool-calling loop has finished. Skip this and Anona never receives a single turn; the agent still runs, silently, with no memory. Note the callback’s parameter must be named exactly callback_context, because ADK invokes it as a keyword argument. You can also call memory_service.add_session_to_memory(session) directly: add_session_to_memory on the callback context is just a shortcut for that, using the callback’s own session. Calling this again on a session you’ve already saved, the normal shape of a multi-turn conversation with one call per turn on the same session.id, is safe: you don’t need to track what you’ve already sent yourself. In the common case (each call sees the same, growing event history, true of the after_agent_callback idiom above, and of a fresh session_service.get_session(...) fetch) only what’s new goes out. If a call instead receives a different, shorter view of the same session, for example a trimmed fetch via GetSessionConfig(num_recent_events=N), this can’t always tell which of those events it already saw, and resends the whole view rather than guess and risk dropping something new. So: never a silently lost turn; occasionally, in that specific case, a duplicate.

Per-user isolation, at no cost

ADK passes user_id and app_name on every memory call, and this adapter maps them onto Anona’s scope, asymmetrically between writing and reading:

ADK	`add_session_to_memory` (write)	`search_memory` (read)
`user_id`	`user_id`	`user_id`
`app_name`	`agent_id`	not forwarded
`session.id`	`session_id`	(ADK’s `search_memory` takes no session)

app_name is written as agent_id but deliberately not forwarded on a read. Anona consolidates raw memories into synthesized observations over time, and an observation is tagged by user only, not by the agent that happened to write the originating turns, so a two-key user_id + agent_id search would never match a consolidated observation, only raw, unconsolidated facts. Since app_name is the one scope key ADK supplies automatically with no way to opt out, forwarding it on every read would have silently hidden your agent’s best answers behind its rawest ones, for every ADK user, all the time. Isolation itself is unaffected: user_id (the key that actually keeps one end user’s memories from another’s) is forwarded on every call, read and write alike. One space serves every user of your app, and a memory written under one user_id is only ever returned to that same user. You configure nothing.

Failure behaviour

If Anona is unreachable, search_memory returns no memories and the agent continues. Failures are logged, never raised.

Getting Started

SDKs & MCP

Framework Integrations

Guides

Setup

Nothing here is automatic

Per-user isolation, at no cost

Failure behaviour

​Setup

​Nothing here is automatic

​Per-user isolation, at no cost

​Failure behaviour

Setup

Nothing here is automatic

Per-user isolation, at no cost

Failure behaviour