Incident note

The agent died. The work did not.

Five long-running readers in one week, three killed by a watchdog. One of them had already written ninety percent of its output to disk, and the parent finished it in a single pass. The difference between those outcomes is one line in the instructions.

The instruction that pays for itself

Write and forget. After every item -- every document, every page, every record -- append the notes to disk and drop the content. Never carry more than one item forward, and never batch the writes to the end.

It feels wasteful. It is the only reason a killed run leaves anything behind. An agent that holds its findings and writes once at the end leaves an empty file when it dies, and the whole run has to happen again.

What to do when one dies

Look at the output file before doing anything else. Re-spawning is the expensive reflex and it is usually wrong.

One of ours was killed twice on the same source. The second time, its file already held seventeen items of notes -- 297 lines. The parent read the file, wrote the summary and the conclusion itself, and routed the result. Nothing was re-read and nothing was paid for twice.

What is missing after a stall is almost always the summary, not the reading. A parent can write that in one pass from notes that are already complete.

Which agents die

The pattern across five runs was consistent, and it was not the one we expected.

The reader that finished cleanly was working through 43 items, all of them reachable. The two that died were on sources with large enumerations -- one reported 760 items against 172 that could actually be listed.

It is enumeration cost, not per-item cost, that runs a reader out of room. Paging a large catalogue, deduplicating ids, and holding the index is what fills the window before the real work starts. A big back catalogue needs its window narrowed before the run, not during it.

The instructions that keep a long reader alive

  1. One item per turn. Never two in the same turn, however small they look.
  2. Append after each one, with a file tool or a script file. Not a shell heredoc -- quoting breaks it, and that is exactly how one of ours died.
  3. Notes, not summaries. Ten to twenty lines of mechanism per item. You are extracting, not reviewing.
  4. Narrow the window first. Decide the date range, the format and the priority order before the first read, and record what you excluded and why.
  5. Record the true count before any verdict, including zero, and say plainly when the reachable set is a subset of the reported one.

The general rule

Durability is the most-ignored detail in long autonomous work. A fifty-step task that fails at step forty-seven restarts from zero unless each step wrote its result down. That is not a resilience feature you add later -- it is one line in the prompt, and it decides whether a failure costs you an hour or a minute.

Where this came from

This page is one section of multi-agent-finisher, one of the Agent Skills in this set. The skills are plain SKILL.md markdown -- no install, no runtime, no dependency. Drop a folder into ~/.claude/skills/ and invoke it by name.

Four of them are free and need no signup: github.com/resilientmindset01-commits/claude-code-skills-free

Written by ResilientMindset. Not affiliated with, endorsed by, or sponsored by Anthropic. Every claim about Claude Code on this page was checked against Anthropic's own documentation on the date shown.