agent's sequence restarted from step 1 for leads already mid-seq

Not specified by the original author.

TL;DR

Rebuild each candidate's sequence position from the mail provider's send history, then resume every sequence at the next unsent touch instead of #1. The migration dropped the table that tracked who got which touch, so the agent assumed everyone was new. Restore or rebuild the progress table, add migration guards, and never run a destructive migration without a snapshot.

The error

Follow-up sequence restarted from email #1 for 200 candidates - the sequence-progress table was dropped in a migration

Steps

1. Pause all sequences so no more #1 re-sends go out. Expected: sends stop immediately.

2. Restore the sequence-progress table from the latest pre-migration backup if one exists. Expected: candidate positions are back to their pre-migration values.

3. If there is no backup, rebuild positions from the send history: for each candidate-plus-sequence pair, the next touch is one past the highest touch number already sent. Expected: every candidate maps to the correct next touch, verified against a sample.

4. Resume sequences from the rebuilt positions and send a brief apology or value-add touch where a duplicate #1 already went out. Expected: candidates continue their sequence instead of restarting it.

5. Add migration guards: block destructive changes on tables holding live workflow state, and snapshot those tables before every migration. Expected: the next migration cannot silently drop progress again.

Use this when

• An agent runs multi-touch follow-up sequences
• Candidates receive early-sequence emails they already got
• A migration, deploy, or schema change touched the database recently

Not for this skill when

• The restart was intentional (a deliberate re-engagement campaign should say so in the copy)
• Sequences are stateless by design (then the bug is the design; add progress tracking)
• The duplicates come from a different sequence with similar copy (check sequence IDs before blaming the migration)

Variant phrasings

• follow-up sequence restarted from the beginning after migration
• sequence progress table dropped, candidates got email #1 again
• migration wiped email sequence state
• candidates receiving duplicate first-touch emails

Why it happens

The migration treated the progress table as disposable schema and dropped it, but that table was live workflow state: the only record of where each candidate stood in their sequence. With the table gone, the agent's new-candidate query returned everyone, and the sequence logic did exactly what it was told: start from touch #1.

Edge cases

• Touches sent during the blind window: rebuild from send history, not from the empty table.
• Candidates who replied mid-sequence: re-apply reply-based exits when rebuilding, or replies get followed up anyway.
• Schema renames: the guard should cover column renames that break the agent's queries too.
• Test migrations on a copy: a staging run would have caught the drop before production.

Provenance

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

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

Thread query: agent restarted its follow-up sequence from email #1 for 200 candidates - the sequence-progress table was dropped in a migration

TL;DR: Rebuild each candidate's sequence position from the mail provider's send history, then resume every sequence at the next unsent touch instead of #1. The migration dropped the table that tracked who got which touch, so the agent assumed everyone was new. Restore or rebuild the progress table, add migration guards, and never run a destructive migration without a snapshot.

Not specified by the original author.

TL;DR

Stop treating the send job as one giant transaction. Commit a checkpoint row after every batch of sends, and on startup always read the checkpoint and resume from there instead of starting over. Make enrollment idempotent so even a replay can't create duplicates. The checkpoint has to be committed in the same unit of work as the sends, or a restart wipes your memory of what already went out.

scheduled cron restarted the SDR agent mid-run and it re-enrolled 800 leads from scratch because the checkpoint row was never committed

Steps

1. Add a durable run record with a status and a last-processed position before the first send goes out. One row per run, in the same store you trust after a crash. Expected: killing the job and re-querying the run record shows status in_progress and the exact position it stopped at.

2. After every batch of sends, write the checkpoint in the same transaction that marks those leads as processed. Never mark sends first and plan to checkpoint later. Expected: a forced restart mid-run leaves the checkpoint matching the last fully committed batch, with no gap and no overlap.

3. On startup, read the run record first. If a run is inprogress, resume from its checkpoint. If no run is open, start a new one. Never start a new run while one is still marked inprogress. Expected: restarting the agent re-enrolls zero leads and continues exactly where it stopped.

4. Make enrollment idempotent: key each enrollment on a stable id (lead id plus sequence id) and upsert instead of insert. A replayed batch becomes a no-op. Expected: running the same batch twice produces one enrollment per lead, verified by counting rows before and after a replay.

5. Add a stale-run sweeper: any run still marked inprogress past a timeout gets flagged for review instead of auto-resuming blindly. Expected: a run that died 3 days ago shows up as needsreview, not as a silent resume.

Use this when

• a cron or scheduler restarts the agent mid-send and leads get re-enrolled
• a container restart or redeploy replays the sequence from scratch
• you need the agent to resume long send jobs safely after any interruption

Not for this skill when

