SenseLab vs Memory

A memory layer stores what an agent saw and said, and hands it back the next time something similar comes up. That solves forgetting. It does not touch the problem that comes right after: the agent acted on what it was handed, and nobody recorded whether that worked. SenseLab is not a memory layer. It is a recursive self-improvement engine for agents, and memory is only where it starts. Everything on this page follows from one difference: a memory layer’s loop is open, and SenseLab’s is closed. This page covers the memory layers — Mem0, Zep / Graphiti and Letta. For the observability and evaluation stack, where an engineer fixes the prompt between releases, see SenseLab vs Observability.

---

​

Memory stops where the work begins

Store, retrieve, stop. A memory layer improves what the model reads, and that is the whole job: extract what matters from a conversation, index it, return the closest matches next time. The agent then acts on what it was shown, and whatever happens next — the deploy that rolled back, the customer who wrote in again, the runbook step that no longer exists — never reaches the store. That is fine while the world holds still. It breaks the moment a rule changes under the agent, which in production is constantly: a price, a policy, an API field, a step in a runbook. The store has no way to know. It keeps serving the old rule with exactly the confidence it had when the rule was right, and it does so to every agent that asks, because similarity has no opinion about whether a thing is still true. The result is worse than forgetting. In our benchmark, after the rules changed, memory without an outcome loop applied the stale fix on twice as many first attempts as an agent with no memory at all — and it did so with full confidence, because the store kept ranking it first.

---

​

What closes the loop

SenseLab runs three loops on one record, and each loop’s output is the next loop’s input. That arrangement, not the store, is what makes the improvement recursive. The fast loop: outcomes decide what agents act on. Before a task, the agent is briefed on what is already known about the entity — what has held up, what has been discredited, what started failing this week, and which action has the best record here. After the task, it reports how things ended, and that result is credited to the exact entries and actions the run relied on. Confidence moves; every entry carries a label the next briefing reads — validated, contested, discredited — and a rule with a long record that suddenly fails is flagged as a regime shift. A memory layer ranks by similarity. SenseLab ranks by evidence. The repair loop: the engine writes its own corrections and proves them. Judges grade every production run. A failure that keeps recurring becomes a named behavior and opens an incident, segmented by model, agent version and tool. The fix to the learning is drafted on a branch no agent can see, replayed against the runs that failed and the runs that passed, optionally canaried on live traffic against a control, shipped, and verified a week later — and rolled back on its own if it did not hold. On a memory layer, the answer to a bad run is that the same memory comes back next time and someone edits a prompt. The model loop: the record becomes your model. Every run leaves a sealed trace — what was asked, what the agent read and at what confidence, what it did, how it ended. That is a labelled training example nobody annotated. Once there are enough, SenseLab trains a model on your own validated decisions, scores it on a holdout of your own history, and serves it with the same memory the frontier agent used, so its own traces train the one after it. A memory layer improves what the model reads. It never touches the model. No human edits a prompt or a store for any of this to happen. The system that fixes the agent produces the data that trains the agent.

---

​

The same rule change, on memory and on SenseLab

Here is the difference as it plays out. An agent fleet has learned that a particular fix works. Then the rule behind it changes.

---

​

What we measured

A feature list says what a system has. We also measured what the loop is worth, on a benchmark built to resemble production: tasks that are new every time, domains with hidden quirks where the textbook answer is wrong, a rule change at episode 20 that turns a learned fix into a wrong one, fleets of six agents on one shared store, and newcomers joining mid-stream. Six scenarios, two frontier models, about 35,000 agent episodes. The arms were no memory, Mem0’s hosted memory with its feedback API called on every retrieved memory at outcome time, and SenseLab. Three things in that table matter for a buyer:

