Memori - Persistent memory from agent trace, not just conversation
Memori launched its new agent-native memory infrastructure, enabling agents to create structured, long-term memory directly from agent trace — including execution paths, tool results, workflow steps, outcomes, and decision-making logic. This allows memory to also be generated from what an agent actually does.
Benchmark results: 81.95% accuracy on LoCoMo using only 1,294 tokens per query, roughly 5% of full-context cost, saving users 95%+ on inference spend. 15K GitHub stars, 200000+ downloads
Replies
See how Memori works: https://memorilabs.ai/benchmark/#demo
Select a task and watch both agents in real time: https://memorilabs.ai/agent-trace/#demo
While most customer facing AI agents are limited by short-term memory constraints, Memori brings the long-term persistent memory and unlike traditional memory systems that rely primarily on long-form natural language conversation history, Memori enables agents to automatically create structured, long-term memory directly from the agent trace — including execution paths, tool results, workflow steps, outcomes, and decision-making logic.
- Structured, persistent memory for AI agents — Memori replaces flat markdown memory files with a structured knowledge graph that captures facts, decisions, outcomes, and patterns across every session — without bloating the prompt.
- Grounded in what agents actually do, not just what they say — Memori captures tool calls, execution traces, and real-time agent decisions alongside conversation, giving agents a fuller picture of prior task execution.
- Agent-controlled intelligent recall — Agents decide when and what to retrieve, scoped precisely by project, session, entity, or time range — eliminating irrelevant context and cross-project noise.
- Automatic memory building, zero latency impact — Memory is structured and updated asynchronously after each interaction, so it never slows the agent's response.
- Smarter daily briefs — Memori generates structured daily briefings built from execution traces and structured memory — covering priorities, risks, active goals, open loops, and known failure patterns — far beyond a simple conversation recap.
- Built for multi-user, multi-project environments — Memory is fully scoped and isolated by project, process, session, and entity, preventing data bleed across users and contexts.
- Production-ready observability — Full visibility into memory creation, recall activity, retrieval performance, and quota usage via Memori Cloud.
@memorilabs Congrats on the launch guys. How do you carve out the useful data from std tool use noise?
@zolani_matebese - great question. We don’t treat every tool call as memory.
The way Memori handles this is by using tool use as signal, not as the memory itself. We structure the agent trace, then filter for durable, reusable context: decisions, user preferences, constraints, workflow outcomes, repeated failures, successful resolutions, and important state changes.
Generic tool noise - routine API calls, retries, intermediate steps, transient logs, HEARTBEAT_OK messages, gets ignored or down-weighted. Then we dedupe, merge, scope by entity/project/session, and apply relevance/decay so only useful context is recalled later.
So the goal is not “store the trace.” The goal is to extract the few memory primitives from the trace that make the next agent run smarter.
Flowtica Scribe
The memory layer design is genuinely artistic.
Instead of treating memory as compressed chat history, @Memori turns agent execution traces into reusable state: what tools were called, what worked, what failed, what decisions were made, and what patterns should carry forward.
That is a much stronger memory primitive for agents. Real agent context lives in the execution path, not just in the conversation around it.
Kudos to @_gordee @adam_b_struck @memorilabs and the team!
15K GitHub stars and rising — well deserved!
mailX by mailwarm
How does Memori handle memory updates when the agent learns something new that contradicts an older trace?
@othman_katim - great question. Memori doesn’t blindly overwrite older traces. We treat memory as a structured, versioned layer with source, signal, timestamp, and relevance metadata. Based on this multi-dimensional meta data, each memory is on its own unique decay curve.
When an agent learns something new that contradicts an older trace, Memori can preserve the older trace for audit/history while updating the active/canonical memory that gets recalled going forward. In practice, newer or higher-confidence memories are weighted more heavily, and older contradictory memories decay or are suppressed unless they are specifically relevant to the task.
Simple example: if an agent previously learned “the dashboard is red” but later the user corrects it to “the dashboard is blue,” Memori keeps the historical context but recalls “blue” as the current truth. That’s the key difference between raw chat history and agent-native memory — we’re managing durable state, not just stuffing old context back into the prompt.
The trace-based memory model is architecturally clever. Capturing tool calls, decisions, and outcomes from execution rather than compressing conversation history preserves the why behind agent behavior, not just the what. We've hit this ceiling building stateful agent workflows; chat summaries lose causal context fast. How do you handle storage and retrieval at scale when agent runs produce deeply nested execution graphs?
@anand_thakkar1 Great question, Anand. We don’t treat the full execution graph as the memory object. At scale, you need to separate trace capture from memory creation.
We ingest the agent trace asynchronously, normalize tool calls / decisions / outcomes into structured events, then score what is actually memory-worthy. From there we persist durable primitives with metadata like entity, project, session, source, signal, timestamp, and outcome - while keeping the raw trace available for audit/debugging.
On retrieval, we avoid replaying or summarizing the whole graph. We use scoped filters plus intelligent ranking across semantic relevance, recency, frequency, source/signal weight, and decay so the agent gets the smallest useful context back at the right time.
So the core idea is: deeply nested traces are useful input, but the production memory layer should store the durable causal learnings, not the entire execution graph as context.
Bolty
Thank you so much for your support, @bryce_murray
Interesting one @memorilabs @adam_b_struck @_gordee ! Upvoted :)
What's the memory an agent gets from the trace, that would be useful for another session?
Like I have set up a rule in Claude.md asking the agent to keep adding new learnings (during the session) into a project level .md file. How would your tool be different from that?
@aiswarya_s Thank you for your support and good question.
CLAUDE.md is a file you write and maintain by hand. Nothing from a session persists unless you remembered to document it.
The agent doesn't write back. Decisions, tradeoffs, and discovered context from each session disappear when it ends. If your md file grows beyond the file size limit, it gets compacted away mid-task.
Preferences and patterns from one codebase don't carry to the next. Every project starts from scratch.
Code style, testing frameworks, and tooling preferences have to be re-established each session rather than recalled.
We'd love to hear your thoughts on https://memorilabs.ai/integrations/claude-code
We’ve been noticing that “memory” for agents usually breaks once workflows become long-running or tool-heavy. The agent trace angle here is interesting because conversation history alone definitely isn’t enough anymore.
How are you guys handling memory cleanup / forgetting over time?
Thank you for your support and good question @zaid_mallik1
We handle memory primarily through a system where context is weighted by relevant and importance.
This includes intelligent decay so older and less relevant facts naturally get deprioritized, ensuring the mist vital memories stay in focus. Our system uses these to manage the rolling context window effectively.
We treat memory as a structured, versioned layer with source, signal, timestamp, and relevance metadata. Based on this multi-dimensional meta data, each memory is on its own unique decay curve.
When an agent learns something new that contradicts an older trace, Memori can preserve the older trace for audit/history while updating the active/canonical memory that gets recalled going forward. In practice, newer or higher-confidence memories are weighted more heavily, and older contradictory memories decay or are suppressed unless they are specifically relevant to the task.
Simple example: if an agent previously learned “the dashboard is red” but later the user corrects it to “the dashboard is blue,” Memori keeps the historical context but recalls “blue” as the current truth. That’s the key difference between raw chat history and agent-native memory — we’re managing durable state, not just stuffing old context back into the prompt.
Cool! Can you also store and remember the sequence of actions in a multi-agent system?
AISA AI Skills Test
the trace-based approach is smart. most agent memory systems just store conversation turns, which loses all the decision logic and tool outputs that actually matter for improving performance over time. curious how you handle conflicting memories when the same agent runs different strategies on similar tasks?
Thank you for your support and good question @ozandag
We handle memory primarily through a system where context is weighted by relevant and importance.
When an agent learns something new that contradicts an older trace, Memori can preserve the older trace for audit/history while updating the active/canonical memory that gets recalled going forward. In practice, newer or higher-confidence memories are weighted more heavily, and older contradictory memories decay or are suppressed unless they are specifically relevant to the task.
As an example: if an agent previously learned “the dashboard is red” but later the user corrects it to “the dashboard is blue,” Memori keeps the historical context but recalls “blue” as the current truth. That’s the key difference between raw chat history and agent-native memory — we’re managing durable state, not just stuffing old context back into the prompt.
The "memory from execution trace, not just conversation" framing is exactly the right primitive for agents that actually do things vs just talk. Quick question: when a tool call returns a large blob (say a 10MB SQL result), how does Memori decide what to keep in long-term memory vs discard? Curious about the pruning side.
Thank you for your support and good question, @mythic_dd
We handle memory primarily through a system where context is weighted by relevant and importance.
This includes intelligent decay so older and less relevant facts naturally get deprioritized, ensuring the mist vital memories stay in focus. Our system uses these to manage the rolling context window effectively.
We treat memory as a structured, versioned layer with source, signal, timestamp, and relevance metadata. Based on this multi-dimensional meta data, each memory is on its own unique decay curve.
When an agent learns something new that contradicts an older trace, Memori can preserve the older trace for audit/history while updating the active/canonical memory that gets recalled going forward. In practice, newer or higher-confidence memories are weighted more heavily, and older contradictory memories decay or are suppressed unless they are specifically relevant to the task.
Simple example: if an agent previously learned “the dashboard is red” but later the user corrects it to “the dashboard is blue,” Memori keeps the historical context but recalls “blue” as the current truth. That’s the key difference between raw chat history and agent-native memory — we’re managing durable state, not just stuffing old context back into the prompt.
@memorilabs That's the right mental model - durable state with version history vs prompt stuffing. The audit trail piece is interesting: when the agent retrieves memory, does it see only the canonical "blue" or can it also see the prior "red" plus the correction event?
Asking because the answer changes a lot of downstream design - whether the agent needs to reason about its own past mistakes, or just acts on current truth.