Redis Agent Memory

Session and long-term memory for Google ADK agents using Redis Agent Memory.

Redis Agent Memory gives ADK agents two tiers of persistent memory:

• Session memory: session-scoped storage for the current conversation.
• Long-term memory: facts extracted from past conversations, stored as vectors in Redis and searchable by semantic similarity with recency boosting.

Choose a deployment

Set backend="redis-agent-memory", the default, on every service and tool config. Redis Cloud and self-managed Agent Memory share one Data Plane API, so you select a deployment by pointing api_base_url at the right Data Plane, not by changing backend:

Wire memory into an ADK agent one of two ways:

See Integration patterns for detailed tradeoff comparison.

Session memory

RedisSessionMemoryService implements ADK's BaseSessionService. It stores the current conversation in the configured memory backend.

from adk_redis.sessions import (
    RedisSessionMemoryService,
    RedisSessionMemoryServiceConfig,
)

session_service = RedisSessionMemoryService(
    config=RedisSessionMemoryServiceConfig(
        backend="redis-agent-memory",
        api_base_url="https://your-endpoint.redis.io",
        api_key="your-api-key",
        store_id="your-store-id",
        default_namespace="my_app",
    )
)

Configuration

Incremental appends

The session service uses an incremental append API: it sends only new messages rather than re-sending the entire conversation on every turn. Network overhead stays proportional to message size, not conversation length.

Supported operations

The service implements all of ADK's session methods:

• create_session: Create a new session
• get_session: Retrieve an existing session
• list_sessions: List sessions for an app/user
• delete_session: Remove a session
• append_event: Add a new message (incremental)

Long-term memory

RedisLongTermMemoryService implements ADK's BaseMemoryService. After each conversation, the memory backend extracts structured information (facts, preferences, episodic events), embeds them as vectors, and stores them in Redis for semantic search across all past sessions.

from adk_redis.memory import (
    RedisLongTermMemoryService,
    RedisLongTermMemoryServiceConfig,
)

memory_service = RedisLongTermMemoryService(
    config=RedisLongTermMemoryServiceConfig(
        backend="redis-agent-memory",
        api_base_url="https://your-endpoint.redis.io",
        api_key="your-api-key",
        store_id="your-store-id",
        default_namespace="my_app",
    )
)

Configuration

Framework services

Pass both services to an ADK Runner. The framework handles memory automatically: sessions are persisted via session memory, long-term memory is searched before each agent turn, and an after_agent_callback triggers extraction in the background.

from google.adk import Agent
from google.adk.agents.callback_context import CallbackContext
from google.adk.runners import Runner

async def after_agent(callback_context: CallbackContext):
    await callback_context.add_session_to_memory()

agent = Agent(
    name="memory_agent",
    model="gemini-2.5-flash",
    instruction="You are a helpful assistant with long-term memory.",
    after_agent_callback=after_agent,
)

runner = Runner(
    agent=agent,
    app_name="my_app",
    session_service=session_service,
    memory_service=memory_service,
)

Runtime flow

1. ADK creates or retrieves a session via RedisSessionMemoryService.
2. Long-term memory is searched for context relevant to the current conversation.
3. User messages are appended to session memory incrementally.
4. The LLM generates a response using session context plus retrieved memories.
5. after_agent_callback triggers add_session_to_memory() for background extraction.

REST tools

Give the agent explicit memory tools that the LLM calls like any other function. The LLM decides when to search memory, what to store, and what to update. No framework services required. The tools share a single MemoryToolConfig.

adk-redis ships six memory tools:

from adk_redis.tools.memory import (
    SearchMemoryTool,
    CreateMemoryTool,
    GetMemoryTool,
    UpdateMemoryTool,
    DeleteMemoryTool,
    MemoryPromptTool,
    MemoryToolConfig,
)

config = MemoryToolConfig(
    backend="redis-agent-memory",
    api_base_url="https://your-endpoint.redis.io",
    api_key="your-api-key",
    store_id="your-store-id",
    default_namespace="my_app",
)

agent = Agent(
    model="gemini-2.5-flash",
    name="memory_agent",
    tools=[
        SearchMemoryTool(config=config),
        CreateMemoryTool(config=config),
        GetMemoryTool(config=config),
        UpdateMemoryTool(config=config),
        DeleteMemoryTool(config=config),
        MemoryPromptTool(config=config),
    ],
)

Requires prompt engineering to teach the LLM memory management strategy, but gives the agent genuine autonomy over its own memory.

Invocation-scoped users

The memory tools resolve the acting user from the ADK tool_context before falling back to the user configured on MemoryToolConfig. A single shared Runner therefore stays scoped to the user of each invocation, with no per-user tool instances.

CreateMemoryTool.run_async() also accepts an application-supplied id for idempotent writes against Redis Agent Memory. IDs are derived with namespace and user scope to prevent cross-tenant collisions, and are never exposed to the LLM.

MCP tools

MCP memory tools are only available on the deprecated Agent Memory Server backend. The redis-agent-memory backend does not expose an MCP endpoint, on Redis Cloud or self-managed; use the REST tools above.

More info

• Integration patterns: Detailed tradeoff comparison of the approaches
• managed_memory_quickstart: Framework services, no Docker
• travel_agent_memory_tools: REST tools only
• Self-managed Agent Memory: run Agent Memory on your own Kubernetes cluster
• Agent Memory Server (deprecated): existing deployments and migration