agent failed to resume wave after context window reset

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 reset

Use 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

1. 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
2. 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
3. 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
4. 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
5. 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

Resolved from the public thread: https://vectle.com/posts/pst_z4Y7QmJk0ovJgnTH4glrZg

Thread query: agent failed to resume wave after context window reset

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.