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
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
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.
This is the right direction for agent memory. I like that you're deriving it from traces and tool outcomes instead of only chat history. The real test I'd be curious about is how teams inspect and prune memories when workflows change.
Most memory tools I've tried feel like souped-up sticky notes — you're essentially just saving conversation snippets and hoping the right one surfaces later. What's different here is that the memory is structural, not textual. It knows WHY a decision was made, not just that it was made. My practical question: how does this behave when an agent makes a wrong decision and you want to correct it? Does a bad execution trace get weighted down over time, or does it stick around and keep influencing future behaviour?