Six pitfalls of AI memory,
and which ones we actually escaped

01Memory makes the agent worse

The trap: treating "remembers a lot" as "remembers correctly". What people want isn't omniscience — it's not being dragged back to last week in the middle of today's task.

Why it happens: most memory systems store everything and search everything. A throwaway decision from three weeks ago and a formal conclusion from this morning sit at identical rank. Both surface, and the model has to guess which one still applies.

How we escaped: we put the gate at write time, not search time.

• An agent can only propose. Proposals land in a pending area; nothing enters your memory until you confirm it. This is the spine of the whole product.
• Unconfirmed proposals auto-archive after 24 hours and stop cluttering the main line.
• Four public vaults, separated: main line / to-do / archive / reference. Search defaults to the main line; history is something you open deliberately.

The side effect: your store grows much slower than a "fully automatic memory" would. That's the point — everything in it is something you personally approved.

02Stale facts weigh the same as current ones

The trap: thinking this is a ranking problem. It's a "how long should this be kept" problem. No amount of ranking rescues a memory that stopped being true.

Why it happens: inverted indexes and vector similarity measure "how similar", never "does this still hold". They have no concept of time.

How we escaped: halfway, and we'll say so plainly.

• What we do have: separate vaults for long-lived principles vs one-off tasks; soft delete with an undo bin; the archive vault excluded from main-line search by default.
• What we don't have: typed decay. There is no mechanism where preferences fade over months, intent over weeks, events over days. That comment gives a workable design. We agree with it. This version doesn't implement it.
• It's filed as S-20261026-02 for the next release. Until then, our memories do not age on their own.

03The granularity trap

The trap: assuming "one memory" is a well-defined unit. It's pulled in three directions at once: summaries build context, details drive execution, and cross-project work needs isolation.

Why it happens: one granularity, many purposes. A single record can't be both summary and detail, and mixing them means they contaminate each other.

How we escaped:

• One memory, one thing: conclusion + evidence + coordinates. Coordinates mean absolute paths, line numbers, URLs — written so they can actually be checked, never "that file".
• Vaults carry the isolation: detail from one area never lands in another area's main line.
• The agent picks the vault when proposing. Pick wrong and you'll see it; fixing it costs one click.

04Plaintext files bloat, and they carry noise

The trap: "plain files you can read and take with you" is our core selling point, and this lands right on it. Readable is not the same as clean.

Why it happens: file-based storage that only ever grows is a junkyard after a year. Worse, noise doesn't disappear — every full read picks it up again.

How we escaped:

• Dedupe on write; deletes are soft, into a bin you can undo (not rm).
• Archive kept separate from the main line, excluded from default search — noise sinks, but isn't lost.
• Automatic daily backup, 10 copies retained, so a corrupted store can go back to yesterday.
• It does get slower as it grows, and that's real: measured p95 of ~127 ms at 1,356 entries; at 1M entries under load test, 0.6 s warm search but 5.3 GB of RAM. Plain files scale to a million entries — the price is memory.

05"Memory" is actually ten different things

The trap: building one universal memory to cover everything. Facts, preferences, commitments, relationships, emotions, tasks — different decay curves, different notions of correctness.

Why it happens: "memory" is one word in the pitch and at least six different data structures with six different freshness rules in the implementation.

How we escaped: we accepted it, then split by purpose rather than by type — main line / to-do / archive / reference, plus four encrypted private vaults.

That's a trade-off. Purpose-based splitting matches human intuition ("this belongs in to-do"); type-based splitting is easier for a machine ("this is a preference, decays monthly"). We chose the former because this store is meant for you to approve, not for a model to tune automatically. The cost is exactly pitfall 02 — typed decay still has to be built separately.

06The selling point we got wrong

The trap: we had been leading with "your data stays yours, no cloud". In this corpus, that's barely a topic. Technical audiences ask "does it work" before "who owns it".

Why it happens: data sovereignty hurts after a loss; inaccurate memory hurts every day. People fix the daily pain first. (Our inference, not something the comments state directly.)

What we changed:

• For technical communities: lead with "remembers accurately, you approve it, you can undo it". Sovereignty is the foundation, not the slogan.
• For ordinary users, sovereignty is still the main story — their worry is "will my stuff be wiped some day".
• Two audiences cannot be sold with one sentence. That was the biggest lesson here.

This one was our mistake, not someone else's pitfall. It's written down for anyone else building in this space: don't assume that because local encryption is harder to build, it's worth more in the market.