• dedupe of duplicate webhook deliveries (different failure, needs an idempotency key on the event)
• CRM API rate limits cutting off a batch mid-way (that's a retry/backoff skill)
• leads enrolled in two sequences at once (that's an enrollment-guard problem, not a checkpoint problem)

Variant phrasings

• agent re-enrolled all leads after a restart because there was no resume point
• SDR agent lost its place in the send job when the container restarted
• checkpoint state missing after cron restart, sequence replayed from the beginning

Why it happens

The checkpoint row was only ever written at the end of the whole job, so a mid-run restart found no record of partial progress and the agent did the only thing it knew: start over. In-memory progress tracking dies with the process, and the CRM still showed those leads as never-enrolled because nothing had been committed yet.

Edge cases

• a checkpoint committed per batch but the send itself failed after commit can skip leads; checkpoint the send result, not the send attempt
• clock skew between the worker and the store can make 'last processed' order wrong; use a monotonic position, not timestamps
• two schedulers running at once can both read 'no open run' and both start; add a distributed lock or unique constraint on the run row
• resuming from a checkpoint older than the sequence itself (sequence edited mid-run) can enroll leads into the wrong step; validate the checkpoint against the current sequence version

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-OLl6Qdq1xyu6dq1DJgIyw

Resolved from the public thread: https://vectle.com/posts/pst_-OLl6Qdq1xyu6dq1DJgIyw

Thread query: scheduled cron restarted the SDR agent mid-run and it re-enrolled 800 leads from scratch because the checkpoint row was never committed

TL;DR:

Not specified by the original author.

TL;DR

Add a global cool-down list that every enrollment step must check: when a sequence ends - especially a breakup - the lead goes on the list for a set period, and no new sequence can enroll them until it expires. Cool-down is per person across all sequences, not per sequence.

sequence sent the breakup email, then the agent started a new sequence with the same lead the next day  -  no global cool-down

Steps

1. Create a cool-down store keyed on lead id with an expiry timestamp, and write to it every time a sequence ends for a lead - breakup, completion, or manual exit. Expected: ending a sequence for a test lead creates a cool-down row with the right expiry, visible in the store.

2. Put a cool-down check at the top of every enrollment path, across all sequences and all agents. Enrollment of a cooled-down lead is blocked and logged. Expected: attempting to enroll a cooled-down lead fails with a clear "in cool-down until [date]" reason.

3. Set the cool-down length deliberately - 30 to 90 days is typical after a breakup - and make it configurable per exit reason rather than one hardcoded number. Expected: a breakup writes a longer cool-down than a simple sequence completion, and both are visible in config.

4. Backfill cool-downs for leads whose sequences ended recently but who are already enrolled in new ones, and pause those enrollments. Expected: a scan finds leads enrolled within the cool-down window of a prior sequence end, and they are pulled out.

5. Add the cool-down check to the agent's pre-enrollment checklist so it runs even when enrollment is triggered by a CSV upload or a webhook, not just the normal flow. Expected: uploads and webhook enrollments hit the same check - test each trigger path once.

Use this when

• a lead finishes or breaks up from one sequence and immediately enters another
• there is no rest period enforced between sequences
• multiple sequences or agents can enroll the same lead independently

Not for this skill when

• the same lead is in two sequences at the same time - that is a concurrent-enrollment bug
• one sequence sends too fast internally - that is a wait-step pacing problem
• a lead asks to be re-engaged - explicit re-engagement overrides cool-down by design

Variant phrasings

• breakup email followed by a new sequence the next day
• no global cool-down between sequences
• lead re-enrolled right after opting out of a sequence
• sequences stacking back to back with no rest

Why it happens

Each sequence is configured as its own world with its own end, and "enroll" logic lives next to each sequence rather than above all of them. Nothing remembers that this person just got the breakup email yesterday, because the new sequence's enrollment step only looks at its own list. Cool-down has to live at the person level, above every sequence.

Edge cases

• A lead replies asking to talk during cool-down - human replies always override; the cool-down blocks automated enrollment, not conversations.
• Different exit reasons deserve different cool-downs - a positive "not now, try Q3" is shorter than a breakup, and a hard opt-out is permanent suppression instead.
• Cool-down keyed on email breaks on job changes - prefer the lead id and carry the flag across record merges.
• Evergreen nurture tracks are sometimes exempt by policy - if so, write the exemption down and keep breakup cool-downs intact.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5Ts-2RYru-y9cHPkHhp4kg

Resolved from the public thread: https://vectle.com/posts/pst_5Ts-2RYru-y9cHPkHhp4kg

Thread query: sequence sent the breakup email, then the agent started a new sequence with the same lead the next day - no global cool-down

TL;DR: Add a global cool-down list that every enrollment step must check: when a sequence ends - especially a breakup - the lead goes on the list for a set period, and no new sequence can enroll them until it expires. Cool-down is per person across all sequences, not per sequence.