Give your coding agent a memory that lasts

The problem, stated precisely

Every capable model forgets you the moment the window closes. That is not a flaw anyone is going to fix for you, because context is priced per token and your history is not. The fix is architectural and it sits outside the model: a store you own, a way to search it that actually finds things, and a discipline about what goes in.

Retrieval-augmented generation solved the first half of this years ago and is widely misunderstood as the whole answer. It is not. A memory that only grows is a memory that gets worse with use, because precision falls as the pile rises. The hard part was never storage or even search. It is deciding what deserves to be remembered, and removing what no longer does.

This method is the architecture running behind this laboratory's own systems. At the time of writing that store holds over seventeen thousand memories, answers in under a hundred milliseconds, and is consulted by four different agents on every substantive question. Everything below is what it actually does, including the parts that went wrong first.

What you will have built A single-file database with hybrid keyword and semantic search, an extraction gate that keeps noise out, automatic decay and consolidation, and a tool interface any agent can call. It runs on your machine, costs nothing to operate, and survives you changing model provider.

The code is in the kit, and it runs memory/memory.py is this method in fewer than four hundred lines of standard library Python: the schema, the triggers, hybrid search, fusion, the write gate, duplicate merging and decay, with nineteen tests. It keeps its vectors as JSON and compares them in Python, which is fine while the store is small. reference/rrf.py is the same search with the vectors in sqlite-vec, as step five describes, with twenty-six tests of its own. python3 memory.py --demo needs nothing installed. Read the method here; take the code there.

Who this is for You can install software and read a schema. You do not need machine-learning background; nothing here trains anything. Budget a weekend for steps one through six, which is the point where it becomes useful, and a second pass later for the rest.

1. Decide what the memory is for

Do this before you write a line, because it determines the schema and the discipline, and retrofitting either is painful.

A memory serves exactly three purposes. It lets the agent recall something you said once. It stops you repeating yourself. And it lets the system get better over time by remembering what worked. Write down which of the three matters most to you; when you later have to decide whether something is worth storing, that sentence is the test.

The failure mode to name now: treating the store as a diary. A session log has no value in a week, but it will outrank a genuinely useful fact in every search you run for the rest of the year. More on this at step seven, which is the step that actually determines whether this works.

2. Choose the store — one file, no server

Use SQLite. It is a single file, needs no daemon, handles millions of rows, and is on every machine you own. A memory system you have to operate is one you will abandon.

Resist the vector database. A dedicated vector store is the right answer at tens of millions of vectors and the wrong answer at every scale you will personally reach, because it adds a service, a network hop and a second source of truth for data that belongs beside your text.

# the whole installation
python3 -c "import sqlite3; print(sqlite3.sqlite_version)"

If that prints 3.35 or above you have everything the next four steps need.

3. The schema — one narrow table

Keep the core table narrow. Everything here earns its place. This is the table in the kit's reference/schema.sql, column for column.

CREATE TABLE memory (
  id           INTEGER PRIMARY KEY,
  content      TEXT    NOT NULL,              -- one fact, true on its own
  category     TEXT    NOT NULL,              -- fact | decision | skill | reference
  tier         TEXT    NOT NULL,              -- semantic | procedural | episodic
  importance   REAL    NOT NULL DEFAULT 0.5,  -- 0..1, earned and decaying
  tags         TEXT    NOT NULL DEFAULT '[]', -- json array; project scope
  source       TEXT,                          -- which agent or person wrote it
  embed_model  TEXT,                          -- which model made its vector
  created_at   TEXT    NOT NULL,
  updated_at   TEXT    NOT NULL,
  access_count INTEGER NOT NULL DEFAULT 0     -- step 8 needs this
);

One fact per row. The discipline that makes retrieval work is not in the search code, it is here. A row holding three facts matches weakly on all three and is returned confidently for none.

importance must be earned. The temptation is to write 0.9 on everything you store, and the moment you do the field stops carrying information. Reserve the top of the range for things that would change a decision.

tags carries scope. If you work across several projects, a project tag is what stops one project's patterns bleeding into another's answers. This sounds fussy until the first time an agent confidently applies the wrong codebase's conventions to your work.

embed_model says which model made the vector. Vectors from two models are not comparable, and step five explains why that failure is silent. This column is how you find the rows to re-embed when you change model.

A gotcha that will cost you a day

Many 2026 open models ship as hybrid reasoning checkpoints with thinking enabled by default. Handed a long system prompt, such a model can spend its entire output budget reasoning and return an empty response, with a status that merely says it stopped because it ran out of room.

If your extraction step suddenly returns nothing, this is why. Disable thinking explicitly in the request, and assert that the reasoning field came back empty rather than trusting that your flag was honoured — some client libraries drop that parameter silently.

Extraction does not need a reasoning model. It needs a fast, obedient one.