Four ownership scopes, five processing layers, one database
Everything in the architecture lives in one on-device SQLite file. There is no separate memory server, and nothing here requires a network call. The five processing layers are not five databases, and they are not quite the same thing as the ownership scopes a row of memory can carry. Three layers correspond directly to an ownership scope; the other two, the control plane and recall, are how that ownership gets enforced and read back, not additional owners.
Global and user-identity memory is the first ownership scope: facts about the person, not the project—preferred language, coding conventions, standing instructions the user gives repeatedly. This scope attaches to no particular agent and no particular project, so it follows the user everywhere.
Per-project memory is the second scope, tied to whichever folder the agent is currently working in. It draws on three sources most engineering projects already have: a running summary of the project's goals and past decisions (the project's soul), a generated map of the codebase's structure, and a sitemap of project documentation. These are injected together, so an agent opening a project for the first time in a session does not need the user to re-explain what the project is.
Per-agent memory and experience is where the remaining two scopes live, and where most of the complexity sits, because the agent is not always one thing. An agent running alone owns its memory under an agent scope outright. An agent that is one role inside a team is different: a fourth scope, shared team memory, exists for facts the whole team should see, while the team's coordinator and its specialists still learn under the agent scope, attributed to different agents by what kind of thing was learned. The owner of any row in the agent scope is a tuple—agent identifier, package hash, project, and environment—not just an agent name, so the same agent installed twice in two different contexts does not share memory it should not share.
What actually happens on a turn
An assistant's reply on a turn passes through curation, which classifies it into curatable events; a semantic admission check drops near-duplicates; anything that survives is inserted with a locally computed embedding. Separately, if the reply represents an operational outcome worth remembering as experience rather than a fact, it is intaken into the experience table, and a promotion receipt records why.
On a later turn working a similar task, recall does not read the whole memory table. It ranks by a hybrid of lexical overlap and cosine similarity, pulls experience candidates ranked by their relation-graph connections, and folds in whatever the user's shared hub says operationally for the session, alongside the project's soul and code map. All four sources are joined into the same context block before it becomes a system prompt. The recall gate is simple by design: a candidate needs either a nonzero lexical match or to clear a similarity floor, which keeps the system from injecting confident-sounding nonsense purely because a vector happened to be nearby.
The same task, three kinds of agent
An agent in Agentlas can be local, hosted on Agent Cloud, or borrowed from a Hub. That distinction matters less than it might seem: all three curate into the exact same device-local store, using the same curation path. What differs is only where experience is owned and where a chip loadout comes from.
A local agent's memory and experience are both fully on-device. A cloud agent's memory stays device-local, but its experience can optionally be published to a cloud account, which is what makes an experience chip sellable later. A Hub agent runs inside a read-only boundary and carries a chip loadout injected at runtime from the Hub's own ontology projection, so what it has learned travels with the lease rather than with the device.
Where the embedding and the graph actually intervene
It is easy to draw a memory architecture that has a nice-looking graph in it and never actually reads from that graph. The honest version: the local embedding model (potion-multilingual-128M, quantized to 256-dimensional int8 vectors, chosen so multilingual text including Korean embeds without calling out to any external model) feeds the hybrid ranking function that recall actually calls.
The relation graph, built from the same rows, feeds two live intervention points: it re-ranks what gets recalled into a prompt, and it biases the auto-router's choice of which agent should receive a new task, through an experience-priors map. Both are real runtime hooks, not a decorative visualization sitting beside the real system.
Shipped and running in production
Team-scoped agents used to have a real gap: a member of a team's org chart had no first-class agent identity of its own, so any experience it earned had nowhere durable to attach and was silently dropped. Schema v75 fixes this by materializing every local team member as a first-class agent row, identified by its org-node slug, additively and idempotently, with no retroactive rewriting of history. On a copy of a live production database this took the agent count from 30 to 92 and materialized 62 member cells across all nine teams present, and it unblocked 55 member-scoped memories that previously had nowhere to attach.
The curator now routes what a team learns by kind: decisions and conflicts go to the team's coordinating agent, shared facts go to team-wide memory, and domain-specific skill goes to the individual member who actually did the work. Separately, the self-evolution loop—propose, apply, roll back—went from a code path that had never fired in production to one that fires on three concrete triggers: a repeated failure pattern, an accumulation of promoted memories, or repeated steering from the user. Proposals are trust-tiered, so low-risk ones apply automatically with a one-click undo while higher-risk ones require explicit approval, surfaced across the desktop dashboard, the One assistant surface, the terminal, and the Hub-connected runtime. A one-time import path also converts memory from a prior markdown-based system into Agentlas memory, idempotently and with secrets redacted.
Researched, shipped dark
The conversational side of memory had its own gap: the relation graph was only ever built from documents, never from ordinary conversation, so an agent's day-to-day dialogue accumulated entities with no relations between them. We built the missing half: when enabled, entities, mentions, and typed relations are recorded for each conversational memory as it is written, bi-temporally, whether or not a language model is available to help.
We then measured, rather than assumed, whether this closes any real gap in recall. It does not, at least not yet. On LoCoMo, sweeping the graph's fusion weight from 0.15 to 1.0, injecting graph-bridged candidates into the ranking left retrieval recall flat to slightly negative at every weight; a directional check on LongMemEval's multi-session questions showed the same pattern. The vector ranking already captures most of the connectivity these benchmarks reward. Upgrading the graph's edges from deterministic co-occurrence to language-model-typed subject-predicate-object relations did not change that result for recall.
It did measurably help a downstream case: when a conversation is distilled into structured facts rather than handed to a reader as raw transcript, a stronger extractor improved answer accuracy on questions that depend on getting a specific date right. This code ships in the runtime but disabled by default, behind a single environment flag, so with it off—which is how every user runs—the graph is never built and retrieval is byte-for-byte the proven lexical-plus-vector path that produced the recall numbers below. We shipped it dark rather than deleting it because the half-graph was a real defect and the typed-relation channel is where we expect the eventual win; we are not willing to turn on, for every user, a channel we ourselves measured as providing no benefit yet.
What we measured, and how
We evaluated retrieval quality on two independent public benchmarks for long-term conversational memory, using the same harness logic against both: ingest every session in a conversation as one memory unit, then for each question check whether the sessions holding the evidence for its answer appear in the top results retrieved.
LongMemEval (500 questions spanning single-session recall, multi-session reasoning, temporal reasoning, knowledge updates, and preference recall) and LoCoMo (very long multi-session conversations, roughly 19 sessions and 300 turns each, with questions labeled single-hop, multi-hop, temporal, and open-domain) were both run with retrieval alone—no reader model involved—so the number is a direct, reproducible count of whether the right session showed up, not a judgment call by any model.
- LongMemEval — 500 questions — recall@10: 96.4%
- LoCoMo — 1,536 questions — recall@10 (all): 86.9%
- LoCoMo — 1,536 questions — recall@10 (single-hop): 94.1%
- LoCoMo — 1,536 questions — hit@10 (all): 91.5%
The reader matters as much as the memory
Both retrieval numbers above are produced entirely by the local embedding model and hybrid ranking. No external API call and no per-query model inference is required to reach them.
We also ran a smaller internal experiment on end-to-end question answering, and we report it separately, as a methodology finding rather than a competitive score: on a 42-question sample it is dominated by which reader model answers, not by the memory system underneath it. With identical retrieval and identical questions, we measured 24.2% overall accuracy with a 20-billion-parameter local reader model and 59.5% with Claude Sonnet 5—the reader moved the outcome by more than double. Retrieval quality is necessary but not sufficient; what reads the retrieved memory back into an answer matters at least as much.
Giving the reader more retrieved context did not uniformly help either. Widening from 5 to 10 retrieved sessions raised single-hop accuracy (75.0% to 91.7%) and multi-hop accuracy (50.0% to 58.3%), but cut temporal accuracy nearly in half (41.7% to 8.3%), because more sessions means more competing dates to confuse. A query classifier that sends temporal-sounding questions to a narrower window and multi-hop-sounding ones to a wider one recovered most of the gains without temporal's collapse—though ours is currently a small set of keyword patterns rather than a trained model.
Where this sits next to other memory systems
Start with the number that needs no reader model, no judge, and no asterisk: how often the memory actually finds the right thing.
- Agentlas — LongMemEval — no reader: 96.4%
- Agentlas — LoCoMo — no reader: 91.5%
- Supermemory — LongMemEval — GPT-4o reader: 95.0%
- Supermemory — LongMemEval — GPT-5 reader: 84.6%
- Supermemory — LongMemEval — Gemini-3-Pro reader: 85.2%
On answering correctly, not just retrieving
Agentlas finds the right memory without ever calling a model to do it. Supermemory's own published number, on the same benchmark family, needs a frontier model in the loop and still lands in the same range we reach for free. We are not certain their number measures exactly the same thing ours does—they label it Recall@k=15 rather than accuracy, and one data point in their own table (a 91% score on a temporal-reasoning category that Zep, testing the same benchmark variant with the same GPT-4o model, put at 62.4%) is the kind of gap that makes us want to see their methodology before calling it a like-for-like match.
For the harder question—does the system also answer correctly, not just retrieve correctly—here are the three other projects whose published numbers trace to a specific paper or post with a stated reader model:
- mem0 — LoCoMo — GPT-4o-mini reader: 66.9% (arXiv 2504.19413)
- Letta / MemGPT — LoCoMo — GPT-4o-mini reader: 74.0% (Letta, 2025)
- A-MEM — LoCoMo — GPT-4o-mini reader: F1 44.7 / 27.0, one-hop / multi-hop (arXiv 2502.12110)
What this architecture is actually for
Where Agentlas is already strong today, measured with Claude Sonnet 5 as reader on the same sample: single-fact recall questions answered correctly 91.7% of the time, and open-ended questions 83.3% of the time. The categories still catching up—multi-hop chains and precise dates—are the categories every system in this comparison is weakest on too; nobody we could find a verifiable number for is solving them well yet, and closing that gap is the next thing we are building toward.
None of this is benchmark-driven design. The scope split existed before any of these measurements were run, because it solves a real product problem: a user's preferences should not live and die with one project, and one team member's hard-won debugging experience should not silently become another member's assumed context.
The benchmarks are how we checked that this design choice did not cost us anything on the axis every other memory system is measured on. It did not, on the metric that isolates the memory system itself. Where the numbers move—reader model choice, and how much raw context a reader is handed—they point at where the next real engineering work is, not at the architecture itself.
