Four Ways to Remember a Document

An assistant that remembers you has the easy half of the problem when it wrote the thing it is remembering. Whatever it authored, it authored for a reason, in a shape it chose, at a moment it understood.

The hard half is everyone else's files. People arrive with folders — a laptop directory synced up, an export from some other tool, four years of meeting notes, an archive of scanned invoices — and they are right to. An assistant you have to curate for before it becomes useful is a filing system with extra steps. But that material carries no signal about what matters in it. Nothing in four hundred synced files says which one will matter in November, and nothing ranks them, because none of them was written to be ranked.

That leaves two ways to be wrong, on opposite sides.

Keep it all as inert storage and the assistant is a cabinet. The answer is in there, it can be found if you ask precisely enough, and it will never once come up on its own.

Push it all into memory at full strength and something worse happens: memory stops being able to answer toward relevance. An archive of invoices and one note recording a decision go in on equal terms, and where retrieval is ranked by similarity, volume wins. You do not end up with an assistant that knows more. You end up with one whose answers are diluted by everything it was handed.

So the question is what a system should do with a document it did not write, arriving in bulk, with no idea which parts of it matter. The answer we ended up with is not a threshold and not a better ranker. It is that "remembered" is not a boolean — and that the useful question is not how much of a file to store, but which machinery the file gets to touch.

We got there from a case where the top setting was switched on and the answer still came back wrong.

Someone points us at a folder of weekly notes synced off their laptop and picks that top setting: Remember every file. The line underneath says their agents will read and remember each one.

A fortnight later they ask when to start the renewal conversation with a client. The answer comes back confident, specific, and a year out of date. It quotes the end of the current term, correctly, from a contract note. It knows nothing about the call three weeks ago where the client asked to bring the whole thing forward to January.

That call is in the folder. It is in a weekly note, in one sentence, four lines below a reminder to book a dentist appointment.

Here is what promotion to the top rung actually did with that note. It registered one entry in memory per file, and the text of the entry was the file's title, its tags and its description. The weekly note has no frontmatter — it is a file a laptop dropped there, not a document anyone authored for us — so the text that entered memory was its filename. Remember every file was a true statement about files and a false one about what is inside them.

The cheap fix is to change the label. We wrote that option down and kept it: relabel the top rung as instant findability, lose the insight promise, keep the ladder honest. It stayed on the table for a day and it was the right thing to hold, because the expensive fix is only worth it if the machinery it buys does something the machinery underneath cannot.

Working out whether that was true meant answering a question we had been treating as settled: what does it actually mean for a document to be remembered?

Four intensities

So a document sits at one of four, and the ladder between them is not a ladder of how much is stored — the full body is reachable at three of the four rungs. It is a ladder of which machinery engages, and at the top, of whether the thing can reach you without being asked for.

Five things fell out of drawing that table, and the first one is the only line in it that really matters.

Push and pull are different products

The two middle rungs are findable. The top rung is findable and can arrive on its own. That is the whole ladder.

The difference is a library and a librarian. A library will hand you anything you can name. A librarian says you'll want to see this before you knew to ask for it, and that is a different capability with a different cost, not a better-tuned version of the first.

The reason it survives as a distinction is structural. There are two meaning-level indexes in the system and they are deliberately not joined. One sits over document bodies and is consulted when somebody asks a question. The other sits over memory and is consulted before the agent answers, on every turn, whether or not anyone asked it to look. Nothing feeds the second from the first. A document that exists only in the vault is reachable by any question you think to ask and will never come to mind unprompted.

That non-join used to look like an omission. It is the reason the setting means anything: the four rungs are a dial across exactly that boundary.

It also killed the original argument for the top rung. Once meaning-level search over full bodies shipped — locally computed, no model calls, near enough free — "get this into memory so my agents can find it" stopped being a thing anyone needed to buy. Findability went uniform across the top three rungs. What remained was the half that memory alone can do, which is turning up unasked.

And the default is the second rung. The system's default posture toward a document somebody drops on it is never volunteer.

What memory holds for a document is a pointer

Not the document. One line: where it is, what it is called, what it is about.

This looks like a shortcut and it is a design. The document store already keeps the only copy, and the moment memory holds a second copy of the prose you have two truths to keep in step. Three things follow from refusing that.

There is no drift, because there is nothing to drift from. Demotion is clean — you tombstone a pointer, which is an operation with an obvious meaning, rather than trying to un-remember a paragraph. And the third one we had not planned for: the quality of unprompted recall over documents is bounded by the quality of their titles and descriptions. Metadata stops being tidiness and becomes load-bearing. It is a card catalogue, and a card catalogue is only as good as the cards.

