Give your AI a memory so you stop re-explaining yourself

For about six months I started every AI coding session the same way: retyping the same paragraph of preferences. Use this stack. Lowercase the columns after every query. Never push straight to the protected branch. Here's how we authenticate. Here's the one weird fact about our data that will bite you if you forget it. Then I'd do the work, close the session, and the next morning the assistant knew none of it. Same paragraph again.

That's the problem this post is about: an AI assistant that starts from zero every session. If you want to give your AI a memory so it gets better over time instead of resetting, the fix is smaller and more boring than you'd think. It's a folder of small files. I've been running it long enough now to trust it, and it's changed how much I get done per session and how much I pay to get there.

The pain is real and it's expensive

Re-explaining yourself costs three things.

First, time. Every session opens with a ritual dump of context before any actual work happens.

Second, tokens. That context dump isn't free. If your preamble is 1,500 tokens and you have ten sessions a day, you're paying to send the same 15,000 tokens into the void every day, forever. It never compounds. It's pure re-derivation.

Third, and worst, consistency. When the rules live in your head and you retype them from memory, you forget some. One day you mention the column-lowercasing rule, the next day you don't, and the output drifts. You end up as the human cache — the only durable store of how things are supposed to work, manually replaying yourself into every fresh context window. That's a bad place to be. You're the bottleneck and the single point of failure.

The fix: a tiny file-based memory

Here's the whole idea. Keep a folder of small Markdown files. One fact per file. Each file gets a short, plain-language description of what it holds. Then keep one index file that lists every memory with its one-line description, and load that index at the start of each session.

The index is the trick. You don't load every memory every time — that would just recreate the bloated-preamble problem. You load the index, which is cheap, and it acts as a table of contents. When a task touches something the index mentions, the assistant pulls in that specific file. The rest stay on disk, costing nothing until they're needed.

I bucket the memories into four rough categories:

• Who the user is. Durable preferences and identity. Preferred stack, brand colors, tone rules, the ports or conventions I always use.
• Feedback and corrections. Times I said "no, do it this way instead." These are gold. They're the difference between an assistant that repeats a mistake and one that learns from it.
• Ongoing project state. Where a given project actually is right now. What's deployed, what's blocked, what the current anchor number is that everything has to tie back to.
• External references. Pointers to the canonical query, the runbook, the design kit. Not the content — the pointer plus enough context to know when it's relevant.

A single memory file is deliberately tiny:

# Report export: always visually check the PDF

Before handing any generated PDF to a user, render it and actually
look at it. Compiling is not the same as being correct.

Watch for:
- text overflowing its box
- columns colliding
- content running off the page
- stale numbers from a previous run

Learned the hard way after shipping a report with a blank page 2.

That's it. A title that reads like a claim, a couple of sentences of the actual rule, and — this matters — a line about why, usually tied to the failure that taught me. The "why" stops me from second-guessing and deleting a memory later because I've forgotten the pain that created it.

The index entry for that file is just one line:

- [PDF visual check](pdf-visual-check.md) — always render and
  eyeball any generated PDF before handing it over

What's worth remembering, and what isn't

This is the part people get wrong. The instinct is to remember everything. Don't. A memory that holds everything is as useless as no memory, because you can't find the signal and you pay to carry the noise.

My rule of thumb: remember durable preferences and non-obvious decisions. Skip anything that's already recorded elsewhere or that only matters to one conversation.

Worth remembering:

• Preferences that persist across projects. Tone, stack, naming conventions.
• Non-obvious decisions and their rationale. "We use the accounting ledger table for revenue, not the transaction table, because the transaction table double-counts multi-leg deals." That's a fact you paid for in debugging hours. Write it down.
• Corrections. Every "actually, no."
• Gotchas that will silently produce wrong output if forgotten.

Not worth remembering:

• Anything the code already says. Function signatures, file structure, what a module imports. The assistant can read the code. Don't duplicate it into memory where it'll go stale.
• Anything git history records. Who changed what, when. That's what the log is for.
• Conversation-local details. "For this one report, use last month's date range." That dies with the conversation. It's not a rule, it's a parameter.