• Memory alone stops helping when the rules change. After the change, Mem0 and no memory both sit at 0.38, and Mem0 applies the stale fix on twice as many first attempts as the agent with no memory — the store is doing its job on a rule that is no longer true, with the same confidence it had when it was right.
• SenseLab recovers. On the changed tasks SenseLab goes from 0.36 to 0.69 first-attempt success over the forty episodes after the change — 28 points over Mem0 in the last twenty, with a third fewer escalations. It halves its own stale-pick rate over those episodes; nobody else’s moves.
• The recovery is inherited. A fleet of six sharing one store matches the single agent. A newcomer that arrives after the change solves 0.62 of its first exposures on a SenseLab store against 0.22 on Mem0, because the store it inherits has already discredited the old fix and named what replaced it. Followers joining a pioneer are productive from their first task — 0.84 against 0.67 — because they are reading notes that twenty outcomes have confirmed or discredited.

Zep and Letta were not in this benchmark. Mem0’s flat pre-change curve is a finding about its fit to this workload — operational lessons needed on the very next task, rather than facts about a user accumulated across conversations — and not about memory in general. Source: SenseLab Research, From memory to recursive self-improvement, preprint, September 2026.

---

​

Where each memory layer stops

Mem0 and Zep are retrieval layers: they improve what the model reads. Letta is an agent runtime with git-backed memory. None of them has an outcome, a judge, an incident or a fine-tune in its model, so none of them can tell a rule that stopped working from a rule that never worked.

​

Feature matrix

---

​

SenseLab vs Mem0

Mem0 extracts facts from conversations in a single ADD-only pass, links the entities across memories in a built-in graph, and ranks results by semantic, keyword, entity and time signals. Since its 2026 algorithm, memories accumulate rather than being updated or deleted. It has a feedback endpoint; in our benchmark we called it on every retrieved memory at outcome time. The difference in one sentence: SenseLab finds out whether acting on a memory worked and repairs what did not. Mem0 stops at retrieving the right memory. Where SenseLab is stronger:

• Outcomes reach the ranking — Commit an outcome and every entry the run relied on is re-weighed: a fresh entry at 0.7 drops to about 0.26 on its first failure and lifts to about 0.82 on its first success, and each entry carries a label — validated, contested, discredited — that the next briefing reads instead of the raw number. Mem0’s feedback endpoint accepts the signal; what it does not do is change what the next agent is shown. After a rule change in our benchmark, Mem0 sat at 0.38 first-attempt success on the affected tasks for forty episodes; SenseLab went from 0.36 to 0.69.
• A repair loop — Judges grade every run. A failure that keeps recurring becomes a named behavior and opens an incident, segmented by model, agent version and tool; the fix to the learning is staged on a branch, replayed against the failing and passing runs, shipped, and verified a week later. Mem0 has no judge, no incident and nothing that changes after a bad outcome.
• Decision traces — record_action(), record_attempt() and commit_outcome() capture the whole causal chain behind an action: what was read at what confidence, what arrived from outside, what was tried and failed, what was decided. Traces are immutable and signed. Mem0 records the memory, never the reasoning that used it.
• Models tuned on your traces — Those traces train a model on how your agents actually work, and we run the training and host it for serving. Mem0 improves what the model reads and stops there.
• Rooms: a shared place to work, not an isolated scope — A room covers a set of topics, and every member’s agent reads and writes the same entries under them: Claude, ChatGPT, Cursor and Claude Code side by side. Mem0’s organizations and projects are isolation boundaries with owner and reader access, and OpenMemory shares context between one person’s own MCP clients on one machine. Neither gives six people’s agents a common surface with topics, attribution and an activity trail.
• A newcomer inherits the recovery — An agent that joins a room is handed what the room already knows before it starts: up to fifty entries across the topics, plus recent activity, with their evidence attached. In our benchmark a newcomer arriving after a rule change solved 0.62 of its first exposures on a SenseLab store against 0.22 on Mem0, where the inherited store still ranked the old fix first — and the Mem0 newcomer applied it.
• Versions you can act on — Mem0 no longer overwrites, which is an improvement, but a pile of accumulated facts is still a log. SenseLab keeps every version as a first-class entry you can read, diff, roll back to or branch from, and when two agents disagree both positions stand with their authors instead of one silently winning on retrieval rank.
• Review before shared knowledge changes — Branching, pull requests, tags, merge and cherry-pick. Mem0 writes straight through.
• Decay that knows about outcomes — Mem0’s Memory Decay is recency: recently used memories rise, idle ones fade. In SenseLab, outcomes are what change stored confidence; decay, when you enable it, weighs time, the kind of learning, whether an outcome ever validated the entry, and how often it is read.
• Nothing to start over — Migrate imports what your agents already know from Mem0, so the record starts with history rather than from zero.

