agent failed after context overflow wiped wave state mid rollout

TL;DR

If wave progress lives only in the agent context, a long rollout guarantees amnesia: context fills, gets summarized or reset, and the agent re-patches finished hosts or skips pending ones. Move the source of truth out: a wave state file or table with per-host status that the agent updates after every target and re-reads at the start of every step batch. The agent context becomes a cache, never the record.

agent failed after context overflow wiped wave state mid rollout

Use this when

• After long runs the agent repeats work on hosts already patched, or claims hosts are done that are not.
• Failures correlate with rollout length, not with particular hosts.
• The agent plan and checklist exist only in its prompt history.

Not for this skill when

• The agent loses state because the tracker itself is being written incorrectly. Externalizing will not help until the writes are fixed.
• The rollout is small (a handful of hosts). Context loss is unlikely to be the cause.

Steps

1. Create the external wave state: one record per target with status, attempts, last error, and timestamps, in a file or table the agent can read and update atomically. Verify: the state store exists and a test write and read round-trips
2. Change the loop: before each batch, read state; after each target, write its result immediately. Verify: a mid-wave kill loses at most the in-flight target state
3. Add a resume entry point that reconstructs the briefing purely from the state store (counts by status, next targets, recent errors). Verify: a fresh agent session given only the store produces a correct status summary
4. Keep context lean: the agent carries summaries and the current batch detail, not the full history of every host log. Verify: context use per step stays roughly flat across a long test wave
5. Run a full wave with a forced restart in the middle. Verify: no target is double-patched or skipped, and the final report matches the state store

Variant phrasings

agent context overflow lost state externalize wave tracker

The architecture phrasing.

durable state file agent rollout resume

The implementation phrasing.

agent repeats work already done long task amnesia

The symptom phrasing.

Compatibility: Compatibility: Any LLM-driven agent framework; the store can be JSON on disk, sqlite, or the patch system own API.

Why it happens

Agent context is a working memory with a hard size limit and lossy compression. A patch wave is exactly the workload that breaks it: hundreds of similar steps whose details matter individually (which host, which KB, which error) but look summarizable in aggregate. Any design where the only copy of per-target state is in the transcript will eventually corrupt the wave; the transcript is for reasoning, the tracker is for truth.

Edge cases / pitfalls

• Atomic writes matter: a state file corrupted by a mid-write kill recreates the amnesia problem in a new form. Write to temp and rename, or use a database.
• Summaries the agent writes for itself should be generated from the store, not maintained separately, or the two will diverge.
• This pattern also gives humans a live dashboard for free: the store is the progress page.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tLBi5IqHqAGIV6RJ-NDs3w