If you can't say why a fact will still matter next month, it probably doesn't belong.

Reusable query and snippet libraries

This is a specific, high-value flavor of memory that deserves its own callout.

There's usually a small set of queries or commands you re-derive constantly. The canonical way to pull volume for a date range. The exact join that bridges two systems that don't share a clean key. The five lines that stand up a local service the way you like it.

Every time you re-derive one of those from scratch, you're paying tokens for the reasoning and risking a subtle difference from last time. So capture it once. Store the working, validated version — the one you've already proven correct — as a snippet in memory, with a note on its gotchas ("this join drops rows for older records, use the name-parse fallback for those").

Now it's never re-derived. The assistant retrieves the known-good version instead of reasoning its way to a slightly-different-and-maybe-wrong version. This is one of the biggest token savers I've found, because query derivation is exactly the kind of expensive multi-step reasoning you don't want to pay for twice.

Handoffs: resuming with zero context loss

Memory handles the durable stuff. Handoffs handle the in-progress stuff.

Long sessions fill the context window. At some point you either compact (lossy) or start fresh (also lossy, unless you prepare). The prepared version is a handoff: before the window fills, write a state file that captures exactly where the work stands, plus a ready-to-paste continuation prompt.

The state file has: what I'm building, what's done, what's next, the current blocker, the anchor number everything ties to, and the exact commands to get running again. The continuation prompt is a short paragraph I can drop into a brand-new session that says "here's the state file, here's the task, pick up from step 4."

Done right, a fresh session resumes with no re-explaining and no lost thread. The difference between "let me reconstruct where we were" (expensive, error-prone) and "read this file, continue" (cheap, exact) is enormous on a multi-day build. I trigger the handoff proactively when the window gets near full, not after it's already been auto-compacted — once context is gone, you can't hand off what you no longer have.

The discipline: keep it small and keep it true

A memory folder rots the same way a codebase does. Two failure modes:

Duplicates. You write the same rule twice with slightly different wording, and now they can subtly contradict. Dedupe when you spot it. One fact, one file.

Wrong memories. This is the dangerous one. A memory that's confidently wrong is worse than no memory, because the assistant will act on it. When you learn that an old decision no longer holds — the blocker got resolved, the better data source was found — go correct or delete the stale file immediately. Treat a wrong memory like a bug in production, because that's what it is.

I do a quick pass every so often: read the index top to bottom, kill anything that's no longer true, merge anything that's said twice. Ten minutes. It keeps the whole thing lean enough that the index stays cheap to load and every file still earns its place.

Why this ties directly to cost

Here's the money angle, because it's the reason this is worth the discipline.

The expensive thing an AI does is derive context. Reasoning out a query, reconstructing where a project stands, re-learning your conventions. Memory plus prompt caching attacks that from two sides. Memory means you stored the conclusion, so it's never re-derived — you retrieve a fact instead of paying to think it up again. Caching means the stable part of your context (the index, the loaded memories) can be served from cache on repeat calls instead of reprocessed at full price.

Put those together and the pattern is simple: you stop paying to re-derive the same context over and over. The preamble you used to retype every morning becomes a cheap, cached lookup. The query you used to reason out becomes a stored snippet. The project state you used to reconstruct becomes a handoff file. Each one converts a recurring cost into a one-time cost.

What I'd do Monday morning

Start with one folder and one index file. Don't try to remember everything on day one — that's how you build the bloated version. Instead, add memories reactively: the next time you catch yourself re-explaining something, stop and write it down as one small file. The next time you correct the assistant, save the correction. The next time you derive a query you know you'll need again, store the working version.

Within a couple of weeks you'll have a memory that reflects how you actually work, built from real friction instead of guesses. Then hold the discipline: keep it small, correct what's wrong, and let the assistant get a little better every session instead of starting over every session. That compounding is the whole point.