---

​

SenseLab vs Zep / Graphiti

Zep builds temporal context graphs via Graphiti: an LLM extracts entities and relationships from each episode, the edges carry validity windows, and retrieval combines vector, BM25 and graph traversal in one call. Every fact traces back to the episode that produced it. The difference in one sentence: Graphiti records when a fact was true. SenseLab records whether acting on it worked, who learned it, and what to do when it stops working. Where SenseLab is stronger:

• Outcomes move confidence — Graphiti knows when a fact became valid and when it was invalidated by a newer one. Nothing flows back from what happened after an agent acted on it. In SenseLab every outcome is evidence on the entries the run relied on, a validated rule that suddenly fails is flagged as a regime shift, and guidance for that scope switches to explore so agents try something other than the rule that just broke.
• A repair loop — A recurring failure in your agents’ runs opens an incident with a fix that is replay-tested before it ships and verified afterwards. Graphiti maintains the graph; it has no view of the runs that used it.
• Rooms: a team, not a tenant — A room covers a set of topics, and every member’s agent reads and writes the same entries under them — Claude, ChatGPT, Cursor and Claude Code side by side. Membership is collaborator or viewer, and a viewer’s writes are refused at the storage layer, so a stray API call cannot get around it. Graphiti’s group_id partitions one system’s graphs so they do not mix; it does not give six people’s agents a shared place to work, and there is no notion of who may write to it.
• Joining briefings — An agent that joins a room is handed what the room already knows before it starts work: up to fifty entries across the topics, plus recent activity. A new consumer of a Graphiti graph must know what to query for.
• Per-agent provenance — Graphiti’s provenance runs from a fact back to its source episode. SenseLab’s runs to the agent, session and time that produced each version, and one agent reading another’s learning is logged on both timelines.
• Decision traces — The full causal chain behind an action — what was read, at what confidence, what external input arrived, what was tried, what was decided — persisted, signed and replayable. There is no Graphiti equivalent.
• Disagreement is kept, not resolved — A write never overwrites; it supersedes. When two agents write the same key both versions survive with their authors, and the disagreement surfaces in history or in a pattern scan. This is the opposite of edge invalidation, deliberately: nothing decides for you which agent was right.
• Git-like history and review — Diff, version history, branching, pull requests, tags, fork and cherry-pick. Graphiti has bi-temporal versioning but no branching or review model.
• Models tuned on your traces — The same traces behind the outcome loop are training data. We spin up the run, fine-tune on your successful decisions, and host the result for serving. Graphiti improves what the model reads; it does not touch the model.
• Nothing to start over — Migrate imports what your agents already know from Zep.

---

​

SenseLab vs Letta

Letta (formerly MemGPT) is an agent runtime whose memory is a git repository. MemFS projects it onto the machine as Markdown files the agent edits and commits; background “dreaming” subagents consolidate it; shared memory repositories give several cloud-hosted Letta agents the same files; and Letta Evals grades agents against a dataset with a pass/fail gate, in CI. The difference in one sentence: Letta versions what an agent wrote. SenseLab versions what an agent learned, and knows whether it held up. Where SenseLab is stronger:

