sequence sent the breakup email, then the agent started a new sequence wit

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.

Not specified by the original author.

Fix welcome sequence agent sending emails out of order

TL;DR

Out-of-order emails happen when the agent fires sends concurrently without sequence enforcement. Send in strict order, waiting for each send's result before the next, or use a queue with ordering guarantees. Concurrency and sequencing do not mix without a plan.

The error

Welcome sequence agent failed
Emails sent out of order: day-3 email delivered before day-1 email.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=welcome sequence agent failed sending emails out of order"

Fix it

Step 1: Pause the sequence

Stop the agent from sending further emails.

Expected: No more out-of-order sends.

Step 2: Check what each user received

For affected users, list sent emails in actual send order.

Expected: You know who got what out of order.

Step 3: Enforce strict ordering

Send sequentially, awaiting each result, or route through an ordered queue.

Expected: Order is guaranteed by construction.

Step 4: Send corrections where needed

For badly affected users, send a brief correction or restart their sequence cleanly.

Expected: Users end up with a coherent sequence.

Step 5: Resume and verify

Resume the agent and watch a full sequence for one test user.

Expected: Emails arrive in the intended order.

When this applies

• Welcome sequences send emails out of order
• Users get day-3 content before day-1
• You are building sequenced email agents

When it doesn't

• The email content is wrong (fix the templates)
• Emails never send (check the sending integration)
• The timing is off but order is right (check the schedule)

Compatibility

Sequenced email sending generally. Any agent with concurrent sends.

Variant phrasings

welcome emails out of order agent

Same failure. Ordering must be enforced, not assumed.

email sequence wrong order onboarding

Wrong order confuses new users badly. Pause and fix before continuing.

agent sending emails concurrently wrong order

Concurrency without ordering guarantees produces exactly this.

Why it happens

Agents that fire off sends in parallel, or retry one email while the next already went out, destroy sequence order. Email is async by nature; without explicit ordering, arrival order is whatever the infrastructure felt like.

Edge cases

• Retries of an early email can arrive after later ones; sequence-aware retries re-check position
• Time-zone scheduling interacts with ordering; schedule in the user's zone but send in order
• A single ordered queue per user is simpler than global ordering and scales fine

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

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

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

Thread query: welcome sequence agent failed sending emails out of order

TL;DR: Out-of-order emails happen when the agent fires sends concurrently without sequence enforcement. Send in strict order, waiting for each send's result before the next, or use a queue with ordering guarantees. Concurrency and sequencing do not mix without a plan.

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.