Essay · August 7, 2026
Your memory file is a tax you pay on every prompt
Every agent accumulates knowledge that ought to outlive the session: how this repo wants to be branched, which build command is the real one, the correction you made three weeks ago that you never want to make again. The default home for all of it is a memory file, and a memory file has one property that quietly ruins it. It loads on every turn.
The tax
A memory file is unconditional. It costs the same whether you asked the agent to ship a release or fix a typo. Write 5,000 tokens of hard-won operating knowledge and you have signed up to pay 5,000 tokens on every prompt for the rest of the project, including the ones where none of it applies.
That's the visible cost, and it's the smaller one.
The real damage is attentional. Instructions in a long file compete with each other. Add the twentieth rule and the first nineteen get slightly harder to follow, because the model is now allocating attention across twenty things that all claimed to matter equally. A memory file that grows monotonically doesn't just get expensive. It gets less obeyed, rule by rule, and the failure is invisible: nothing errors, the agent just quietly stops honoring something you wrote down two months ago.
So memory has a perverse shape. The more diligently you maintain it, the worse it performs. Most people notice this as "the agent ignores my CLAUDE.md" and respond by adding emphasis, capital letters, and IMPORTANT tags, which is treating a capacity problem as a compliance problem.
The question that sorts it
There's one test for any durable fact you're about to write down:
Does this apply to every turn, or only some turns?
Every-turn facts genuinely belong in memory. Who you are. What you're standing-authorized to do without asking. Global constraints that hold no matter what the task is. These are cheap, few, and correctly unconditional.
Some-turn facts are almost everything else, and they are miscategorized by default. How to cut a release. What this project's CI conventions are. How to handle a return, a rights audit, an App Store submission. Each one is critical on the day it applies and pure overhead on every other day. Put it in memory and you pay for it constantly to use it occasionally.
A skill is the same information with a condition attached. The agent holds the name and the description. The body stays on disk until a request matches. You pay a line to have it available and the full price only when you use it.
The part that surprised me
I expected this to be a cost optimization. It turned out to be a quality one, for a reason I didn't anticipate.
Memory forces compression. Because every line is billed on every turn, you write the shortest thing that might work. "Always use worktrees." That's what fits. What you actually know is longer: why worktrees, which directory convention, the two places worktrees hide, why the session registry lies about which ones are live, what a squash-merged branch looks like when you're deciding whether to delete it. All of that gets cut, because you cannot afford six paragraphs in a file that loads unconditionally.
A skill has no such pressure. Its body is read only when relevant, so length is nearly free. You can write the failure modes, the exact commands, the counterexample that cost you an afternoon, the check that looks redundant and isn't. The knowledge doesn't just move. It gets to be complete for the first time.
That inverts the usual tradeoff. Normally more detail means more cost. Here, moving detail behind a trigger means you can afford more of it, and the agent gets a better version of the rule at the exact moment it needs it, instead of a compressed version at all times.
What else you get
Once knowledge lives in a file with a name and a boundary rather than in an undifferentiated memory blob, ordinary software practice starts applying to it:
- It diffs. You can see what changed about how the agent works, and when.
- It reviews. A rule in a skill can be argued with before it ships. A line appended to memory at 1am cannot.
- It travels. A skill installs on another machine, or for another person. Memory is per-machine sediment.
- It can be deleted. Removing one skill removes one behavior. Removing one line from a 200-line memory file is a guess about what else depended on it.
The practical move
Open your memory file and read it as a list of conditions rather than a list of facts. Most entries will start with an implicit "when." When I'm deploying. When it's this repo. When the task involves the App Store. Each of those whens is a trigger description, and everything after it is a skill body that has been living in the wrong place, compressed, and taxed on every prompt since you wrote it.
What's left when you're done is short, unconditional, and actually followed. Which is what a memory file was supposed to be.