• Git on learning, not on files — Letta’s git tracks Markdown text: history, diffs, conflict resolution, worktrees for concurrent subagents. SenseLab’s git-like model is on learning entries that carry confidence, evidence status and outcomes. A branch carries a prediction, a pull request is reviewed before the team’s knowledge changes, and a merged fix is replay-tested first and verified a week later. Git tells you a file changed; SenseLab tells you whether the change worked.
• Outcomes — Letta has no outcome. Dreaming reorganizes memory on a step count or on context compaction, not on whether the agent’s actions succeeded. In SenseLab the outcome is what moves confidence, and the briefing an agent starts from reflects it.
• Grading production runs, not test suites — Letta Evals runs an agent against a dataset with graders and a gate — a CI tool, run before deployment. Behavior grades the runs your agents actually make, discovers behaviors you did not think to define, opens incidents when one recurs, repairs the learning, and verifies the repair against live runs.
• Rooms are for people — Letta’s shared memory repositories share files between Letta agents in one organization. A SenseLab room is a workspace several people join, each bringing whichever assistant they use — Claude, ChatGPT, Cursor, Claude Code — with collaborator and viewer roles enforced at the storage layer, a joining briefing for every new agent, and Room Hub to publish a room or subscribe to one. There is no colleague in Letta’s model.
• Concurrent writes that do not conflict — Letta resolves concurrent edits with git: worktrees, merges and automatic conflict repair. SenseLab writes supersede rather than replace, every version keeps its author, and two agents disagreeing leaves both positions standing — there is no merge conflict on a key.
• Decision traces — The full causal chain behind an action is captured, signed and replayable. Letta keeps the conversation and the files; it does not keep the reasoning that produced a decision months ago.
• Models tuned on your traces — Those traces train a model on how your agents actually work, with the training run and the hosting handled for you. Letta manages what goes into the context window; the model underneath stays a general one.
• Data-driven tiering — Hot / Warm / Archive tiers are assigned by priority scoring across confidence, recency, recall frequency and importance, with progressive retrieval deciding how deep a search goes. Letta’s root files sit in the prompt every turn and the agent reads the rest on demand, which spends the model’s attention on memory management.

---

​

The repair loop nobody else runs

The largest gap on this page is not a feature. It is what happens after a bad run. In every other system the answer is nothing: the same memory comes back next time, and someone edits a prompt. SenseLab’s Behavior layer treats the bad run as a signal:

1. Judges grade the run. A starter pack covers ungrounded claims, missing required tools, retry storms, tool-error cascades and unresolved user repetition; you define more in plain language, and Behavior discovers behaviors you did not think to name.
2. A recurring failure opens an incident, segmented by model, agent version and tool, so you see whether it is one model, one release or one integration.
3. A fix is staged to the learning — a knowledge entry, a procedure, or a code handoff — on its own branch, with a prediction of which past failures it would have fixed and which past successes it must not break.
4. The fix is replay-tested against the failing and the passing runs before it ships, and optionally canaried on live runs.
5. It ships, then it is verified a week later. A fix that did not hold is rolled back in one click, and its prevention rate — how often the behavior recurred before and after — stays on the fix.

A repair policy decides how much of this runs on its own: review every fix, ship automatically after replay, or ship automatically after canary. Every proven repair is also a labelled example — situation, wrong action, right action, outcome — for the model loop below. That is the recursive part.

---

​

Models tuned on your own decision traces

Every other memory system here stops at retrieval — it decides what the model gets to see. SenseLab uses the same record to improve the model itself. A decision trace already holds what an agent read with its evidence status, what it decided, which tool it called and whether that turned out well. That is supervised training data, and your agents produce it as a by-product of working. Nothing extra to instrument, nothing to label. We run the entire pipeline for you. No ML engineers, no GPUs to procure, no training infrastructure to maintain:

1. We spin up the training job from traces already sitting in your account. Nothing to export or prepare — the data is there because your agents have been working.
2. We run the fine-tune, score the candidate, and decide whether it is good enough to promote.
3. We host it and serve it, on our infrastructure, behind an endpoint your existing code already knows how to call.

