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!
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.
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.
Bolty
Thank you so much for your support, @bryce_murray
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.
@memorilabs Really appreciate the detailed breakdown.
We have also worked on our memory layers using temporal memories .
One thing we kept running into when experimenting with agent memory was temporal context — not just what was remembered, but when and under what circumstances it was learned. A lot of contradictory state seemed to come from memories that were technically correct at one point but no longer reflected reality.
How are you handling temporal memories and state changes over time? Is that something your weighting/decay system captures, or do you treat it as a separate layer?
@zaid_mallik1 Great question - we think temporal context is one of the core reasons agent memory cannot just be “vector search over old facts.”
At Memori, we treat this as both a weighting/decay problem and a state-management problem.
Decay helps determine how much influence an older memory should have during recall, but decay alone is not enough. A memory can be perfectly true at the time it was created and still be wrong today. So we also attach temporal and contextual metadata around memories: when it was learned, where it came from, what entity/project/session it related to, and the source/signal behind it.
The important part is that newer state can supersede older state rather than simply coexist with it. So if an agent learns “the user prefers X” and later learns “the user now prefers Y,” the system should not blindly retrieve both as equivalent facts. The older memory can still exist as historical context, but recall should privilege the current/canonical state unless the agent is explicitly asking about prior history.
That is also why we care so much about memory from agent trace, not just conversation. The “when” and “under what circumstances” often come from execution context: tool calls, workflow steps, decisions, failures, confirmations, and outcomes.
So our view is:
Decay / weighting handles relevance over time.
Temporal metadata captures when and where the memory was learned.
State updates / supersession help prevent stale-but-once-true memories from corrupting current context.
Recall filters and ranking determine whether the agent needs current state, historical context, or both.
That distinction is critical for production agents. Otherwise memory becomes noisy very quickly.
Cool! Can you also store and remember the sequence of actions in a multi-agent system?
AISA (aisa.to) AI Fluency Assessment
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.
Persistent memory from trace (not conversation) is exactly the right framing — agents that 'forget' why they made a choice are nearly useless in any audit-sensitive workflow. Curious how Memori handles the case where two traces contradict each other and the agent needs to pick a winning version. This is structurally the same problem in financial modeling — I built ModeLoop in part because assumption drift between model versions is brutal in deal work, and 'why did we change this number' is the question that gets asked three months later when nobody remembers.
Thank you for your support and good question @samir_asadov
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.
We built something similar at Tuple — agents that retained outcome data from past campaigns, not just conversation history. The behavioral difference was significant. An agent that recalls "this pain framing outperformed in healthcare verticals three campaigns ago" behaves fundamentally differently than one starting cold each run. The hard part we kept hitting: structuring trace data so retrieval stays signal-dense, not verbose. The LoCoMo benchmark showing 5% of context cost is the number that matters for production deployments. Watching this closely.
Thank you so much for your support, @thekrew
You're absolutely right it's important to structure memories from agent trace and execution in addition to long conversation is essential with the rise of AI agents.
It’s great to hear that the LoCoMo benchmark resonated with you. We agree that efficiency and context cost are the primary hurdles for scaling these deployments in the real world.
We'd love for you to see how Memori works as it retrieves memories, creates session summaries and hear your thoughts: https://memorilabs.ai/benchmark/#demo
Agents that learn from mistakes demo: https://memorilabs.ai/agent-trace/#demo