Every LLM call is stateless. No memory of yesterday. Each prompt starts from zero.
So how do you build on previous work when your collaborator has amnesia?
Idempotency. Not the HTTP kind—deeper: given the same context, produce the same output, regardless of how you arrived there.
Except that’s a lie. LLMs are probabilistic. Temperature, sampling, moon phase, whatever. Same input, different outputs. But if you manage context deliberately enough, the variance stops mattering. Mostly.
“Make it faster.” Reduce latency? Increase throughput? Cache results? The model guesses. Guesses wrong. You correct it. Now your context has both the mistake and the correction—noise you’ll be carrying forever.
English has an error margin. The gap between what you meant and what landed creates drift. Over a long conversation, drift compounds. I’ve had sessions where the model confidently referenced decisions we never made, hallucinated from some earlier misunderstanding that got half-corrected three times.
Better prompts won’t save you. Structure might.
A schema is a contract. Pins down what things are, what values are valid. When intent goes through a schema, ambiguity collapses:
player:
movement_speed: 12 # was 8
“Make the player faster” → one line, no interpretation. The schema is what changed.
Unrolling: reconstructing state from a minimal representation.
Like database normalization, kind of. Store canonical facts, derive everything else. Instead of 300 messages of back-and-forth with corrections and tangents, a 50-line spec that captures what you actually decided.
The conversation refines the spec. The conversation is not the spec.
New session reads the spec, produces consistent results. How you got there doesn’t matter. The spec is the checkpoint. (This is the part I always forget to actually do, and then I pay for it two days later.)
Structure projects so any session can unroll to the same state. Path doesn’t matter, destination does.
Anchor documents. One file captures current state. CLAUDE.md, SPEC.md, whatever you want to call it. Every session reads it first. Decisions update it.
# Current State
- Combat: turn-based, action points
- Status effects: poison, stun, haste (done)
- Next: equipment system
# Constraints
- No RNG in competitive modes
- Effects must be visually distinct
Deltas. Prompts as state transformations. Current, goal, constraints. Same delta on same state → same result. History not required.
CURRENT: Player has health, no shields
GOAL: Add regenerating shields
CONSTRAINTS:
- Shields absorb before health
- Regen pauses 3s after damage
Checkpoints. Crystallize progress into artifacts. A commit. An updated spec. A summary appended to the anchor doc. Next session starts from there.
I used to think this was overkill. Then I lost a week of design decisions because I closed a browser tab.
Self-contained. No “as we discussed” references to conversations that don’t exist anymore.
Structured enough to parse reliably. Minimal enough that key constraints aren’t buried on page 47.
What, not how. “Damage applies to shields first” survives refactoring. “The applyDamage() function on line 247” doesn’t.
Test it: start a fresh session with just the context docs. Does it produce work consistent with yesterday’s session? Hand the spec to yourself two weeks from now. Is it enough?
Idempotent context compounds.
Early sessions establish vocabulary. Later sessions build on it. “Boss rooms lock until the encounter resolves”—one sentence that implies door states, resolution conditions, room tracking. Dozens of implementation decisions, all consistent. But only if you wrote it down somewhere the model can find.
Poor context is fragile. Works until some session makes an incompatible decision and you don’t notice for three days.
For one-off tasks, ignore all of this. “Write a regex for emails” doesn’t need context management. For exploration, keep it loose—premature structure calcifies bad decisions.
For anything you’ll return to? This is the difference between building on previous work and rediscovering it every time you open a new tab.