A library inside one LangGraph process, or a memory service every agent can share
LangMem is LangChain's MIT-licensed memory library: tools and a background manager that live in your LangGraph application. Dakera is a server that any agent, in any language, connects to. Here is the same job written both ways.
Reviewed October 2026
The same memory, in code
Left, the LangMem quickstart from its documentation: two memory tools handed to a LangGraph agent, with memories in a LangGraph store. Right, Dakera behind the same kind of LangChain agent through langchain-dakera 0.3.0.
from langgraph.prebuilt import (
create_react_agent,
)
from langgraph.store.memory import (
InMemoryStore,
)
from langmem import (
create_manage_memory_tool,
create_search_memory_tool,
)
store = InMemoryStore(index={
"dims": 1536,
"embed":
"openai:text-embedding-3-small",
})
agent = create_react_agent(
"anthropic:claude-3-5-sonnet-latest",
tools=[
create_manage_memory_tool(
namespace=("memories",)),
create_search_memory_tool(
namespace=("memories",)),
],
store=store,
)from langchain_dakera import DakeraMemory
memory = DakeraMemory(
api_url="http://localhost:3000",
api_key="dk-mykey",
agent_id="my-agent",
recall_k=5,
)
# Store a turn
memory.save_context(
{"input": "I'm building a chatbot."},
{"output": "Nice to meet you."},
)
# Recall, even after a restart
ctx = memory.load_memory_variables(
{"input": "What was I building?"}
)
print(ctx["history"])LangMem lets the agent call memory tools during the conversation and also offers a background manager and prompt optimization. DakeraMemory is documented on the LangChain integration page; with langchain-core 1.x, call load_memory_variables and save_context directly as shown.
Where the memory lives
| LangMem | Dakera | |
|---|---|---|
| Form | Python library in your LangGraph process | Server your processes call |
| Storage | A LangGraph store: InMemoryStore for development, or a persistent one such as AsyncPostgresStore | Built in, on a volume; survives restarts |
| Languages | Python | Python, TypeScript, Go and Rust SDKs; REST; MCP |
| Who decides what to remember | Memory tools the agent calls, plus a background manager that extracts and consolidates | Your code stores; the server extracts entities, ranks, decays and deduplicates without an LLM |
| Memory types | Semantic, episodic and procedural, plus prompt optimization | Episodic, semantic, procedural and working, with importance, tags, TTL and sessions |
| Version | 0.0.30, October 2025, MIT | v0.12.0, October 2026 |
Then read it from anywhere
A memory service stops being tied to the process that wrote it. A Python worker stores a fact, and a TypeScript front end, a Go service or Claude (through the MCP server) recalls it.
from dakera import DakeraClient
client = DakeraClient(
"http://localhost:3000",
api_key="dk-mykey",
)
client.store_memory(
agent_id="my-agent",
content="User is learning Rust",
importance=0.8,
)import {
DakeraClient,
} from '@dakera-ai/dakera';
const client = new DakeraClient({
baseUrl: 'http://localhost:3000',
apiKey: 'dk-mykey',
});
const { memories } = await client.recall(
'my-agent', 'what is the user learning?',
{ top_k: 5 },
);
memories.forEach(m =>
console.log(m.content));Go and Rust SDKs also provide store and recall; see the Go and Rust pages.
What a shared service adds in v0.12.0
- Isolation. Namespaces, scoped API keys pinned to them, and namespace quotas that are enforced.
- Retrieval beyond one embedding. Hybrid BM25 and vector search, RRF fusion and a cross-encoder reranker, with multilingual embeddings across 100+ languages and full-text stemming in 18.
- Protection. AES-256-GCM at rest once a key is configured, per-namespace rotation, encrypted backups and authenticated, rate-limited gRPC for vector operations.
- Lifecycle. Six decay curves, TTL, forget, deduplication and consolidation, so memory stays relevant without a custom job.
- Availability. Multi-node high availability with replicated writes,
/health/readyprobes and Prometheus alert rules with a Grafana dashboard. - Existing data. Dakera imports JSONL, CSV, Mem0 and Zep exports.
When to choose each
Choose LangMem if
- You build on LangGraph and want memory tools that fit its store with no new infrastructure.
- You want background extraction, consolidation and prompt optimization from the same library.
- Your memories are fine inside a LangGraph store you already operate, such as Postgres.
- Your application is one Python process.
Choose Dakera if
- More than one process, language or framework needs the same memory.
- You want retrieval, decay and entity extraction handled for you, with no per-call model cost.
- Memory must be encrypted, namespaced, backed up and monitored as its own service.
- You may move off LangGraph later and want memory to stay put.
Prefer managed? Dakera Cloud is coming. Join the waitlist.
Frequently asked questions
Can I use Dakera inside a LangGraph or LangChain app?
Yes. langchain-dakera 0.3.0 provides DakeraMemory, DakeraVectorStore, DakeraAgentTools and more for Python, and @dakera-ai/langchain covers LangChain.js. Both work with Dakera server v0.12.0.
Does LangMem require LangGraph?
Its documentation says the core memory API works with any storage system, while its native integration targets LangGraph's long-term memory store.
Do I lose memories when my process restarts?
With LangMem it depends on the LangGraph store: InMemoryStore is for development, and a persistent store such as Postgres keeps data. Dakera persists to its data volume.
Does Dakera optimize prompts like LangMem?
No. Dakera is a memory service for storing and recalling; prompt optimization stays in your framework.
Run Dakera on your own infrastructure.
One binary with its models baked in and no per-call fees. Start it with one Docker command and see it for yourself.
Prefer managed hosting? Join the Dakera Cloud waitlist →