agent failed to resume wave after context window reset
Fixes a patch agent failing to resume a wave after its context window resets, because the resume path depends on the agent remembering the plan instead of reconstructing it from durable wave state. Use when a restarted agent starts over, skips work, or asks what it was doing. Not for waves with no external state store at all (build that first).
TL;DR
Resume is a reconstruction problem: after a reset, the agent has the goal and the tracker, and must rebuild an accurate briefing (what is done, what remains, what is blocked, and why) before touching any host. Implement a deterministic resume routine that reads the tracker, summarizes by state, surfaces anomalies (in-progress targets from the crashed session), and only then continues execution.
agent failed to resume wave after context window resetUse this when
- After a restart the agent re-runs completed hosts or declares the wave done early.
- Targets left in an in-progress state by the crashed session are never resolved.
- The agent spends its first post-reset steps guessing state from partial logs.
Not for this skill when
- The agent restarts cleanly between waves. Resume within a wave is the problem case.
- The tracker data itself is corrupt. Repair the store; no resume routine can rebuild from bad records.
Steps
- Ensure every target state transition is written to the durable tracker at the moment it happens, including an in-progress marker with a session ID and timestamp. Verify: the tracker shows the crashed session in-progress targets distinctly
- Build the resume briefing generator: counts by state, list of in-progress orphans, last errors, and next targets in wave order. Verify: the generated briefing matches a manual count from the tracker
- Define orphan handling: in-progress targets older than a threshold are re-verified against the host (not assumed done or not done) and moved to the correct state. Verify: a planted orphan is resolved by host evidence
- Wire resume as the standard entry point: any agent start with an active wave in the tracker begins with the briefing, not with execution. Verify: a fresh session produces the briefing before any host action
- Test with a deliberate mid-wave kill and reset. Verify: the resumed wave finishes with no duplicates, no skips, and a final report matching the tracker
Variant phrasings
resume wave after context reset reconstruct from tracker
The design phrasing.
orphaned in-progress targets crashed agent session
The edge-case phrasing.
agent starts over after restart patch wave state
The symptom phrasing.
Compatibility: Compatibility: Any LLM agent with a durable state store; briefing format should be compact enough to fit comfortably in a fresh context.
Why it happens
Context resets are normal operations for long-running agents, so resume cannot be an afterthought. The failure mode is subtle: the agent does not crash, it confidently continues from a summarized or empty memory, and its errors look like ordinary patch failures until someone correlates them with reset times. A deterministic resume routine makes the reset a non-event, which is the standard a fleet tool has to meet.
Edge cases / pitfalls
- Keep the briefing structured (counts, IDs, states) rather than prose; prose summaries are where resume errors breed.
- The session ID on in-progress markers is what separates your orphans from another live agent active targets; never clear in-progress states you cannot attribute.
- If two agents can resume the same wave, claiming rules apply here too: resume should claim the wave before executing.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_z4Y7QmJk0ovJgnTH4glrZg