Strands Agents Integration

Give Strands agents durable memory that survives across sessions. strands-dakera ships a dakera_memory tool the model can call, plus a drop-in DakeraMemoryStore for the Strands MemoryManager — recall ranked by importance × recency × semantic relevance, not just vector distance.

Overview

Strands gives you a clean, model-driven agent loop — but the model still starts every session with an empty context window. strands-dakera connects that loop to a self-hosted Dakera memory server so facts, preferences and decisions persist across turns, sessions and processes. Instead of re-stuffing the whole transcript into the prompt or expiring context on a fixed TTL, Dakera scores every memory by importance × recency × semantic relevance and surfaces the handful that actually matter for the current turn.

The package is deliberately small and offers two integration points that share one server and one agent namespace:

• The dakera_memory tool — a native Strands tool the model invokes explicitly to store, retrieve, get, update and delete memories. Best when you want the model to reason out loud about what to remember.
• DakeraMemoryStore — a class that conforms to the Strands MemoryStore protocol and plugs into MemoryManager. The agent recalls and writes memory automatically, with no explicit tool call and no prompt changes.

When to use which

Install & Setup

git clone https://github.com/dakera-ai/dakera-deploy
cd dakera-deploy && docker compose up -d

# server + MinIO object storage, listening on :3000

pip install strands-dakera

export DAKERA_BASE_URL=http://localhost:3000
export DAKERA_API_KEY=dk-your-key-here

Pattern 1 — The dakera_memory tool

Add dakera_memory to your agent's tools and the model can explicitly store, retrieve, get, update and delete memories. A single action parameter routes to the five operations; the tool returns a Strands ToolResult with status="success" and JSON content, or status="error" with a message.

from strands import Agent
from strands_dakera import dakera_memory

agent = Agent(tools=[dakera_memory])

# Store a memory with an importance weight and type
agent.tool.dakera_memory(
    action="store",
    agent_id="alex",
    content="Alex prefers dark-mode dashboards and async standups.",
    importance=0.8,
    memory_type="semantic",
    metadata={"category": "preferences"},
)

# Decay-weighted semantic recall
agent.tool.dakera_memory(
    action="retrieve",
    agent_id="alex",
    query="how does alex like to work?",
    top_k=5,
)

Tool actions

Tool parameters

Consent on writes

The mutating actions — store, update and delete — prompt for confirmation and show a content preview before executing. Read actions (retrieve, get) never require confirmation. Set BYPASS_TOOL_CONSENT=true to skip the prompt in automated or non-interactive runs.

# Skip write confirmations (CI, servers, headless agents)
export BYPASS_TOOL_CONSENT=true

Pattern 2 — DakeraMemoryStore (automatic)

Plug DakeraMemoryStore into the Strands MemoryManager and memory becomes invisible: the manager searches the store to recall context — injected into the prompt automatically — and, when writable, writes new memories back through it. The class conforms to the Strands MemoryStore protocol, implementing search() and add().

from strands import Agent
from strands.memory import MemoryManager
from strands_dakera import DakeraMemoryStore

# Recall + write, distilling durable facts from the conversation.
store = DakeraMemoryStore(agent_id="alex", writable=True, extraction=True)
agent = Agent(memory_manager=MemoryManager(stores=[store]))

agent("Remember that I prefer dark-mode dashboards.")
agent("How do I like my dashboards?")  # recalls the stored preference

DakeraMemoryStore options

All keyword options after agent_id are keyword-only. The store also exports a DakeraMemoryStoreConfig dataclass (extending the Strands MemoryStoreConfig) carrying the same Dakera-specific fields — agent_id, importance, memory_type, base_url, api_key — for programmatic configuration.

How recall & extraction flow

On each turn the MemoryManager calls search(query, options) on the store, which performs decay-weighted, access-aware recall favouring important, recently accessed memories. Results come back as MemoryEntry objects — each with content plus a metadata dict containing id, score, importance, memory_type, created_at and any custom metadata — and the manager injects them into the prompt.

When extraction is enabled, the manager's ModelExtractor distils durable facts from the conversation before they are written, rather than dumping raw turns. The store implements add(content, metadata) — not add_messages() — so extraction stays the manager's responsibility while the store handles persistence with at-least-once semantics and server-side deduplication.

# Read-only recall: surface memories but never write back
recall_only = DakeraMemoryStore(
    agent_id="alex",
    writable=False,
    max_search_results=8,
)

# Write with a fixed importance and a procedural type
proc = DakeraMemoryStore(
    agent_id="alex",
    writable=True,
    importance=0.6,
    memory_type="procedural",
)

Worked example — a memory-backed assistant

Combine both patterns: the store gives effortless cross-session continuity, while the tool lets the model curate memory explicitly when it matters.

import os
from strands import Agent
from strands.memory import MemoryManager
from strands_dakera import dakera_memory, DakeraMemoryStore

os.environ["DAKERA_BASE_URL"] = "http://localhost:3000"
os.environ["BYPASS_TOOL_CONSENT"] = "true"  # headless

store = DakeraMemoryStore(agent_id="alex", writable=True, extraction=True)

agent = Agent(
    tools=[dakera_memory],
    memory_manager=MemoryManager(stores=[store]),
)

# Session 1 — the store quietly captures the preference
agent("I'm Alex. I like concise answers and I ship on Fridays.")

# Later session, new process — recall persists
agent("What do you know about how I work?")

# The model can also curate memory explicitly
agent.tool.dakera_memory(
    action="store",
    agent_id="alex",
    content="Alex's release day moved from Friday to Wednesday.",
    importance=0.9,
    memory_type="semantic",
)

Environment variables

Memory types

Both patterns accept a memory_type that tags each memory with the kind of knowledge it holds. The store defaults to episodic; the tool defaults to episodic when the model omits it. Typing memories keeps recall coherent — a durable preference and a one-off event don't compete as if they were the same class of fact.

Advanced — sharing one client

Both patterns construct a DakeraServiceClient from DAKERA_BASE_URL and DAKERA_API_KEY. For multiple stores — or to reuse a single connection across an app — build the client once and inject it with the client= parameter:

from strands_dakera import DakeraServiceClient, DakeraMemoryStore

client = DakeraServiceClient(
    base_url="http://localhost:3000",
    api_key="dk-your-key-here",
)

# Two stores, one connection, different write policies
prefs = DakeraMemoryStore(agent_id="alex", client=client, memory_type="semantic")
events = DakeraMemoryStore(agent_id="alex", client=client, memory_type="episodic")

The client wraps the dakera Python SDK and exposes the same operations the tool uses under the hood — store_memory, get_memory, search_memories, update_memory and delete_memory — so tool calls and store writes land in exactly the same place.

Troubleshooting

Related integrations

Links

• GitHub — strands-dakera
• PyPI — strands-dakera
• Strands Agents
• Dakera deploy — Docker Compose setup
• All integrations

Frequently Asked Questions