Which is exactly what the renewal question ran into. A file whose card says nothing cannot be recalled by a system that only ever reads cards.

Extraction, never copying

So the top rung had to read the bodies. The question was what to do with what it found, and the tempting answer — write the interesting passages into memory — is the same duplication mistake wearing a better hat.

What a document cannot express about itself is structure. Prose says "Northwind want to bring the renewal forward to January because of their budget cycle" and that sentence is perfectly retrievable from the document. What it is not is joinable. Ask what you know about that client and no amount of similarity search assembles the fee, the notice period, the term end and the moved conversation into one answer, because those four things live in different files and similarity does not do joins.

So the top rung runs a single structured pass per segment of the file and pulls out facts as subject-relation-object triples, and the constraint that makes it work is a validation rule: the subject must be a real-world entity. A person, a company, a project, a figure. Never a file path. Path-keyed rows already existed — this file is called that, this file is tagged that — and they are worth nothing to somebody asking about a client, because nobody's question has a file path in it.

Two implementation choices are worth stealing. It is one structured call per segment rather than an agentic loop, so the cost of extracting from a file is known before it runs and does not depend on a cheap model reliably driving a tool loop, which in our experience it does not. And long files are cut on entry boundaries rather than at a character count, which is what lets a multi-megabyte running log go through in full instead of being truncated at whatever cap seemed generous.

A ledger makes it reversible, and reversible makes it cheap

Every fact the extraction writes is recorded against the document it came from, keyed by a hash of that document's content.

That one record does three jobs. Demotion tombstones exactly what extraction wrote, and nothing else — the difference between un-remembering a document and hoping. A changed document diffs against its old set instead of piling a second copy of itself on top. And an unchanged document costs nothing at all: same hash, no model call, apply the whole folder again and again for free.

We had argued for idempotence as correctness. Here it is also the cost control and the safety story, and those turn out to be the same property viewed from different ends. A thing you can undo exactly is a thing you can afford to redo.

The policy belongs to the destination, not the author

There are more ways for a file to arrive than anyone lists on the first pass. An agent writes a note. A person edits a document in the browser. A connector saves an email. Somebody drags a file into a conversation. A sync job copies a folder. A remote tool call writes from another machine.

All of them now run through one gate that asks the same question — what has this file's destination folder been set to? — and does what that says. Who wrote the file does not enter into it.

This was a bug fix before it was a principle. Agent-authored notes had always been remembered in full, by construction, because in the beginning they were the only things in memory. Which meant an agent writing into a folder the user had deliberately demoted put the file straight back into memory, silently, and the badge on the document changed under them. The user's setting was correct and the write did not consult it.

The general form is a shape that recurs: an exemption derived from who is acting is a policy hole with good manners. It looks like trust and behaves like a bypass. Policy attaches to the destination, and every route in has to pass the same gate, or the setting is advisory.

Two paths that still ignore the setting

They index at the top rung unconditionally, whatever the folder is set to.

Generated data views — the readable rendering of a structured dataset — always get the full treatment. That one is deliberate and still open: a dataset view is a different kind of object from a file somebody dropped in a folder, and we have not settled what its policy ought to be.

And the gate itself falls back to the top rung when it cannot read a policy: during early boot, before the policy lookup has registered, or if that read throws. The reasoning was that a failed policy read must never break indexing. The reasoning is fine and the default is the wrong way round — a system whose failure mode is remember more than you were asked to has picked the wrong direction to fail in, in a product whose entire proposition is that you decide what it keeps. It is a small window and it is on the list.

Postscript, August 2026. The four rungs held, including under a proposal to collapse the top two into a single "Remembered" setting with a size guard. That was declined for a reason that only became visible after the extraction work: the two rungs now sit on opposite sides of a real cost boundary, and merging them would have hidden it.

What did move was the vocabulary, twice, and it moved because the axis moved. The dialog originally described how much of a file the system takes in. Once meaning-level search made every non-stored file findable, that axis was measuring something the rungs no longer differed on, and the copy was describing machinery instead of consequences. It now asks what form the content takes in memory — distilled facts, the gist, searchable text, nothing — which is the question the rungs actually answer.

The stakes went up in the same period. Unprompted recall used to fire on chat turns only; it now runs on scheduled work and on each stage of a multi-step job. The top rung buys presence in more places than it did when we drew the table, which makes "never volunteer by default" a better default than it was.