Memori: Structured Agent Memory That Hooks Into the LLM Calls You Already Make
Memori is agent-native memory infrastructure. A LLM-agnostic layer that turns agent execution and conversation into structured, persistent state for production systems. Built for enterprise, Memori works with the data infrastructure you already run, no rip-and-replace, and deploys across managed cloud, single-tenant cloud, VPC, and on-premises.
At a glance
- What is it?
- Memori is an LLM-agnostic memory layer that captures agent conversations and execution as structured state. It works through SDKs for Python and TypeScript, with plugins for OpenClaw and Hermes, and claims strong benchmark results on the LoCoMo test.
- Who is it for?
- Adopt Memori if you run agents in Python or TypeScript and want persistent memory without rewriting your LLM calls or swapping your datastore. Skip it if you need full control over memory extraction logic or if your stack is outside the supported SDKs and plugins.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Agents Forget Everything Between Turns
Most agents are stateless by default. Each conversation starts from scratch, or you stuff the entire history into the prompt to give the model context. That approach is expensive and fragile. Memori addresses this by turning agent execution and conversation into structured, persistent state. The pitch is that memory comes from what agents do, not just what they say. Tool calls, decisions, and outcomes become part of the stored state. The intended users are teams building production agents who want memory without re-architecting their existing LLM calls or their data layer.
How It Works: Background Capture and Recall via SDK Wrappers
The core mechanism is a wrapper around the LLM client. In the TypeScript SDK, you create an OpenAI client, then register it with Memori: `new Memori().llm.register(client)`. From that point, every `chat.completions.create` call is intercepted. The conversation is persisted and recalled automatically in the background. The same pattern applies in Python: `mem = Memori().llm.register(client)`. You do not change the messages you send. The README shows that after telling the model a favorite color, a later query about that color gets the right answer because Memori injects the relevant memory. Attribution is explicit: you set an entity ID and a process ID, like `user_123` and `support_agent`, so memory is scoped to a specific user and a specific agent process. This is not a vector database bolted onto your app. It is a layer that sits between your code and the LLM provider.
Getting Running: Cloud-First, BYODB Later
The fastest path is Memori Cloud. You sign up at app.memorilabs.ai, get an API key, and set two environment variables: `MEMORI_API_KEY` and your LLM key such as `OPENAI_API_KEY`. Then you install the SDK. For Python: `pip install memori`. For TypeScript: `npm install @memorilabs/memori`. The quickstart code is short. In Python, you create an OpenAI client, register it, set attribution, and then make normal chat calls. The same flow exists in TypeScript. There is a dashboard for exploring memories, analytics, and API keys. If you do not want the managed cloud, the README points to a BYODB option where you bring your own database. It mentions TiDB Zero as a disposable development database and links to docs for that path. The cloud route is zero config; the BYODB route is not described in the README beyond the pointer.
The LoCoMo Benchmark: Strong Claims, Limited Detail
The README reports that Memori scored 87% overall accuracy on the LoCoMo benchmark for long-conversation memory, using an average of 721 tokens per query. That is 2.8% of the full-context footprint. It also claims to outperform Zep, LangMem, and Mem0 while reducing prompt size by roughly 67% versus Zep and lowering context cost by more than 36x versus full-context prompting. These are specific numbers, but the README does not describe the evaluation methodology, the exact LoCoMo subset, or how the comparison systems were configured. A benchmark against a competitor depends heavily on prompt design and retrieval settings. Treat the 87% as a reported result, not a guarantee. The paper is linked on arXiv, so you can check the details before relying on it.
Plugins for OpenClaw and Hermes: Memory Without Code Changes
Beyond the SDKs, Memori ships as a plugin for OpenClaw and a memory provider for Hermes. For OpenClaw, the plugin captures structured memory after each turn, including tool calls and outcomes, with no changes to agent code or prompts. Installation is command-driven: `openclaw plugins install @memorilabs/openclaw-memori`, then enable it, run `openclaw memori init` with your API key and entity ID, and restart the gateway. For Hermes, you install `hermes-memori`, run `hermes-memori install`, set the provider with `hermes config set memory.provider memori`, and add environment variables to the Hermes home directory. Hermes gets explicit `memori_recall` and `memori_recall_summary` tools, giving the agent controlled recall rather than automatic injection. This is a different model from the SDK wrapper, where recall is automatic. The plugin approach is valuable if you already run those gateways, but it also means you are tied to the plugin's lifecycle and update cadence.
Limitations and Failure Modes
The biggest limitation is that Memori only works where the SDK or plugin integrates. If you use a framework that is not OpenAI-compatible or a language outside Python and TypeScript, you are out of luck. The README shows only OpenAI client registration. No other provider is demonstrated. Another concern is attribution. You must remember to set `entity_id` and `process_id` correctly. If you forget, memory could leak across users or processes. The background capture is automatic, which is convenient but also opaque. You cannot easily see what is being stored or when. The README offers a dashboard, but the details of memory editing or deletion are not covered. For a production system, you need to know how to correct a wrong memory or purge sensitive data. The BYODB option exists, but the README gives no configuration keys or schema. You must go to external docs. Finally, the license metadata says NOASSERTION on GitHub, even though the badge shows Apache 2.0. That discrepancy is worth resolving before adoption.
Alternatives: Full-Context Prompting and Retrieval Systems
The obvious alternative is what Memori is trying to replace: full-context prompting. You keep the entire conversation history and pass it with every request. That works for short sessions and gives the model perfect recall, but token costs grow linearly and eventually exceed context windows. The benchmark claims Memori cuts that cost by over 36x. Another alternative is a retrieval-based memory system like Zep, LangMem, or Mem0, all named in the README as systems Memori outperforms. Those systems typically embed conversation chunks and retrieve them by similarity. Memori's difference is that it stores structured state, not just raw text. That means it can capture tool calls and outcomes as first-class data. The trade-off is complexity. A retrieval system is simpler to reason about: store text, find text. Memori's structured approach may require more setup and a clearer model of what entities and processes mean in your domain.
Maintenance, Upgrades, and License Reality
The repository shows active releases, with v3.3.6 from May 2026 and several patch releases in the same month. That suggests a maintained project, but the README does not describe a migration path between versions. For a memory layer, version changes can affect how stored memories are interpreted. You should plan to test upgrades against your existing memory data. The license badge in the README points to Apache 2.0, but the GitHub metadata says NOASSERTION. That means the repository owner has not asserted a license in the machine-readable field. If you are building a commercial product, confirm the license in the actual LICENSE file before you rely on the badge. The project is not archived and has recent pushes, so it is alive, but the discrepancy is a red flag for governance.
Editorial conclusion
Adopt Memori if you run agents in Python or TypeScript and want persistent memory without rewriting your LLM calls or swapping your datastore. Skip it if you need full control over memory extraction logic or if your stack is outside the supported SDKs and plugins. Before committing, verify the benchmark claims against your own workload, confirm the Apache 2.0 license status given the NOASSERTION metadata, and test the BYODB path with your actual database, since the README only sketches that option.
Community notes