The problem: the tenth session should be smarter than the first

Their framing is precise, and it is ours as well. A person works with an agent for months and hundreds of sessions. By the tenth session the system must be noticeably more useful than it was in the first — it should know what the project is, who is involved, which formats the person prefers, how the last analysis ended. If every conversation starts from zero, that is not a colleague; it is a search box with good manners.

The problem has two halves. Knowing a fact is not enough — the agent has to know that the fact exists at all and how to reach it. Having reached it, the agent has to know whether it is current and where it came from. A lone fact with no source and no neighbours is worth little: it can be neither verified nor updated.

The two obvious answers are both bad. Dumping every memory file into the context trades precision for recall: the window fills with steadily less relevant material, and trimming it degrades the answer. Putting everything in an external database is flexible, but pushes navigation onto the agent: a vector store returns disconnected fragments, and a graph has to be queried competently to give anything back.

What Brain is

Brain is a wiki on top of file-based memory. Computer's memory is materialised in the sandbox as an ordinary filesystem, with three top-level directories under memory/: sessions/ holds the raw material — indexes, summaries, full transcripts; notes/ holds distilled snippets by topic; knowledge/ is Brain itself.

The wiki is a system of linked Markdown pages. One page is one subject, and it must remain useful when read alone. There are two kinds of edges, and this split is the most valuable part of their design:

• [[wikilinks]] are context edges, sideways. They answer "what else do I need to know": a project links to its owner, its client, the concepts it depends on.
• [cite:N] are evidence edges, downwards. They answer "how do I know this is true": they lead to a specific session or a connector source.

All of it is Git-backed, so versions, diffs and changelogs exist, and several agents can edit the wiki at once without overwriting each other.

Three decisions there deserve to be called out.

The compact index of the wiki goes straight into the first message. Not "the agent can read it", but it is already there. A separate randomised experiment showed a 6.9% drop in memory-related dissatisfaction from this change alone. A cheap edit with a measurable effect.

Navigation happens through ordinary tools. cat memory/knowledge/index.md, grep -Ril "kyoto" memory/knowledge/, follow a link, compare Git revisions. No new interface between the model and its memory: the agent already knows how to work with files.

A local working set instead of the whole corpus. Copying the entire tree at sandbox boot is expensive, and keeping it on a remote filesystem is worse, for a specific reason: an agent performs thousands of filesystem operations in a single command, and if each one becomes a network round trip, the exploration loop stalls. Their measurement: grep over a remote FUSE-backed path was 400 to 500 times slower than over local files. So boot preloads a map, and from there a subagent semantically searches for what was described and materialises the supporting files into the same tree — the working set grows gradually and the paths stay stable.

Dream: memory is rewritten offline

The most interesting part is not reading but maintenance. That is the job of background agents called Dream: the same sandbox, the same files, read-only tools, and a single goal — improve the context for future sessions. Each run starts not from scratch but from the wiki the previous run produced.

Four phases: orient (scope, standing instructions, deletion log, stopping conditions) → summarise sessions that are new or have new turns → attach every significant observation to its proper subject → update the wiki: open a page for a durable new subject, rewrite a synthesis that has changed, add links and citations. Or change nothing, when the graph is already correct.

They write into a staged output tree: nothing becomes permanent until the agent has finished the whole set of edits, so the graph is updated as a whole rather than as unrelated pages. Then two checks run — deterministic (frontmatter present, citation format valid) and semantic (is the proposed synthesis supported by the gathered evidence, and consistent with the rest of the graph) — and only then does the change synchronise into the repository.

What it bought them

Offline: 640 questions across 44 synthetic personas, comparing "wiki enabled" against "wiki withheld" while the other memory surfaces stay available in both conditions — so what is measured is the contribution of the wiki, not of memory in general. Correctness 0.600 → 0.661 (+6.1 pp), evidence recall 0.573 → 0.625 (+5.2 pp). The largest gains are on questions about preferences (+10.2 pp) and about time (+8.6 pp).

