Memory integration patterns

Approaches for connecting Google ADK agents to Redis memory.

adk-redis offers two approaches for connecting agents to memory. Each has different tradeoffs around control and complexity.

Comparison

Approach Control Complexity Protocol Best for
ADK services Framework Low HTTP Invisible infrastructure
REST tools LLM Medium HTTP Explicit memory management

Both use backend="redis-agent-memory", the default, on Redis Cloud or self-managed. See Redis Agent Memory for the deployment options.

Note:
A third approach, MCP memory tools, is only available on the deprecated Agent Memory Server backend.

1. ADK services (framework-managed)

Configure RedisSessionMemoryService and RedisLongTermMemoryService, pass them to the Runner, and the framework handles everything automatically. Memory extraction happens in the background. Search happens before each agent turn. The agent code never directly interacts with memory.

from google.adk.runners import Runner
from adk_redis.sessions import (
    RedisSessionMemoryService,
    RedisSessionMemoryServiceConfig,
)
from adk_redis.memory import (
    RedisLongTermMemoryService,
    RedisLongTermMemoryServiceConfig,
)

runner = Runner(
    agent=agent,
    app_name="my_app",
    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",
        )
    ),
    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",
        )
    ),
)

Tradeoffs: Simplest to implement, hardest to customize. The agent has no explicit control over what gets stored or when it searches.

2. REST tools (LLM-controlled)

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.

from adk_redis.tools.memory import (
    SearchMemoryTool,
    CreateMemoryTool,
    UpdateMemoryTool,
    DeleteMemoryTool,
    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),
        UpdateMemoryTool(config=config),
        DeleteMemoryTool(config=config),
    ],
)

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

Hybrid approach

The most powerful configuration combines framework services with REST tools. Framework services handle session persistence and automatic background extraction. REST tools give the LLM explicit CRUD control on top.

# LLM-controlled tools on the Agent
agent = Agent(
    model="gemini-2.5-flash",
    name="hybrid_agent",
    tools=[
        SearchMemoryTool(config=config),
        CreateMemoryTool(config=config),
        UpdateMemoryTool(config=config),
        DeleteMemoryTool(config=config),
    ],
)

# Framework-managed services on the Runner
runner = Runner(
    agent=agent,
    app_name="my_app",
    session_service=session_service,   # Auto session management
    memory_service=memory_service,     # Auto memory search
)

The pattern works on redis-agent-memory. The example that demonstrates it, travel_agent_memory_hybrid, is currently written against the deprecated backend; see Agent Memory Server (deprecated).

More info

RATE THIS PAGE
Back to top ↑