Most "give your AI a memory" posts stop at the same place: embed everything, throw it in a vector store, retrieve top-k before each call. That works for documents. It fails for a personal assistant, and the failure is not about retrieval quality — it is about lifetime.
Here is the thing that took months to learn: a personal assistant accumulates four kinds of knowledge with four completely different expiry rules, and putting them in one flat store makes all four worse.
The four types
1. Facts. "Lives in Bali." "Prefers replies in Russian." "Runs a tattoo studio." A fact holds until it changes — and when it changes, the old value must be overwritten, not appended. A vector store happily keeps both, retrieves both, and now your assistant knows two contradictory things with equal confidence.
2. Events. "Signed the lease on 2026-08-27." Immutable, timestamped, and only relevant near its time window or when explicitly recalled. Events must never overwrite each other — the exact opposite rule from facts.
3. Lessons (corrections). "Don't send files via a base64 blob, use the file marker." A lesson exists to override behaviour. It is not a retrieval item, it is closer to a runtime rule: it has to be in context before the assistant acts, not fetched after it already acted wrongly. Mixing lessons into the same top-k pool as facts means the correction loses to a semantically closer but useless fact.
4. Inferences (worldview). "The owner seems to prefer directness over hedging." These are the assistant's own conclusions. They should decay if nothing reconfirms them, because they were never verified in the first place. Nothing else in the system decays.
Why one store cannot serve all four
Give them one table and one retrieval path, and you get the failure modes in order:
- contradictory facts coexisting (no overwrite semantics)
- an old event surfacing as if current (no time weighting)
- a correction never making it into context when it matters (competing on semantic distance instead of applying as a rule)
- a shaky guess hardening into a "fact" because it got retrieved often (no decay)
Every one of those looks like "the model hallucinated" from the outside. None of them is a model problem.
What the split looks like in practice
Four tables, four write paths, four read paths:
| Type | Write rule | Read path | Lifetime |
|---|---|---|---|
| Fact | upsert on (subject, predicate) | semantic + exact key lookup | until contradicted |
| Event | append-only, timestamped | time-window + explicit recall | permanent |
| Lesson | append, importance-ranked | always injected above threshold | until superseded |
| Inference | append with confidence | semantic, confidence-weighted | decays without reconfirmation |
The upsert rule for facts is the single highest-leverage line in that table. Deterministic IDs derived from (subject, predicate) mean re-learning the same fact updates instead of duplicating — which quietly solves the contradiction problem that no amount of retrieval tuning fixes.
The "always injected" rule for lessons is the second. If a correction has to win a similarity contest to be applied, it will eventually lose one, and the user will watch the assistant repeat a mistake it was explicitly taught not to make. That is the failure users forgive least.
Cost of the split
Honest accounting: four stores mean four write paths to keep correct, a decay job, and a compaction strategy so the context block stays bounded. On a real install the whole memory layer sits comfortably in a SQLite file — around 117 MB for roughly 7,300 indexed conversation chunks after half a year of daily use. The engineering cost is in the discipline, not the hardware.
What you get back: an assistant whose knowledge of you gets sharper over months instead of noisier. Flat-store assistants degrade with volume. Typed-store assistants improve with it. That asymmetry is the entire argument.
Disclosure: I work on a self-hosted personal AI assistant, so I am not a neutral party. The longer write-up — schema, decay function, and how the four layers get injected into context — is on our blog at avelina.ai. Written with AI assistance.
