Vector vs Markdown Memory: Make the Decision

PROJECT CONTEXT:
Everyone says agents need a vector database; practitioner memory systems keep shipping markdown and SQLite. The honest answer depends on scale, query style, and inspectability needs - and it can be tested cheaply on my own data.

GOAL:
Run a structured decision process: profile my memory workload, benchmark file-based vs vector recall on my real data, and commit with revisit triggers.

REQUIREMENTS:
- A workload profile: entry count, growth rate, query styles, inspectability needs
- A benchmark on my real memory data: file/lexical recall vs vector recall
- A decision matrix scoring both (plus the hybrid) on quality, ops, and debuggability
- A written decision with measurable revisit triggers

CONSTRAINTS:
- The benchmark uses my actual memories and realistic queries, not synthetic toys
- Bias to simple: vectors must beat files on my data to justify their ops cost

DEFINITION OF DONE:
- The benchmark reports recall quality for both backends on 15+ real queries
- The decision cites benchmark numbers, not fashion
- Revisit triggers are concrete (entry count, miss rate, latency)
- Whichever backend wins, memories remain human-inspectable somewhere

COMMON FAILURES TO AVOID:
- 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