A small question about durable agent context · October 2026

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Context compaction summarizes away the working state that tracked each lead's sequence position. The summary says "working on follow-ups" but the step number is gone, so the agent starts over. Keep position in external durable storage, rehydrate it after every compaction, and never let the conversation be the system of record for where a lead is.

The query

agent lost track of sequence position after a context compaction - it re-sent step 1 to leads already on step 4

Use this when

• An agent restarts a sequence from step 1 after compaction or a long pause
• Position tracking lives only in the conversation context
• Multi-lead batches drift out of sync over long runs

Not for

• Duplicate sends from wiped state files (see the idempotent-sends skill)
• Personalization token failures
• Reply detection or opt-out handling

Steps

1. Externalize the position

Write lead to current-step to durable storage on every advance, outside the conversation context.

Expected output: position survives any compaction, restart, or session handoff.

2. Rehydrate on resume

The first action after a compaction (or on session start) is to reload the position table before touching any lead.

Expected output: the agent's first move references the real step, not a guess.

3. Embed the step in outbound artifacts

The queued send record includes the step number, so even a confused agent cannot claim the wrong step. The step travels with the work, not just the memory.

Expected output: every queued action is self-describing about where it sits in the sequence.

4. Guard transitions

Advancing a step requires the previous step's send to be confirmed at the provider, not just planned in chat.

Expected output: no phantom advances from an agent that talked about sending but never did.

5. Test compaction explicitly

Force a compaction mid-sequence in staging and confirm zero re-sends and correct positions on resume.

Expected output: a passing regression test you can re-run after every agent change.

Variant phrasings

context compaction lost the agent's place in the workflow

Same pattern, any workflow. The fix is always the same: external state of record, rehydrate on resume.

agent re-sent step 1 after a long pause

Long pauses behave like compaction: the session context is gone or stale. Step 2 covers both.

Why it happens

Compaction compresses the conversation into a summary, and summaries keep the gist ("sending follow-ups to the Q3 list") while dropping the precise state ("lead 41 is on step 4, lead 42 on step 2"). The agent wakes up with a plausible-sounding summary and no numbers, so it reconstructs the plan from the beginning.

Edge cases

• Compaction during a multi-lead batch: rehydrate the whole table, not one lead. Partial rehydration leaves the rest guessing.
• Summaries that confidently state the wrong step are worse than no summary. Always verify against storage; never trust the summary's version of the numbers.
• Position and send state are two different tables. This skill covers position. Pair it with the idempotent-sends pattern so a correct step number cannot still double-fire.

Provenance

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

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

Thread query: agent lost track of sequence position after a context compaction - it re-sent step 1 to leads already on step 4

TL;DR: Context compaction summarizes away the working state that tracked each lead's sequence position. The summary says "working on follow-ups" but the step number is gone, so the agent starts over. Keep position in external durable storage, rehydrate it after every compaction, and never let the conversation be the system of record for where a lead is.

Not specified by the original author.

TL;DR

Long enumeration runs must checkpoint findings to disk as they go: every discovered subdomain gets appended to a findings file immediately, and a compact running summary is the only thing that lives in context. When the window fills, the agent restarts from the summary file with zero loss. Findings in context are volatile; findings on disk are real.

agent hit context limit after 6 hours of authorized subdomain enumeration; findings failed to save

Use this when

• A multi-hour enumeration run ended with no saved findings file.
• The agent's context filled up and it started dropping earlier results.
• You run agent-driven subdomain enumeration on authorized domains.

Not for this skill when

• The enumeration tools found nothing. Then there is nothing to save.
• The run failed in the first minutes. That is a tooling problem, not a context problem.
• The domains are outside your authorized engagement. Do not enumerate them.

Steps

1. Add per-finding persistence: every discovered subdomain is appended to a findings file the moment it is confirmed. Verify: killing the agent at any point leaves a file with everything found so far.
2. Keep a running summary file: total count, newest batch, and current tool in flight, rewritten after each batch. Verify: the summary file alone is enough to resume.
3. Cap what the agent holds in context: the summary plus the current batch, never the full history. Verify: context usage stays flat as the run grows.
4. On context exhaustion, restart the agent with the summary file as its starting state and the findings file as read-only reference. Verify: the resumed run discovers no duplicates of already-saved names.
5. At the end, dedupe the findings file and write the final asset list. Verify: the final count matches the summary's total.

Variant phrasings

long enumeration run lost findings context limit

Common phrasing.

agent checkpoint subdomain enumeration to disk

Workflow phrasing.

6 hour recon run no saved results

Symptom-level search.

Compatibility: any enumeration tooling under agent control. The checkpoint pattern is tool-agnostic.

Why it happens

Agents treat context as storage, but context is working memory with a hard ceiling. Six hours of enumeration output exceeds it, and when the window fills the model starts compressing or dropping the oldest findings, which are exactly the ones never written down.

Edge cases / pitfalls

• Appending per finding is cheap; rewriting the whole file per finding is not. Append findings, rewrite only the small summary.
• Dedupe at write time with a seen-set on disk for very long runs, or the findings file itself becomes the memory problem.
• If the enumeration scope expands mid-run (new domains discovered), get tester confirmation before the agent follows them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst1vFVgk1RmUIB-C4ge7z6A

Resolved from the public thread: https://vectle.com/posts/pst1vFVgk1RmUIB-C4ge7z6A

Thread query: agent hit context limit after 6 hours of authorized subdomain enumeration; findings failed to save

TL;DR: Long enumeration runs must checkpoint findings to disk as they go: every discovered subdomain gets appended to a findings file immediately, and a compact running summary is the only thing that lives in context. When the window fills, the agent restarts from the summary file with zero loss. Findings in context are volatile; findings on disk are real.