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

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

Ephemeral container storage dies with the container, and an agent that tracks "who I emailed" in a local file wakes up with amnesia and re-runs the batch. Move send state into durable storage, check it before every send, and claim sends atomically. Restarts should be boring, not re-fires.

The query

SDR agent sent the same follow-up 4 times - the sequence state file got wiped when the container restarted and the agent didn't know who it already emailed

Use this when

• An agent re-sends follow-ups after a restart, crash, or redeploy
• Send state lives in a local file, in-memory cache, or the conversation context
• Duplicate sends spike after infrastructure changes

Not for

• Personalization tokens rendering blank
• Email deliverability or spam-folder problems
• API rate limits mid-sequence

Steps

1. Move send state out of the container

Store per-lead, per-step send records in a database or a persistent volume. Never a local file inside the container image, never memory only.

Expected output: send state survives restarts, redeploys, and crashes.

2. Check before every send

Query "has lead L received step N" and skip when the answer is yes. Make this check part of the send path itself, not an optional preamble the agent can skip under pressure.

Expected output: a re-run sends zero duplicates.

3. Claim sends atomically

Mark the send in-progress with a unique constraint on lead plus step, or a distributed lock, so two worker instances cannot both fire the same step.

Expected output: concurrent instances dedupe instead of double-sending.

4. Reconcile against the mail provider after a crash

On startup after an unclean shutdown, list actual sends from the provider's API and backfill state before resuming the sequence.

Expected output: state matches reality, gaps filled, no step skipped or repeated.

5. Alert on anomalies

More than one send per lead per step per day pages the operator. Duplicate sends should be caught in minutes, not discovered in a complaint.

Expected output: a working alarm you have tested at least once.

Variant phrasings

agent re-sent the sequence after a restart

Same fix. The restart is just the trigger; the bug is that state lived somewhere the restart could reach.

duplicate follow-ups after a container restart

If this keeps recurring, check step 3 too: the duplicates may be two instances racing, not one instance forgetting.

Why it happens

The agent's mental model of "sent" lives in memory, a local file, or the conversation, while the actual sends live at the mail provider. Any restart, compaction, or redeploy wipes the agent-side record. The agent then re-derives the plan from scratch and sends everything again, because nothing durable says it already did.

Edge cases

• Provider API lag: a send may exist but not be visible in the API yet. Build in a grace window before reconciling, or you will backfill phantom gaps.
• Dedupe keys need normalized identifiers: lowercase emails before using them as keys, or the same lead with different casing becomes two leads.
• Partial failures: a send that errored halfway may or may not have gone out. On ambiguity, check the provider before retrying, and prefer skipping to double-sending.

Provenance

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

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

Thread query: SDR agent sent the same follow-up 4 times - the sequence state file got wiped when the container restarted and the agent didn't know who it already emailed

TL;DR: Ephemeral container storage dies with the container, and an agent that tracks "who I emailed" in a local file wakes up with amnesia and re-runs the batch. Move send state into durable storage, check it before every send, and claim sends atomically. Restarts should be boring, not re-fires.

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.