On public benchmarks: removing the wiki costs 4.6 pp of correctness on LoCoMo, and makes no significant difference on LongMemEval-S. They explain that honestly: LongMemEval-S tests recovering a fact from a single session, where the transcript is a redundant path to the answer, while LoCoMo requires stitching evidence across conversations and dates.

In production, a daily paired evaluation: +9.3 points of correctness, +8.0 of currentness, +8.9 of recall, at −15% tokens, −10% cost and −10% generation time. The last part matters more than the first: organised memory does not add to the context, it replaces it.

How it works on our side

Three places where we chose differently

A note is keyed by topic, not by session. In their design a background agent attaches an observation to its subject; in ours it is a property of the key itself. The store holds a picture of what is known rather than a log of when it was learned. A log grows linearly with the number of conversations; a picture grows with the number of topics.

A fact does not enter memory unless it follows from its source. A separate lightweight judge checks the claim against the captured transcript, never refetching live data. If it is not supported, or the judge's reply cannot be parsed, the claim is dropped. This is stricter than their semantic check: theirs verifies the synthesis of a page, ours verifies every claim on the way in. The price is honest — some true facts are lost. We think the trade is right, because an error in long-term memory lives for months and is rewritten into new answers as if it were the agent's own.

We delete nothing. A note that stops being read is not pruned after a month; it sinks in the manifest ranking by half-life. Deletion judged a note on a signal it could not possibly have earned: a note is only read if the manifest offered it, and every note we used to prune had zero reads. That was a sentence for not having been shown.

What their post leaves out: memory as a laundering channel for injections

The Brain write-up says a great deal about accuracy and cost and nothing about the fact that an agent's memory is a delivery channel for instructions.

Everything an agent reads from a web page, someone else's MCP server or someone else's CRM arrives for one turn and arrives fenced: it is data, not commands. But the moment the agent writes what it learned into its own memory file, the same text comes back unfenced, in the stable prefix, under a directive that calls it the agent's own memory. A one-turn quotation has become a standing instruction — and no attacker is required for that, an honest summary of a hostile page is enough.

So the project memory file passes the same screen the project rules file pays, and a filtered verdict is deliberately distinguishable from an empty file: if the body was withheld, the render has to say so. Otherwise "keep this file current" plus "the file is empty" is an invitation to overwrite real memory with nothing.

What we are taking

1. The memory index in the first message. It bought them a measurable effect for almost nothing. We already have a manifest; the question is whether it arrives in the starting context instead of on request.
2. Citations as edges. Our notes are verified against their source on the way in, but the link to that source does not live in the note's body as something to navigate. A guarantee at write time and the ability to re-check a month later are different things.
3. A staged tree for the nightly distillation. We already write in an atomic batch, but the set of edits is assembled one note at a time.
4. The paired evaluation. The most inconvenient item and the most necessary one: we have no number that says what our memory is worth — enabled versus disabled, on the same questions. Until that number exists, memory work is done by taste. Of everything in Perplexity's post, this is the one thing to copy outright.

Honestly about the limits

Their numbers are not our numbers: the ablations ran on their data, their personas and their agent, and none of it transfers as a promise. Worth noting separately is their honesty in the one place where silence would have been convenient: LongMemEval-S showed no significant difference, and they published that instead of hiding it. A post about your own architecture in which one of three measurements is flat earns more trust than one where all three are green.

FAQ

How is this different from RAG? Retrieval returns chunks that resemble the query. A wiki is an artifact compiled offline: the page was written in advance, linked to its neighbours, bound to its sources, and it outlives many sessions. Neither replaces the other — the raw material behind the wiki still has to be found.

Why files rather than a database? Any bespoke interface to memory is one more language the model has to learn and will make mistakes in. It already knows grep.

Why update memory at night rather than in the conversation? A good memory page requires going across several sessions, comparing them, discarding contradictions and rewriting what is already there. A user's turn has neither the time nor the context for that, and the result has to outlive the turn.

What happens when a fact changes? The note is rewritten, not appended to. Otherwise both versions sit in memory as alternatives, and the agent picks between them at random.