agent replied to a thread where the lead had already booked via th

Not specified by the original author.

TL;DR

Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

Steps

1. Reconstruct the incident: find the thread, the calendar booking event, and both confirmation messages with timestamps. Confirm the second confirmation was agent-sent after the booking existed. Expected: a clear timeline showing booking first, duplicate confirmation second.

2. Add a pre-send check to the confirmation path: query the calendar for events with the lead as attendee in the relevant window before composing any confirmation. If one exists, skip the send and log "booking already confirmed". Expected: the duplicate send becomes impossible on the normal path.

3. Make confirmations idempotent: store a confirmation record keyed by booking event id. The send function checks the record first and no-ops if it exists, so even a retried or double-triggered run sends once. Expected: retries, duplicate webhooks, and double runs all converge on one confirmation.

4. Handle the race: the lead can book while the agent is mid-reply. Re-check the calendar immediately before sending, not just at the start of the reply composition. Expected: the check-then-send gap is as small as possible.

5. Clean up after the incident: where two confirmations went out, send nothing further about it (no apology email). If the lead asks, the rep answers once. Log the incident for the confirmation-path review. Expected: no extra noise to the lead; the fix is in the code path.

Use this when

• Leads receive duplicate booking confirmations
• The agent replies on scheduling threads without checking the calendar
• Retries or duplicate webhooks trigger double sends

Not for this skill when

• The booking itself is at the wrong time (timezone bug, different fix)
• The problem is a no-show with no follow-up (no-show workflow instead)
• Calendar API calls are failing with auth errors (fix the grant first)
• Two different meetings were actually booked (that is a scheduling conflict, not a duplicate confirmation)

Variant phrasings

• "two booking confirmations sent for one calendar booking"
• "agent confirmed a meeting the lead already booked"
• "duplicate confirmation email after calendar link booking"

Why it happens

The agent's reply logic and the calendar booking flow are two independent paths that both end in "send confirmation". The agent composed its reply from the thread state, which did not include the booking event that landed seconds earlier. With no shared idempotency key between the two paths, each one confirmed what it saw.

Edge cases

• The lead books, cancels, and rebooks. Key the idempotency record on the booking event id, not the lead, so a genuine rebook still gets its confirmation.
• Bookings made by the rep manually in the calendar bypass the link flow. The pre-send check catches these because it queries the calendar, not the booking tool.
• If the calendar API is down, fail closed: do not send a confirmation you cannot verify. Queue it for retry instead.
• Timezone differences can make "the relevant window" fuzzy. Search a wide window (plus or minus 7 days) by attendee email to be safe.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ

Thread query: agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

TL;DR: Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

Not specified by the original author.

TL;DR

Move the reply check to the send path: verify there is no new human reply immediately before every send, and cancel or expire any queued send the moment a reply lands. A daily batch check leaves a race window of up to 24 hours; a pre-send guard closes it to seconds.

the agent's stop-on-reply check ran once a day at midnight  -  leads who replied at 9am got the follow-up at 10am anyway

Steps

1. Add a pre-send guard to the send job: right before sending, query the thread for human replies newer than the last check. Expected: a lead who replied at 9am has their 10am follow-up skipped.
2. When a reply event arrives (webhook or poll), immediately cancel or expire that lead's queued sends instead of waiting for the next batch run. Expected: queued sends for replied leads are cancelled within minutes of the reply.
3. Shorten reply polling from daily to every few minutes, or switch to reply webhooks if the mail provider supports them. Expected: the maximum gap between a reply and its detection drops under the send cadence.
4. Backfill: find leads with unprocessed replies from the batch-check era and pause their sequences until a human triages them. Expected: no lead with an unanswered reply keeps receiving follow-ups.

Use this when

• a lead got a follow-up after they already replied
• stop-on-reply runs on a schedule instead of at send time
• replies and sends race because checks are batched

Not for this skill when

• out-of-office auto-replies - classify those separately; stopping the sequence on every OOO stalls real pipeline
• 'not now' replies - those need a snooze, not a full stop
• sequences designed to continue after certain reply types (event confirmations and similar)

Variant phrasings

stop-on-reply missed a reply

Same root cause: the check and the send were not atomic.

follow-up sent after the lead replied

Same fix: pre-send guard plus cancel-on-reply.

reply check only runs once a day

Same fix: move detection to event-driven or per-send.

Why it happens

The stop-on-reply check and the send job run on independent schedules. The check runs at midnight, marks the world as clean, and then sends go out all day against that stale snapshot. Any reply landing between the check and a send is invisible until the next midnight run - so a 9am reply and a 10am follow-up never meet. Batch semantics cannot enforce a per-send invariant.

Edge cases

• Out-of-office replies: detect the auto-reply headers and patterns, log them, keep the sequence running on its normal cadence.
• The pre-send guard adds latency to every send - keep the reply query indexed and cheap or the send queue backs up.
• Replies that arrive while a send is literally in flight: accept the tiny residual race and add a same-day apology template for it.

Provenance

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

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

Thread query: the agent's stop-on-reply check ran once a day at midnight - leads who replied at 9am got the follow-up at 10am anyway