How it works:

• Positive outcomes only. Training pairs come from decisions recorded as successful. Failures are deliberately withheld into a holdout so there is something honest to score against.
• A readiness gate before anything trains. Ninety days of history, a floor of 100 and a target of 200 eligible decisions, at least three distinct primary tools, and at least 60% positive outcomes. Below the gate, no run starts.
• Scored before promotion. Candidates are evaluated on a temporal holdout against a tool-agreement threshold, and only promoted automatically when the gate passes, the subscription is active, and the account is under its live model limit.
• Served behind the API you already use. OpenAI-compatible at /api/v1/chat/completions and the Anthropic dialect at /api/v1/messages, with the model field naming your model.
• Fallback is automatic. An unparseable action, a tool outside the agent’s recent set, a safety block or an upstream error falls back to a general model rather than failing the call.
• Plan limits. One live model on Pro, three on Teams, one hundred on Enterprise.

What a tuned model inherits. In our companion study, a small model trained on a frontier agent’s sealed traces and served with the same memory solved 0.94 and 0.92 of tasks on two scenarios, under the rule change its teacher lived through, where the frontier agent on the same memory solved 0.84 and 0.82 — at about one fortieth of the list price per solved task. Under a second rule change no training trace contained, it matched the frontier on success within noise. The memory keeps working after the experience is in the weights: switching it off cost the tuned model 0.26 first-try success after the change, and serving the same entries without their outcome record cost 0.24 — most of what memory does for a tuned model is the evidence. A third generation trained on the second generation’s own traces improved on its parent. On cost and accuracy, the figures that matter are yours, not ours. Every candidate is scored on a temporal holdout built from your own traces, so what you get is a number for your model on your traffic rather than a benchmark run on somebody else’s workload. No competitor on this page closes this loop. Mem0, Zep and Letta all improve what the model reads. None of them improve the model.

---

​

What Makes SenseLab Unique

1. It closes the loop after the model acts — Every outcome is evidence on the learning the run relied on. Confidence moves, entries carry a label the next briefing reads, failed attempts are charged before the next one is tried, and a rule that just stopped working is flagged. No other system connects memory to what happened next — and in our benchmark that is why SenseLab recovered to 0.69 first-attempt success after a rule change while Mem0 sat at 0.40.
2. It repairs itself — Judges grade production runs, recurring failures open incidents, and the fix to the learning is replay-tested before it ships and verified after. No prompt edit, no redeploy.
3. It trains a model on its own record — The same decision traces become a fine-tuned model: we spin up the job, score it against a holdout of your own decisions, and host it behind an OpenAI-compatible endpoint. No ML team required.
4. Each loop feeds the next — Outcomes improve the memory, failures become tested repairs, the validated record becomes the model, and the model’s own traces train its successor. That arrangement is what makes the improvement recursive.
5. Git for learning, not for files — Branching, pull requests, diff, merge, rollback, tags and fork on entries that carry confidence and outcomes — so a review can ask whether a change worked, not only whether it was made.
6. Rooms are for people — Several people’s agents on one topic, whichever assistant each person uses, with roles enforced at the storage layer, a joining briefing, discussions, negotiations, page-cited documents and a hub to publish or subscribe.
7. Complete decision traces — What was read, done, attempted and every LLM call, immutable and signed, with verify, replay and compare.
8. Cross-system context — Deploys, incidents and reviews land in the record over webhooks, with PagerDuty as a ready-made connector, so outcomes come from the systems that know. Migrate brings in what your agents already learned in Mem0 or Zep.
9. Works with what you already run — Any framework, any IDE or assistant through MCP, SDKs for Python and TypeScript, and nothing to operate. The store outlives any single model choice: in our benchmark a newcomer on a different model read the fleet’s store as well as the model that wrote it.
10. Enterprise-grade — Isolation per account, roles and teams, scoped API keys, audit logging, learning security with SIEM forwarding, usage quotas.