## 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.

```text
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