Skip to main content
Dakera gives your agent decay-weighted memory that fades stale context and keeps fresh, important facts on top.
Later chats can recall the fact — Dakera weights it by importance and decays older memories.

Quick Start

1

Install

This installs dakera>=0.12.8. Alternatively, pip install dakera installs the SDK on its own.Run the Dakera server locally with Docker Compose — see dakera-ai/dakera-deploy for the compose file. The default port is 3000, matching the adapter default.
2

Configure with environment variables

3

Configure with a dict


How It Works

Dakera stores memories with an importance score and timestamps them. Over time, memories decay — so stale context stops competing with fresh, relevant facts.

Memory Tiers

PraisonAI maps its two memory tiers onto distinct Dakera memory_type values: Unlike Mem0 or ChromaDB, Dakera has a first-class memory_type field — so the two tiers never collapse.

Configuration Options

Env fallback chain for URL: DAKERA_URLDAKERA_API_URL"http://localhost:3000". Precedence: config dict > env var > hard default. Config dict values always win.

Reserved metadata keys

These keys are lifted out of metadata and promoted to Dakera fields. Explicit kwargs win over metadata values: Reserved keys are stripped from metadata before storage so they never leak into the payload.

Environment variables only


Precedence Ladder

Do not invent a DakeraConfig dataclass, a Dakera(...) instance form, or a Bool / Array level — none exist in the SDK. The supported forms are: memory="dakera" (env-var driven), memory={"provider": "dakera", "config": {...}} (nested), or a flat dict of config keys (memory={"url": "...", "api_key": "..."}).

Store, Search, Delete & Reset

Storing memories

importance, session_id, and tags can be passed as top-level kwargs or inside the metadata dict — kwargs always win. metadata is the container, not a promoted field.

Searching memories

Retrieving all memories

Deleting memories

Dakera is one of the only providers that supports DeletableMemoryProtocol and ResettableMemoryProtocol — mem0, ChromaDB, and MongoDB do not implement these optional protocols.

Resetting tiers


Common Patterns

Namespace per user / tenant

Different agent_ids on the same Dakera server keep memories fully isolated.

Overriding tier mapping for custom Dakera types

If your Dakera server is configured with custom memory types, override the defaults.

Boost recall for high-signal facts

Higher importance scores surface this fact ahead of lower-scored memories when Dakera ranks results.

Filter recall by minimum importance


Best Practices

Each agent or user should have a unique agent_id so memories don’t cross-read. One Dakera server can host many namespaced agents.
Set default_importance in config to bias all new stores without repeating it on every call. Pass explicit importance only on the highest-signal facts.
Reset working (short-term) memory at the end of each session or task. Avoid resetting episodic (long-term) memory unless you intentionally want to wipe all durable knowledge — this matches how Dakera’s decay is tuned.
Use DAKERA_URL, DAKERA_API_KEY, and DAKERA_AGENT_ID so credentials don’t appear in source code or version control.

Deploying Dakera

Dakera is a self-hosted memory server. The quickest way to run it is with Docker Compose via dakera-ai/dakera-deploy. The default compose port is 3000, which matches the adapter’s default http://localhost:3000, so no URL config is needed for local development.

Memory Configuration

Provider strings, MemoryConfig, and backend overview.

Custom Memory Adapters

Register your own memory backend with the adapter registry.

MongoDB Memory

Document-backed memory with optional Atlas Vector Search.

Memory Overview

Memory system overview and quickstart.

Memory Storage

All supported database backends.