State and memory

"The loop remembers" hides three different mechanisms with three different lifetimes. Most confusing loop behavior — repeated work, forgotten lessons, bloated prompts — comes from mixing them up.

Three questions, three stores

Context answers: what am I doing now? Context is everything placed in front of the model for the current pass — instructions, the task, the relevant files, the recent transcript. It's assembled for the pass and gone when the pass ends. Context is expensive and small; it should hold what this pass needs and nothing else.

Working state answers: where am I in this run? The checklist with four of nine items ticked, the branch with today's commits, the list of tickets still untriaged. Working state outlives any single pass and dies with the run. It's how pass five knows what passes one through four already did — and it lives outside the model, in files or a database or the work itself, so it survives even when context gets trimmed.

Memory answers: what should change future runs? Lessons that outlive the run entirely: "the staging deploy takes ten minutes — don't call it stuck at five." "Tickets that mention invoices go to billing, whatever the tag says." Memory is written deliberately at the end of a run and read back into context at the start of future ones.

The same loop, three stores

Take a loop that triages support tickets every night:

• Context, during one pass: the triage rules plus the one ticket it's looking at right now.
• Working state, during one run: tonight's ticket list, marked triaged, failed, or remaining. If the loop crashes on ticket 40, this is what lets it resume at 41 instead of starting over at 1.
• Memory, across runs: the routing lessons learned last month that make tonight's triage better than January's.

With the three stores named, the common failure modes are easy to spot:

• Working state stuffed into context. The run's progress lives only in the transcript, the transcript gets long and summarized, and the loop re-does ticket 12. Keep working state outside the model, in something durable the next pass can read.
• Memory assumed instead of written. The loop hits the slow staging deploy, waits it out, finishes — and nothing writes the lesson down. The next run is exactly as ignorant. Memory doesn't accumulate on its own; a pass has to put it on the record.
• Memory as a landfill. If every run appends and nothing prunes, memory becomes a second context problem. Treat it like code: small, deliberate, reviewed occasionally, deleted when wrong.

One test sorts anything into the right store — ask which question it answers. What am I doing now: context. Where am I in this run: working state. What should change future runs: memory.

Do this next

Make one run leave something behind on purpose: finish a loop run, write down the one lesson that should change the next run, and load it there. Use the Quick Start to put it on the record.