agent's sequence restarted from step 1 for leads already mid-sequence - the resume logic keyed on campaign name, not...

TL;DR

The conversation is not a database. Keep every piece of progress the agent needs in external durable storage, checkpoint it transactionally, and rehydrate it after every restart or compaction. If the state only exists in context, it will be lost.

The query

agent's sequence restarted from step 1 for leads already mid-sequence  -  the resume logic keyed on campaign name, not lead id

Use this when

• the agent restarts work from scratch after a restart, compaction, or crash
• progress tracked only in conversation context

Not for

• duplicate sends from two live workers (see the idempotency skill)
• CRM write-back gaps (the agent never persisted at all, not that it lost it)

Steps

Step 1: Move the state out of the conversation

Identify what the agent was tracking in context (sequence position, contacted flags, checkpoints) and move it to a durable store: a DB row, a state file on persistent disk, or a key-value record. Context is a cache, not storage.

**Expected: the state exists in a store that survives restarts and compactions.

Step 2: Checkpoint transactionally with the work

Write the checkpoint in the same transaction as the work it describes. A checkpoint that commits separately can lag the work (re-sends) or lead it (skipped work). One transaction, one truth.

**Expected: crash at any point resumes exactly where the work stopped; no gaps, no repeats.

Step 3: Rehydrate explicitly after every restart and compaction

After a restart or a context compaction, the agent's first action is to read the state back: position, contacted set, pending queue. Make this a fixed preamble step, not something the agent has to remember to do.

**Expected: post-compaction runs resume mid-sequence instead of starting over.

Step 4: Make the state store survive the failure modes

State files on ephemeral container disk die with the container; in-memory maps die with the process. Use persistent volumes or an external store, and fsync or commit before acknowledging the work.

**Expected: killing the container mid-run loses zero committed state.

Step 5: Add the restart-and-resume test

Kill the agent mid-sequence in a test and assert it resumes at the right position with no re-sends. Run a compaction mid-batch and assert the same. These are the two failure modes; test both.

**Expected: both tests pass; restart incidents stop recurring.

Why it happens

Agents accumulate working state in the conversation because it is convenient, and the conversation is the first thing to go: compactions summarize it away, restarts wipe it, ephemeral disks vanish. Anything tracked only in context has a countdown on it.

Edge cases

• Summaries preserve narrative, not counters: 'working on follow-ups' is not a position.
• Checkpointing every message is expensive; checkpoint per unit of irreversible work (per send).
• Two writers to one state file need a lock; see the duplicate-send skill.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

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