LoopWorkbench
intermediatepractical-guidesloop-engineeringstatememorylong-running

Chapter 6 of 8

State & Memory: The Sixth Block

Why every long-running loop depends on memory that lives on disk, not in the conversation — and what to write down.

State & Memory: The Sixth Block

The five building blocks act. The sixth one remembers. It sounds too dumb to matter — and it's the single thing every long-running loop depends on.

The problem it solves

A model forgets everything between runs. The conversation context dies when the session ends. So if a loop runs every morning, it has no memory of what it tried yesterday, what passed, what's still open — unless that memory lives on disk, not in context.

"The agent forgets, the repo doesn't." — Addy Osmani, Loop Engineering

What state looks like

State can be a markdown file, a Linear board, a SQLite DB — anything that lives outside any single conversation and holds what's done and what's next.

<!-- loop-state.md — the spine of the morning triage loop -->

## Open
- [ ] auth/login.ts — flaky test `expires_token` (found 2026-07-05, attempted fix reverted)
- [ ] export/csv.ts — memory leak on large exports (found 2026-07-06, not yet attempted)

## In Progress
- [ ] deps/update — worktree `deps-update`, sub-agent drafting, awaiting review

## Done (this week)
- [x] billing/webhook.ts — retry logic added (PR #4821, merged 2026-07-04)
- [x] api/rate-limit — bucket size tuned (PR #4819, merged 2026-07-03)

Why this is the spine

Tomorrow morning's run reads this file and picks up where today stopped. It doesn't re-triage the bug it already fixed. It doesn't re-attempt the fix that got reverted — it either tries a different approach or escalates to you.

Without state:

  • The loop re-discovers the same issues every run.
  • It re-attempts fixes that already failed the same way.
  • You can't tell what it actually did while you were away.

With state:

  • The loop compounds — each run builds on the last.
  • You can audit it — "what did the loop try, what passed, what's open" is a file you can read.

Write the state the way you'd write a handoff doc

The state file is a handoff from yesterday's loop to today's loop (and from the loop to you). Write what a junior engineer would need to pick this up: what was tried, what the result was, what's blocked and why. If you can't read the state file and understand the current state of the work, neither can the next run.

State vs. context

Don't confuse state with context.

  • Context is what the model sees during a run (the prompt, the tool outputs, the conversation). It dies when the run ends.
  • State is what persists between runs (the markdown file, the ticket board). It survives.

A loop that keeps its working memory in context alone will forget everything overnight. A loop that writes its conclusions to state before it exits will remember. Compact aggressively during a run; persist conclusions to state before you stop.

What this block contributes to the loop

State is what turns a loop from a series of one-shots into a durable system. The five blocks make a loop capable; state makes it continuous.

Next: One Full Loop — wire all six blocks into a single loop that runs overnight.

Prerequisites