Step 1 of 3
Profile the workload honestly
Scale and query style decide this - measure both.
Profile my memory workload. Quantify: current entry count and average length; growth per week (from session frequency); query styles from real usage - what fraction are exact lookups (names, errors, commands) vs paraphrases vs broad topical asks (sample 20 real queries if logs exist, else write 20 realistic ones); latency needs; and inspectability requirements (do humans read/edit memory? does it live in git?). Research context: practitioner systems report plain files serving well into the hundreds of entries when queries skew exact; vector value concentrates in paraphrase-heavy, large-store recall. Deliver the profile with the 20-query sample labeled by style.
Expected after this step
A quantified workload profile with a labeled query sample.
Should not happen
- ✕Adopting a vector stack for 80 memories a grep would search perfectly
- ✕Dismissing vectors while users paraphrase every query and lexical misses them
- ✕Benchmarking on toy data that flatters one side
- ✕A decision without triggers, silently outgrown a year later
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Adopting a vector stack for 80 memories a grep would search perfectly
- !Dismissing vectors while users paraphrase every query and lexical misses them
- !Benchmarking on toy data that flatters one side
- !A decision without triggers, silently outgrown a year later
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The query sample is invented to be interesting. Pull real queries from transcripts or recall logs - the exact/paraphrase ratio is the single most decision-relevant number here.