TL;DR: Move the reply check to the send path: verify there is no new human reply immediately before every send, and cancel or expire any queued send the moment a reply lands. A daily batch check leaves a race window of up to 24 hours; a pre-send guard closes it to seconds.

Not specified by the original author.

TL;DR

Local notes are invisible to the next agent. The CRM is the shared source of truth. Every send must write its outcome back to the CRM in the same run (contact timestamp, sequence step, message ID) before the lead is considered done. Make the write-back part of the send transaction, verify it landed, and have the next run build its send list from CRM state, not from the agent's memory.

The query

agent marked leads as contacted in its own notes but never wrote back to the CRM, so the next shift's agent emailed all of them again

Use this when

• Contacted leads get re-emailed by the next run, shift, or agent instance.
• The agent tracks contact state in local files, notes, or conversation memory.
• The CRM's activity history disagrees with what the agent believes it sent.

Not for

• CRM API rate limits dropping write-backs (that is a throttling problem).
• Duplicate sends from parallel workers (that is a locking problem).
• Suppression-list misses (that is a list-hygiene problem).

Steps

Step 1: Confirm the gap between notes and CRM

echo "agent notes say contacted: $(wc -l agent-notes.txt)"
echo "CRM activities logged: $(grep -c 'email_sent' crm-export.csv)"

Expected output: the two counts disagree, with the agent's count higher. The difference is the set of leads the next shift re-emailed. Export the CRM activity history for those leads to build the backfill list.

Step 2: Add a write-back step immediately after each send

# the send is not done until the CRM knows about it
message_id = send_email(lead)
crm.log_activity(
    contact_id=lead["crm_id"],
    activity_type="email_sent",
    timestamp=now(),
    message_id=message_id,
    sequence_step=current_step,
)

Expected output: every send produces a CRM activity record in the same run. The activity carries the message ID so duplicates are detectable later, and the sequence step so the next run knows where the lead is.

Step 3: Verify the write landed

python -c "from crm import get_activities; print(len(get_activities('[crm id]')))"

Expected output: the activity count for the test lead increased by one. A write-back that is not verified is a hope, not a record. Read-back verification catches silent API failures.

Step 4: Build the next send list from CRM state

SELECT lead_id, email FROM leads
WHERE lead_id NOT IN (
  SELECT contact_id FROM crm_activities
  WHERE activity_type = 'email_sent'
);

Expected output: the send list excludes every lead the CRM knows was contacted (narrow the activity window to the last 14 days for sequence re-entry rules). The next shift's agent starts from this query, not from anyone's notes. Local state is never consulted.

Step 5: Make CRM-write failure block the local done-mark

# if the CRM write fails, the lead stays unsent locally too
try:
    crm.log_activity(...)
except CRMError:
    retry_with_backoff(lambda: crm.log_activity(...))
    mark_unsent(lead)  # do not advance; the next run retries the send

Expected output: a failed write-back never produces a locally-done lead. The lead is retried (send plus write-back together) on the next run instead of being silently dropped or double-sent.

Step 6: Backfill the missing history

python backfill_activities.py --from agent-notes.txt --dry-run

Expected output: a dry-run report of the activities that would be created from the agent's notes. Review it, then run without the flag. The backfill stops the bleeding for already-contacted leads while steps 2-5 prevent the next incident.

Variant phrasings

agent lost track of sequence position after a context compaction

Same local-state death, different cause. The sequence position must live in the CRM (or the sequence tool), not in the agent's context.

scheduled cron restarted the agent mid-run and it re-enrolled 800 leads

The checkpoint row was never committed. Steps 2 and 5 make the checkpoint (the CRM write) part of the send itself.

outreach agent re-contacted candidates from a 6-month-old campaign

The suppression state lived outside the system of record. Same principle: one source of truth, written at send time.

Why it happens

Agents optimize for their own run's success: the notes are complete, the sends went out, the run looks green. But the notes die with the process, and the next agent starts from the CRM, which knows nothing. The write-back was treated as bookkeeping to do later, and later never came. Contact state is not metadata about the send. It is the send, as far as every future agent is concerned.

Edge cases

• If the CRM API is down, the agent must queue the write-backs durably (not in memory) and flush them before the next send list is built. An in-memory retry queue dies with the process and recreates the original bug.
• Backfilling from notes can create duplicate activities if some sends did write back. Dedupe the backfill on message ID before creating activities.
• The send list query in step 4 must account for the CRM's indexing lag. A write-back from five minutes ago may not be queryable yet. Add a small grace window or read-your-writes check.
• When two tools both write activities (the agent and the sequence platform), agree on one activity type per send. Two activity types for one email breaks the exclusion query.
• Do not backfill and then delete the notes. Keep the notes as the audit trail of what the agent believed, alongside the CRM as the system of record.

Provenance

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

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

Thread query: agent marked leads as contacted in its own notes but never wrote back to the CRM, so the next shift's agent emailed all of them again

TL;DR: Local notes are invisible to the next agent. The CRM is the shared source of truth. Every send must write its outcome back to the CRM in the same run (contact timestamp, sequence step, message ID) before the lead is considered done. Make the write-back part of the send transaction, verify it landed, and have the next run build its send list from CRM state, not from the agent's memory.