Memori: The Memory Layer That Turns LLM Calls Into Durable Agent State
A zero-config interceptor, SQL-native storage, and entity-process attribution give AI agents something most still lack: a real memory system that survives sessions without bloating the prompt.
- Memori argues that agent memory should behave like operational state, not a searchable archive of old chats.
- Its interceptor pattern is the real product move because it adds memory without forcing a framework rewrite.
- Entity, process, and session attribution keep memories from bleeding across users and workflows.
- The project’s benchmark story is about token efficiency, not bigger prompts.
Memori is most interesting when you stop thinking about it as a memory store. It is a request-path layer that watches an LLM call, retrieves the right state, injects it, then writes back what changed. That is a different mental model from dumping chat history into a vector database and hoping retrieval saves you.
The memory layer hiding inside your LLM client
The first surprise is practical. Memori does not ask you to rebuild around a new agent framework. You register an existing client, and the interceptor handles the rest. In the repo, that means wrappers around providers like OpenAI, Anthropic, LangChain, and similar clients, so memory becomes a property of the call rather than a new application architecture.
Memori is agent-native memory infrastructure. A SQL-native, LLM-agnostic layer that turns agent execution and conversation into structured, persistent state for production systems.
The important shift is that memory is not bolted on after generation. It is part of the invocation lifecycle. Memori observes the call, selects relevant memories, augments the prompt, and then updates storage in the background. That makes it feel closer to a transaction log for agents than a chat archive.
Why memory from action is the real differentiator
Memori’s philosophy is blunt: agents do not just say things, they do things. The repo’s memory model reflects that. It tracks entities, processes, events, facts, preferences, relationships, rules, and skills, which makes the resulting state feel operational rather than conversational.
import memori
client = openai.OpenAI()
mem = memori.Memori()
mem.attribution(entity_id="user_123", process_id="support_agent")
mem.llm.register(client)
response = client.chat.completions.create(
model="gpt-4.1",
messages=[{"role": "user", "content": "What did we decide last time?"}]
)
That tiny wrapper hides the bigger idea. The system separates who the memory belongs to from which workflow produced it. That is what keeps one customer’s preferences from leaking into another customer’s session, and one agent role from contaminating another.
Entity, process, session: the identity model that keeps memory from bleeding
| Layer | What it represents | Why it matters |
|---|---|---|
| Entity | The person or account | Keeps user-specific memory stable across workflows |
| Process | The agent role or workflow | Lets one system hold distinct memory for different jobs |
| Session | The temporary interaction window | Captures short-lived context without promoting it to durable state |
This is the part many memory systems flatten. Memori makes identity first-class. That matters in production because a support agent, a research agent, and a sales agent do not need the same history, even when they share infrastructure.
How Memori actually stores and recalls memory
Under the hood, the flow is straightforward enough to trust and opinionated enough to matter. A request enters the wrapper, Memori selects relevant memory, augments the prompt, and the response returns through the same path. Streaming support is important here, because token-by-token output is where a lot of memory systems get clumsy. Memori has to merge chunks cleanly before it can capture the final result.
Request -> Interceptor -> Recall -> Augment prompt -> LLM response
\-> Stream merge -> Background writeback -> SQL storage| Approach | Strength | Tradeoff |
|---|---|---|
| Memori | Structured state with interception | More opinionated than flat retrieval |
| Vector-first memory | Simple semantic search over past text | Can miss workflow and identity boundaries |
| Big context window | Easy to understand | Costs more and still wastes tokens |
| Framework-native memory | Convenient inside one ecosystem | Often too limited for production state |
Memori is not trying to win by stuffing more history into the prompt. It is trying to remember less, better.
Why the benchmark matters more than the star count
| System | What it optimizes for | What the benchmark story suggests |
|---|---|---|
| Memori | Structured memory and token efficiency | Strong accuracy without a full-context burden |
| Zep | Long-term retrieval | Useful, but more retrieval-centered |
| Mem0 | Agent memory convenience | Competitive, but not as state-first |
| LangMem | Ecosystem fit | Better as a helper than a storage layer |
The benchmark result matters because it supports the design thesis. If a system can hit strong recall while using a small fraction of the full context footprint, that is a signal that structured state can beat brute-force prompting. The argument is not that bigger windows are bad. It is that they are the wrong default for durable agent memory.
Cloud mode or BYODB: the trust story for teams
Memori’s deployment story is split in two. Cloud mode gives you a managed path. BYODB gives you control over the database layer, which is the option teams want when privacy, compliance, or procurement slows everything down. That choice is not a side note. It is part of the product’s enterprise pitch.
| Mode | Best for | Main concern |
|---|---|---|
| Cloud | Fast setup and managed ops | Data handling lives outside your own stack |
| BYODB | Teams that need sovereignty | You own the database and operational surface |
That dual path makes the architecture easier to adopt. A team can start with the managed service, then move the memory store into its own SQL infrastructure once the integration proves itself.
Where Memori fits in the memory stack
| Project | Primary emphasis | How Memori differs |
|---|---|---|
| Memori | Structured, SQL-native agent state | Hooks into existing clients and separates identity from workflow |
| Mem0 | General agent memory | Less centered on call interception and SQL-native state |
| Zep | Long-term memory store | More retrieval-oriented than process-aware |
| LangMem | Framework utilities | Useful inside the ecosystem, but narrower in scope |
| Native framework memory | Simple session memory | Usually too shallow for durable production state |
So the cleanest way to place Memori is this: it is not just memory retrieval, and it is not just persistence. It is an operational state layer for agents that have to survive across sessions without losing their thread.
The tradeoff Memori is making
The cost of the approach is real. Structured memory is more opinionated than flat search, which means you have to accept its model of identity and state. Interception is elegant, but it also lives in a sensitive part of the request path. That is the right place for serious agent infrastructure, and the wrong place for casual chat logging.
If all you want is a simple archive of conversations, Memori is probably more machinery than you need. If you are building production agents that need durable, queryable, token-efficient state, the design starts to look less like a feature and more like the missing layer.
