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.

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