Launched this week
Memori
Persistent memory from agent trace, not just conversation
194 followers
Persistent memory from agent trace, not just conversation
194 followers
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
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.
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.
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
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.
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.