An assistant with a long-term memory has to answer a question most software never faces: of everything a person gives it, what should it actually remember?
The generous answer — remember all of it — destroys the thing it promises. Where recall is ranked by similarity, volume wins, and three hundred receipts must not be allowed to outrank the one note recording a decision. We made that argument in the previous entry and take it as settled here: push everything into memory at full strength and memory stops being able to answer toward relevance.
But the cautious answer fails too, and its failure is nastier because nobody sees it happen. For most of this system's life, the de facto policy was that only notes the agents authored themselves entered semantic memory. Everything a person uploaded, dragged in, or synced was keyword-searchable storage at best. That sounds reasonable — agent-authored notes are curated by construction — and it silently wrong-foots people, because a person who puts a folder into their assistant's vault reasonably assumes the assistant now knows it. It didn't. Two kinds of file wearing the same coat: notes the agents remembered, and files they had merely filed away, with nothing anywhere telling you which was which.
So the real finding of this phase is that there is no good default. Any fixed policy is wrong for someone's folder — the archive that should stay inert, the contract folder that should be known cold. What shipped instead is the decision made visible and owned: every folder carries a plain-language memory setting, the setting is offered at the moment files arrive, and the system's standing rule is that it never promotes content into memory silently. What gets in stopped being an architectural constant and became something a person decides, folder by folder, in words they can act on.
This entry is about the machinery that makes such a choice trustworthy — because a setting a user cannot verify, applied by a process that can half-fail, is worse than no setting at all.
Ask at the door, once
There are more ways for a file to arrive than anyone lists on the first try: a bulk folder copy, a file-picker upload, a connector saving email attachments, something pasted into a conversation, a sync job, an agent writing a note. Each is a door, and the choice is presented at the door — with discipline about how often.
The granularity is the folder, never the file. A folder import shows the ladder once, with the middle rung pre-selected; every file inherits. A connector saving into a new folder prompts once, and every later save inherits silently. A file attached mid-conversation lands searchable, with a lightweight "remember this" affordance afterwards — never a modal interrupting the exchange. Ask about a place once, not about a thousand files; a memory system that nags is a memory system whose prompts get dismissed unread, which converts the explicit choice back into an accidental default.
The four settings are stated in plain words — Remember every file, Remember the gist, Keep as searchable files, Just store them — and each carries a concrete example, because the abstract descriptions tested as too vague to choose between. What each rung mechanically does was the previous entry's subject; this one is about keeping the contract honest once the choice exists.
The badge cannot lie
Every file and folder shows its standing — in memory, gist only, searchable, stored. The obvious implementation is a stored status field, written when the policy is applied. We refused it, on a rule that has earned its keep across this codebase: derive state, don't store it.
A stored badge is a claim about the past — we once set this to X — wearing the costume of a claim about the present. The two part company the first time anything goes wrong: an apply that dies midway, a store that changes behind the flag, a migration that misses a row. From then on the interface asserts something the stores no longer agree with, and no one can tell from the outside.
So the badge is computed, on read, from what the stores actually hold. A per-file memory entry exists → in memory. The folder holds a summary entry → gist. A keyword-index entry only → searchable. None of the above → stored. There is no status field anywhere to go stale, which means the display is structurally incapable of disagreeing with reality — the strongest honesty guarantee available, because it is not a guarantee anyone has to maintain. In a product whose promise is you can see exactly what your agents hold, that property is not an implementation nicety. It is the promise.
Apply is a destination, not a journey
Changing a folder's setting means real work: tearing down per-file memory entries, writing or removing a folder summary, adding or dropping index entries, over possibly hundreds of files. With four settings there are twelve possible transitions, and the obvious implementation — read the old policy, compute the difference, apply the delta — means twelve code paths, each an opportunity to be subtly wrong, plus a thirteenth nobody writes: recovering from an apply that died in the middle.
The version that shipped never reads the previous policy at all. Applying a setting is target-state reconstruction: each target unconditionally removes every artifact it must not have and builds every artifact it must, regardless of what was there before. All twelve transitions collapse into four idempotent destinations, correct by construction rather than by enumeration. And the failure story falls out for free: each file's work is wrapped so one blip cannot abort the whole apply, a partial failure leaves a mixed state the rollup honestly reports, and the recovery procedure is apply it again — same target, clean result. There is deliberately no retry queue, because a cheap idempotent apply is the retry mechanism.
The one bug this design produced is the exception that argues for the rule. The only transition that misbehaved was the one the delta mindset says is trivial: re-applying a folder's current setting. The full-memory branch originally skipped its own teardown — the source tier "couldn't" hold those artifacts — so applying Remember every file twice appended a duplicate memory entry per file. And applying a setting twice is not a rare event; it is what a person does when they are not sure the first tap worked. The fix was to make the branch true to the principle it had shortcut: tear down first, always, even when you believe there is nothing to tear down.
Words that keep the contract honest
The remaining machinery is vocabulary, and it did as many revisions as the code. Three details from that work say what kind of product this is trying to be.
The strongest setting argues against itself. Selecting Remember every file on a large folder shows an amber warning — memory gets noisy; stray details start surfacing in answers unprompted — and the dialog suggests the gist setting instead. On a small, focused folder the same option shows a soft green "fine for a folder like this". The system has an interest in looking as capable as possible, and "remember everything about me" is the capability-sounding choice; pricing it honestly at the moment of choice, scaled by the actual folder in front of you, is the opposite of a dark pattern and cost one afternoon.
The weakest setting says what still works. Just store them originally read as if the files went dark. The shipped copy says the agents "won't learn the contents or find them by search — but can still open one if you name it directly", because that is the truth: the rung switches off discovery, not access, and copy that overstates a restriction is as dishonest as copy that overstates a capability.
And one word was refused outright. "Trained" was floated for the top rung — train your agents on this folder. It is wrong. Retrieval is not training: nothing about any model changes when a folder is remembered, and the product's standing commitment is that it never trains on your data. Using "trained" as a warmth word for indexing would spend the credibility of that commitment on a metaphor. The copy says learns and remembers — words whose plain reading matches what the machinery does — and the distinction is load-bearing enough that we wrote it down as a rule rather than a preference.
What a memory owes its owner
The through-line of this phase: an assistant's memory is the user's to govern, and governance needs three properties the defaults never had. The decision must be theirs — made in plain words, at the door, never silently. The display must be true — derived from the stores, incapable of drift. And the mechanism must be safe to use carelessly — idempotent, self-healing, honest about partial failure. Remembering everything was never the goal, and neither was the quiet inverse we shipped first. The goal is that what an assistant holds about you is exactly what you decided it should — and that you can check.
Postscript, August 2026. The rungs and the never-silently-promote rule have held. The apply became a background job the day after this entry — the dialog closes at once, and the folder's memory line carries the target badge and "applying…" until it settles, with a visible retry if it fails. The vocabulary moved twice more within days — the previous entry's postscript tells that story from the document side — and a few doors remain honestly unwired: the loose-file upload affordances still route through the folder machinery rather than their own choice cards, and promoted bulk content still indexes into a file's natural area rather than a separate namespace, a hardening deferred until scale demands it. And the boot-cost rule is written down beside the machinery it protects, so the next encoder proposal has to answer for the largest vault's cold start before it answers for anything else — which is exactly where the last change hurt us.