Memori is an open-source, agent-native memory layer from Memori Labs. It observes conversations and execution traces—tool calls, workflow steps, decisions, outcomes and failures—then converts selected signals into structured, persistent memory. Later, an application or agent can retrieve a small, scoped set of memories instead of replaying an entire transcript.
This is a different job from document RAG. RAG usually answers “what does the source corpus say?” Agent memory must also answer “what happened, to whom, in which project, when, with what outcome, and is it still true?” Memori’s value depends less on storing many facts than on writing selectively, separating users and projects, resolving corrections, preserving lineage, recalling at the right moment and deleting reliably.
From execution trace to recalled context
conversation + agent trace + tool results
|
v
sanitize / attribute / normalize
|
score what is memory-worthy
|
.------------+-------------.
v v v
facts events/outcomes decisions/patterns
'------------+-------------'
v
structured memory store
entity / project / process / session / source / time
|
rank: relevance + recency + signal + decay
|
v
smallest useful recall
|
correction / supersession / deletion
The raw trace is input, not necessarily the final memory object. Product explanations say ingestion is asynchronous: tool activity and conversation can be normalized, scored and distilled after an interaction without delaying the response path. Raw traces may remain available for audit while durable primitives carry metadata such as entity, project, session, source, signal, timestamp and outcome.
What Memori is—and is not
| System | Primary unit | Best question | Typical failure |
|---|---|---|---|
| Conversation history | Message | What was said recently? | Context becomes long, expensive and internally inconsistent |
| Document RAG | Chunk/document | What does an external source say? | Weak handling of personal state, outcomes and corrections |
| Workflow database | Explicit application row | What is the authoritative transaction state? | Requires developers to model every field and transition |
| Memori | Structured memory derived from conversation and trace | Which prior state helps this agent act now? | Extraction or ranking can promote noisy, private or stale observations |
Do not use probabilistic memory as the system of record for balances, permissions, orders, medical facts or legal status. Those belong in authoritative application tables and should be fetched at decision time. Memori is better for preferences, prior attempts, outcomes, reusable workflow knowledge and contextual signals whose provenance can be shown.
The architecture choices that matter
The open-source architecture is described as LLM-, framework- and datastore-agnostic. Attribution scopes memory to an entity and process; augmentation turns raw activity into structured memory; recall uses semantic relevance, ranking and decay; wrappers can inject selected context into later model calls. The design supports Memori Cloud and a bring-your-own-database path.
| Layer | Responsibility | Evaluation question |
|---|---|---|
| Capture | Collect conversation, trace, tools and outcomes | Exactly which events are observed, and can sensitive tools be excluded? |
| Attribution | Assign entity, project, process and session | Can malformed IDs cause cross-user or cross-tenant recall? |
| Augmentation | Extract, classify, enrich and consolidate memory | Which model runs, where, with what retry and confidence policy? |
| Storage | Persist structured items, embeddings, lineage and trace | Who controls encryption, backup, region, retention and schema migration? |
| Recall | Filter, rank, decay and return relevant context | Can every result explain source, scope and currentness? |
| Observability | Show writes, recalls, performance and quota | Can operators detect bleed, stale recall and runaway write volume? |
Why trace-derived memory can add information
A transcript may say “I’ll retry with the CSV parser,” but the trace can reveal which parser ran, which file failed, the error, the fallback and whether the output passed validation. Capturing the execution path can preserve causal evidence that a conversational summary loses. Useful examples include a deploy command that repeatedly fails under a specific environment, a data source that returned stale rows, or a support workflow whose escalation resolved the case.
| Trace signal | Potential durable memory | Do not store blindly |
|---|---|---|
| Tool call and result | Known-working procedure or recurring failure condition | Raw payloads, tokens, customer records or transient stack traces |
| Decision and rationale | Chosen approach with scope and evidence | Unapproved model speculation presented as team policy |
| Outcome | Whether a prior plan succeeded, failed or was reverted | Outcome inferred before external verification |
| User correction | Current preference plus supersession of the old value | Sensitive attributes without consent or a business need |
| Repeated pattern | High-confidence workflow insight after multiple observations | One-off behavior generalized into a permanent rule |
The write policy should require durability, utility and appropriate sensitivity. “User chose dark mode” may be durable. “User is currently angry” is ephemeral and potentially harmful. “Transfer completed” must be verified against the transaction system, not inferred from an agent’s final sentence.
Intelligent recall and “tokenless” language
Memori material emphasizes targeted, agent-controlled recall and avoiding large prompt dumps. The practical meaning is not that memory has literally zero token cost: any text ultimately inserted into an LLM context consumes tokens. Rather, the agent can call a recall tool only when useful, and retrieval can return a compact result instead of continuously injecting the full history. Storage, enrichment, embeddings and tool calls still have compute and monetary cost.
| Recall control | Benefit | Failure to test |
|---|---|---|
| Entity/project/session filters | Prevent irrelevant and cross-tenant context | Missing or spoofed scope identifiers |
| Semantic relevance | Finds meaning beyond exact keywords | Plausible but unrelated matches |
| Recency and decay | Deprioritizes old observations | Old but critical facts disappearing |
| Source/signal weighting | Favors verified outcomes over casual mentions | Uncalibrated confidence becoming authority |
| Agent-controlled recall | Avoids constant prompt injection | The agent forgets to call the tool at a critical step |
| Summary recall | Provides compact orientation | Compression drops exceptions and provenance |
How to interpret the benchmark claim
Memori reports 81.95% accuracy on LoCoMo with 1,294 tokens per query and describes that context as roughly five percent of a full-context approach, implying up to 95.03% inference savings in the tested setup. LoCoMo evaluates long-conversation memory questions, so it is relevant to conversational recall. The product’s trace-derived positioning extends beyond what that benchmark alone proves.
Before adopting the numbers, inspect the repository’s benchmark code, dataset version, judge, model, baselines, token counting and number of runs. Separate retrieval accuracy from final-answer accuracy. Cost claims should include augmentation, embedding, storage, recall calls and retries—not only tokens in the final answer prompt. A vendor benchmark is useful reproducible evidence, but it is not an SLA or proof of performance on your schemas and languages.
| Claim | What it supports | Additional proof needed |
|---|---|---|
| LoCoMo answer accuracy | Performance on a public long-conversation task | Your domain questions, users, languages and correction patterns |
| 1,294 tokens/query | Compact context in the reported configuration | Total write + retrieval + answer cost at production volume |
| Trace-derived memory | Richer inputs than conversation alone | Ablation showing which trace fields improve your tasks |
| Asynchronous building | Potentially avoids response-path latency | Freshness lag, queue failure and read-after-write behavior |
| Scoped isolation | Designed tenant/project boundaries | Adversarial authorization and identifier tests |
BYODB versus Memori Cloud
| Deployment | Advantages | Responsibilities / questions |
|---|---|---|
| Open source + own database | Storage control, existing governance, portability and local customization | Operate schema, models, embeddings, migrations, backups, observability and scaling |
| BYODB with hosted capabilities | Keep primary data in chosen database while using managed augmentation/operations | Map exactly what content/metadata leaves the database and where processing occurs |
| Memori Cloud | Faster setup, managed API, dashboard, quota and operational visibility | Verify live pricing, tenancy, subprocessors, region, retention, export, deletion and uptime |
“Bring your own database” does not necessarily mean “all processing stays inside your network.” Obtain a data-flow diagram covering raw traces, extracted memory, embeddings, telemetry and support access. If personal data is stored, map access/deletion requests to every derived copy, vector, cache, backup and exported trace.
Memory security and privacy threat model
| Threat | Example | Required control |
|---|---|---|
| Cross-tenant bleed | A recall query omits project scope and returns another customer’s fact | Server-side authorization, non-optional tenant keys and isolation tests |
| Memory poisoning | Untrusted document/tool output tells future agents to reveal secrets | Source trust labels, sanitization, approval and instruction/data separation |
| Sensitive inference | Repeated behavior is consolidated into health, finance or identity claims | Data minimization, excluded classes, consent and short retention |
| Stale authority | An old address or policy is recalled after correction | Versioning, canonical state, supersession and freshness checks |
| Deletion gap | Row deleted but embedding, trace or backup remains retrievable | End-to-end deletion verification and documented backup expiry |
| Prompt disclosure | Agent repeats private memory to an unauthorized user | Permission-aware retrieval plus output policy; never rely on the model alone |
A production-ready memory contract
Define a contract before enabling automatic capture. Every memory should have an owner, tenant/entity, project/process, type, source pointer, created time, confidence, sensitivity, expiry, lifecycle status and deletion identifier. The contract should state which types are never stored, which require user consent, which can be recalled automatically and which must be fetched from an authoritative system.
allowed: preferences, verified outcomes, reusable task procedures denied: credentials, raw payment/health records, hidden system prompts authority: application DB > verified user correction > tool outcome > model inference recall: tenant + project required; source and timestamp returned lifecycle: proposed -> active -> superseded/expired/deleted deletion: memory + embedding + cache + trace pointer + backup schedule
A four-week evaluation plan
- Week 1—baseline. Collect 50 real questions across recent facts, old facts, corrections, multi-session outcomes and “no memory exists” cases. Measure full-history and simple vector-RAG baselines.
- Week 2—write quality. Run representative traces, label which observations should become memory and calculate extraction precision/recall, sensitive-data leakage and freshness delay.
- Week 3—recall quality. Test filters, ranking, decay, citations, contradictions, multilingual queries and adversarial tenant IDs. Record relevant-context precision before measuring final answers.
- Week 4—operations. Load-test writes/recalls, stop the augmentation worker, rotate credentials, restore a backup, export data and execute full deletion. Price the actual workload.
| Metric | Definition | Suggested starting gate |
|---|---|---|
| Write precision | Useful, accurate durable memories / all created | ≥90% |
| Write recall | Gold durable observations captured / all gold observations | ≥85% |
| Recall precision@k | Relevant returned memories / k | ≥80% at the context actually injected |
| Unsupported-memory rate | Recalled claims lacking valid source / recalls | <2% |
| Cross-scope leakage | Unauthorized tenant/project items returned | 0 in adversarial suite |
| Correction success | Queries returning current canonical fact after correction | 100% for critical test fields |
| Deletion completion | Derived surfaces no longer retrievable within policy window | 100% |
| Total cost/task | Write, models, embeddings, storage, recall and answer | Below measured value saved |
Thresholds should be tightened for regulated or high-impact uses. Also measure abstention: a good system must say “no reliable memory found” rather than retrieving a semantically similar fiction.
Alternatives
| Alternative | Choose when | Key comparison |
|---|---|---|
| Mem0 | You want a widely integrated general memory API and managed/open paths | Compare extraction schema, graph support, scoping, benchmarks and hosted data flow |
| Zep / Graphiti | Temporal knowledge graphs and entity relationships are primary | Compare temporal invalidation, graph operations and trace ingestion |
| Letta | Memory management should be part of a stateful agent runtime | Different abstraction: agent orchestration plus tiered memory |
| LangGraph persistence | You need explicit workflow checkpoints and state you model yourself | More deterministic state; less automatic semantic memory extraction |
| Postgres/pgvector custom layer | Your schema, security or cost requirements justify ownership | Maximum control, maximum evaluation and maintenance burden |
| Plain profile/ADR tables | Memory needs are small, explicit and high consequence | Often safer and cheaper than probabilistic extraction |
FAQ
Does Memori replace a vector database?
No. It is a memory lifecycle and integration layer that can use storage and retrieval infrastructure. The important added work is attribution, structuring, ranking, lineage and augmentation.
Does it only learn from chat?
No. Its current positioning explicitly includes agent execution trace, tool activity, workflow decisions, outcomes and failures alongside conversation.
Is recall really token-free?
On-demand tool recall can avoid always injecting memory, but returned text used by an LLM consumes context tokens. Include retrieval and memory-building costs in the total.
Can Memori store authoritative business state?
It can store context about it, but critical current state should remain in the authoritative application database and be verified at action time.
How should corrections work?
Keep lineage, mark the newer verified value canonical, suppress the old value from ordinary recall and retain history only as policy permits.
Who should adopt Memori first?
Teams with long-running, multi-user agents whose measurable failures come from lost execution context—and that can operate a serious privacy and evaluation program.
Sources and verification
- Official Memori product site
- Official open-source repository
- Official BYODB architecture documentation
- Official agent-trace overview and demo
- Official benchmark page
- Benchmark code and materials in the official repository
- Memori technical paper
- Product Hunt launch and maker explanations
- OWASP LLM application security guidance
Last reviewed July 26, 2026. Architecture, cloud plans, benchmark results and integrations can change. Verify current documentation, terms and code before production use.
