Give Your Long Jobs a Handoff File

An AI agent has a brutal amnesia problem: when a run ends, the context is gone. The next run wakes up knowing nothing about what the last one did — what it finished, what it was in the middle of, what it already tried and abandoned. If you want a loop that runs on a schedule or survives an interruption to be continuous rather than starting from zero every time, its memory can’t live in the conversation. It has to live on disk, in a file the job reads first and writes last. Think of it as the handoff note for a night shift you never watch.

The next run inherits nothing but the file

This is the core constraint, and it’s easy to underestimate. Whatever the agent “knew” during a run evaporates when that run ends — the working context clears, the session dies. So the only thing tomorrow’s run can rely on is what today’s run wrote down. Not what it did, not what it figured out, not what it decided to avoid — only what it committed to durable storage. If it didn’t write it down, it didn’t happen, as far as the next run is concerned.

Treat the loop like a night shift you’ll never observe. You’re judged entirely by the note left on the desk at nine. So design that note first, and most of the loop designs itself.

That reframing — design the handoff note first — is the trick. Once you know exactly what the next run needs to pick up cleanly, you know what each run has to produce, and the rest of the loop is in service of leaving a good note.

One file, four sections

The handoff doesn’t need to be elaborate. A single file, checked in alongside the work, with four sections carries almost all the value:

• Done — what’s finished, so the next run doesn’t redo it.
• In progress — what’s mid-flight, with enough detail to resume it rather than restart.
• Next — the queue of what to do, so the loop always has an unambiguous next move.
• Never — the things the job must not touch, no matter what it concludes.

Read first, write last. Every run opens by loading this file to learn where it stands, and closes by updating it with what it just changed. That single discipline is what turns a scheduled job from an amnesiac that repeats itself into one that genuinely makes progress across runs.

It’s what stops the two dumbest loop failures

A handoff file directly prevents the two most common ways an unattended loop wastes itself. First, repeating the same mistake forever: without a record of what it already tried, a loop will cheerfully re-attempt the thing that didn’t work, every run, indefinitely. The “Done” and “In progress” sections are its memory of what’s been attempted. Second, losing work to an interruption: a run that gets killed halfway — a timeout, a crash, a deploy — comes back and resumes from the last written state instead of starting over. It’s the antidote to the silent-death and directionless-drift failure modes that kill loops that have no memory of where they were.

The “Never” list is a cheap, durable guardrail

The section people skip is the most valuable one for safety. A “Never” list — “do not modify this directory,” “do not touch production,” “do not delete anything” — is a standing constraint that survives every run, written in the same file the loop is guaranteed to read. It’s a persistent blast-radius limit that costs one paragraph, and it does the job of a panic button’s guardrails without any code: the loop reads its own boundaries at the start of every run and can’t quietly forget them between sessions.

Progress state is different from knowledge

This pairs with, but is distinct from, giving an agent durable context about your conventions. That kind of memory is knowledge — how your system works, the rules, the data model — the stuff that’s true across every run. The handoff file is progress — where this particular job is in this particular effort. One tells the agent how to work; the other tells it where it left off. A capable unattended agent needs both: stable knowledge so it doesn’t relearn the basics, and a living handoff so it doesn’t lose its place. They defeat the same enemy — the empty context at the start of every run — from two directions.

None of this is AI-specific, really. Any long-running or resumable process — a migration, a crawler, a batch job — benefits from an external state file it reads first and writes last. The agent case just makes the amnesia total and the lesson unavoidable. Design the handoff note first, keep it honest, and a loop that would otherwise start from nothing every morning instead shows up already knowing where it stood. If you’ve built loop state that made an agent actually continuous, I’d love to hear how you structured it.