choose-memory-paradigm

name	choose-memory-paradigm
description	Decide whether to build a memory system at all, and if so which paradigm — raw context, flat retrieval, LLM-extraction or agentic — behind a mandatory baseline-first gate. Reach for this before any memory design work.

Skill: Choose a memory paradigm

Decision 1 of the six-decision spine — what earns a write? The cheapest store is none, and the second cheapest is a keyword index. This skill exists to make both of them compete before anyone builds anything (§3 #2).

The order below is not a suggestion. Steps 2 and 3 are stops: if either is unmeasured, the answer to "which paradigm?" is "you cannot know yet" — not a paradigm. Traverse Tree 1 in the decision trees alongside this.

Step 1 — Name the durable question

Write one sentence: what must survive this session, and which later session reads it? If you cannot name the reader, you are designing a log, not a memory system.

Then separate two things that get conflated constantly:

You have	You need
A fact a later session must recall	Memory — this skill
A prompt that is too long right now	Context pressure management — see map-memory-surface

Context editing and compaction shrink a live prompt. Neither is durable. Memory is what has to survive both.

Step 2 — STOP. Prove the no-memory baseline loses

Run your real queries with no injected history at all and record accuracy and cost. This is the stateless baseline.

• Never measured? Stop here. Build the golden set first — build-memory-eval is the procedure.
• No-memory is good enough? Do not build memory. Write that finding down; it is the most valuable result this skill produces.
• No-memory loses? Continue — and carry the measured gap forward, because it is the only thing that will later justify the write path.

Honest caveat on this baseline: stateless is not the same job. It cannot answer a memory-dependent query at any accuracy. Use it to size the gap, never as the amortization baseline — the calculator prints a boxed warning for exactly this reason (§3 #1).

Step 3 — STOP. Prove flat lexical retrieval loses

Run deterministic top-k retrieval over the same history — BM25 or an embedding index, no LLM in the construction path — and record accuracy and cost.

This step exists because of the single most uncomfortable result in the literature: in the published benchmark suite, plain lexical retrieval scored the highest accuracy and the lowest cost per correct answer of every system measured, LLM-mediated ones included. Conditions, figures and source: the paradigms knowledge file.

• Flat retrieval wins? Ship Paradigm II and stop. It amortizes almost immediately.
• Flat retrieval loses? Now — and only now — you have a memory problem. Continue to step 4.

Any memory proposal that skips this step is selling something, including this one.

Step 4 — Classify along the four axes

The four axes and the four paradigms are different fours. Classify the candidate design on all four axes before naming a paradigm:

Axis	The question	Why it decides cost
Construction	Is an LLM in the write path, and does it run per-event or in a batch?	This is where the money goes (§3 #1)
Storage	Flat rows, a vector index, a graph, or in-context blocks?	Sets the growth slope and the erasure residue
Retrieval	Deterministic top-k, or a model deciding what to fetch?	Sets per-query latency and variance
Mutability	Append-only, overwrite, or reconcile-on-write?	Decides who resolves contradictions, and when

Step 5 — Name the paradigm and the bill it pays

Paradigm	What it does	The bill it pays
I — raw context	Prefill the full history at every query	Zero construction cost; per-query cost grows with the history
II — flat retrieval	No LLM in construction; deterministic top-k	Cheap build; amortizes almost immediately
III.a — structure-augmented	LLM-mediated extraction into a graph or index	Large offline batch indexing traffic
III.b — consolidating fact store	LLM-mediated extraction into a mutable fact store	Sequential per-event traffic on the write-loop critical path
IV — agentic	The model decides when to write, which tool, and whether the evidence suffices	Per-event traffic plus a read of the growing store before every write — the only family with a super-linear cost slope

The III.a / III.b split is load-bearing, not pedantry. It predicts the shape of the write traffic, which is what decides whether your build is a nightly batch job or a latency tax on every single turn. Named examples per row: the paradigms knowledge file.

Step 6 — Amortize against the baseline you just beat

Take the baseline that lost in step 2 or 3 and put a break-even number on the paradigm you chose. Hand off to budget-memory-costs, which drives the calculator amortize mode.

If there is no break-even, the only argument left is accuracy — and then the unit is cost per correct answer, which needs the accuracy half from build-memory-eval.

Step 7 — Record the decision, not the conversation

A paradigm chosen in chat is not a decision. Write down, in the memory design record: paradigm · the baseline that lost · the measured gap · break-even query volume · who decided · the date. The next three skills all read from that record.

Guardrails

• Do not pick a paradigm from a leaderboard. Every published memory-system ranking is self- or competitor-reported (§3 #8). Rank on your own data or do not rank.
• Do not carry a benchmark number into a client deliverable without its conditions. The measured results in this plugin come with a fixed query count, a fixed model, and a fixed corpus; strip those and the number becomes a claim it cannot support.
• Every external figure gets a source URL and a retrieval date, or an explicit unverified marker (§4).

Output

A paradigm decision with both baselines measured and beaten, the four-axis classification, the bill that paradigm pays, and a break-even against a named baseline. Traverse Tree 1 in the decision trees.