Module 2 · Tools, Knowledge, Memory & Research Design · scripted
Teaching Your Future Self
The developer's return
Everyone who has ever built anything knows this moment. You open a project you set aside six months ago — your own project — and begin the interrogation:
Two strangers, same questions
Same list. Same stranger. One difference: the developer suffers it occasionally. The LLM lives it EVERY conversation — each one is the six-months-later return, guaranteed, forever.
We've built the reading side of the answer: the library, the tree, the skill — training someone else prepared. Now the other direction: a conversation does work worth keeping — decisions, records, findings. In what form should it write things down, so that a future self who remembers nothing can pick them up? The hiring model serves one more time — write it as you'd write it for the brilliant new hire — but how you write it depends on what kind of thing you're writing. That is this lesson.
Match the container to the shape of the state
The central law
State comes in shapes. Each shape has a natural container:
RECORDS regular, repeating, queryable facts —
expenses, samples, measurements, submissions
→ a DATABASE (or structured files)
KNOWLEDGE irregular prose — decisions and their reasons,
findings, gotchas, how-things-work
→ a NOTES TREE (wiki-style files and folders)
ARTIFACTS the work itself — drafts, figures, code
→ FILES, in a legible layout
Records stored as prose are a landfill.
Knowledge forced into a database is a procrustean bed.
Sorting your state into its shapes is the first act of
teaching your future self.Records: the schema is the training
Start with the shape that solves itself. The task: tracking a small business's travel expenses across many conversations.
[conversation 1, September:] Log these five receipts. Tools:
sql(statement), read_file, write_file.
⟨tool_use⟩
sql(statement = "CREATE TABLE expenses (id INTEGER PRIMARY KEY,
date TEXT, vendor TEXT, amount_ore INTEGER, currency TEXT,
category TEXT CHECK(category IN ('travel','lodging','meal',
'supplies')), status TEXT DEFAULT 'logged')")⟨tool_use⟩
sql(statement = "INSERT INTO expenses VALUES (NULL, '2026-09-12',
'Hotel Alexandra', 189000, 'NOK', 'lodging', 'logged'), …")⟨tool_use⟩
write_file(path = "notes/expenses-README.md", content = "Expense
state lives in expenses.db. Amounts are øre-integers (1890.00 kr
= 189000). One row per receipt. status: logged → checked →
reported. Rows with status 'flagged' await a user decision —
never modify them silently.")[conversation 2, October:] Add these two receipts and tell me what's still unreported.
⟨tool_use⟩
sql(statement = "SELECT sql FROM sqlite_master WHERE
name='expenses'")⟨tool_result⟩
[the CREATE TABLE statement — the schema, verbatim]⟨tool_use⟩
sql(statement = "INSERT INTO expenses VALUES …; SELECT * FROM
expenses WHERE status != 'reported'")Knowledge: the methodology is the schema — and nothing forces it
Now the harder shape, because files force nothing. Two versions of the same project's accumulated knowledge:
The junk drawer
notes.md · notes2.md · misc/ · important_READ.md · meeting.md · newstuff/final-decisions-v2-old.md · untitled(3).md
Every fact the project ever learned is in there. Somewhere. Every future lookup is an excavation. The state survived — byte for byte — and is effectively lost.
The tree with a contract
CONVENTIONS.md: "One decision per file: what was chosen, why, what it rules out. Filenames: date-slug. findings/ = established facts with evidence links. gotchas/ = traps for the unwary, imperative ('do NOT use data/v2'). ADD rule: new knowledge goes in exactly one folder — if it's a choice, it's a decision. READ rule: INDEX.md first; decisions are authoritative over findings when they conflict."
The unstructured store's contract
A store's contract has two halves:
HOW TO ADD where a new item goes, what it's named,
what it must contain
HOW TO READ where to start, what's authoritative
The database enforces its contract. A notes tree enforces
NOTHING — so you must supply the contract yourself: written,
short, apple-dense… or worn, which is the next idea.Convention is an apple
Some structures don't need their contract written, because the
model has seen them a hundred thousand times. Watch what a single
ls does:
Add a settings page to this project. Tools: ls,
read_file, write_file.
⟨tool_use⟩
ls(path = ".")⟨tool_result⟩
app/ · components/ · lib/ · public/ · package.json ·
next.config.js · tsconfig.jsonThis is a Next.js application using the App Router. A settings page belongs at app/settings/page.tsx; shared UI goes in components/, helpers in lib/. I'll follow the existing naming in components/ for consistency.
Two consequences, both cheap and both essential:
State the delta — and name the ambiguities
The legibility ladder
WORN the pattern is instantly recognizable —
nothing to write
WORN + DELTA recognizable, with the deviations named —
one line each
WRITTEN novel structure — CONVENTIONS.md must carry
the whole contract
NEITHER the junk drawer. The state survives;
the knowledge is lost.
Every store you leave behind sits on one of these rungs.
Know which — and never the last.The bootstrap line
Pull it together with the file we already believe in. The INDEX.md from the tree lesson now reveals its full job: not just "start here," but naming the containers and their contracts:
INDEX.md, doing its real work
START HERE — project state, 2026-10-12.
Currently open: reviewer 2's power question (notes/decisions/2026-10-08-power-analysis.md). Do NOT use data/v2 (see gotchas/).
However much state accumulates — a thousand rows, a hundred notes, a whole application — the future self bootstraps in three reads, because every container either explains itself or carries its contract.
The closing principle
You cannot leave your future self your memory. You can leave it something better: state stored in the shape it has, in containers that explain themselves — the schema the database enforces, the conventions the notes declare, the layout the model knows on sight. These are the letters you write to someone who will remember nothing — and who is you.
- Sort the state your own research project accumulates into the three shapes. Which shape is currently living in the wrong container — and what does every lookup cost you because of it?
- The junk drawer contained every fact the good tree contained. Say precisely what was lost, in the currency of tokens and judgment — and why "we can always search it" doesn't rescue it.
Design the state architecture your agent leaves behind. (1) The shape inventory: its records, knowledge, artifacts. (2) For the records: the schema, plus the five-line training note. (3) For the knowledge: CONVENTIONS.md in ten lines or fewer — both halves of the contract. (4) For the artifacts: name the convention worn, and write the delta line. (5) The INDEX.md that names all of it. Then the acid test: hand everything, cold, to a fresh conversation with one instruction — "read INDEX.md first" — and record what it could and couldn't continue.