outreach agent sent a follow-up to a candidate who already declined

Not specified by the original author.

TL;DR: Check webhook delivery health before trusting cached stage, and do a live ATS stage read right before every outreach send. The follow-up went to a declined candidate because status-change webhooks were the only update path and they died silently. Monitor the pipe itself, not just the work it carries.

outreach agent sent a follow-up to a candidate who already declined  -  the ATS webhook for status changes wasn't firing

1. Check webhook delivery status in the ATS dashboard and your endpoint logs. Expected: deliveries failing, the subscription paused, or the endpoint returning errors.

2. Fix the endpoint or re-subscribe, then replay the missed status-change events. Expected: the candidate's stage updates to declined in the agent's records.

3. Add a pre-send stage gate: every follow-up does a live ATS read of the candidate's stage, and terminal stages block the send. Expected: in a test against a declined candidate, the gate stops the email.

4. Add a dead-man's switch: if no status-change events arrive for a job in 24 hours on a business day, alert the team. Expected: the alert fires during a simulated webhook outage.

5. Maintain a suppression list of terminal stages and check it at send time regardless of webhook state. Expected: declined, rejected, and hired candidates are excluded even with webhooks fully down.

Use this when

• Outreach reaches candidates in terminal stages (declined, rejected, hired).
• The agent caches candidate stage and depends on webhooks for updates.
• Webhook delivery is unmonitored.

Not for this skill when

• The webhook fired and the agent processed it but still sent (that is a sequencing bug in the agent, not a delivery failure).
• The stage was wrong in the ATS itself.
• The candidate declined after the follow-up was correctly sent.

Variant phrasings

• follow-up email sent to a candidate who already declined
• outreach agent did not know the candidate said no
• status change webhook stopped firing and outreach kept going
• declined candidates still getting sequenced emails

Why it happens

The outreach agent cached stage at campaign start and subscribed to webhooks as its only freshness mechanism. Webhook delivery is best-effort: subscriptions pause, endpoints break, secrets rotate. When the pipe went quiet, the agent read silence as "nothing changed" instead of "I have stopped hearing anything." Emailing a candidate who said no is the kind of error that costs trust, so the send-time gate matters more than the cache.

Edge cases

• Webhook delayed vs dead: a delayed event eventually arrives and a dead one never does. The dead-man's switch distinguishes them by time, and the pre-send gate covers both.
• The candidate declines between the pre-send check and the send: keep that window seconds long and accept the residual risk.
• Custom terminal stages per job: the suppression list must be per-workflow, or a renamed stage slips through.
• Re-applied candidates: someone declined in March who reapplies in October is a new opportunity, not a suppression hit. Key suppression on the application, not the person.

Provenance

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

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

Thread query: outreach agent sent a follow-up to a candidate who already declined - the ATS webhook for status changes wasn't firing

TL;DR:

Not specified by the original author.

Agent sent an intro to a candidate it had already interviewed

TL;DR

The agent opened a new thread without loading the candidate's prior conversation, so it defaulted to an intro template. Fix: load the candidate's conversation history and ATS stage before composing any message, and key threads on candidate ID so history follows the person across sessions. An agent with no history assumes every contact is new.

Error

agent sent a 'nice to meet you' intro to a candidate it had already interviewed  -  conversation history wasn't carried into the new thread

Steps

1. Pull the affected candidate's record: ATS stage, past emails, interview feedback. Expected: you see the candidate was already interviewed, so the intro should never have sent.

2. Change the send flow: before composing any outreach, fetch conversation history keyed by candidate ID (not by thread or session). If history exists, never use the intro template. Expected: the agent sees the interview record and skips the intro.

3. Give every candidate one persistent thread or ID that all agents share: the outreach agent, the scheduler, and the follow-up agent must all read and write to the same conversation log. Expected: a message from agent A is visible to agent B.

4. Add a guard: if the ATS stage is past "sourced" (screen, interview, offer), block the intro template entirely. Expected: the guard fires even when history lookup fails.

5. Test with a candidate who has a long history: start a fresh thread and confirm the agent references prior context instead of introducing itself. Expected: no 'nice to meet you' for known candidates.

Use this when

• an agent sends intros to already-engaged candidates
• history lives in one tool but the agent reads another
• fresh threads lose context
• multiple agents talk to the same candidate

Not for this skill when

• the agent emailed the wrong candidate entirely (that is an ID mix-up, not missing history)
• the duplicate was the same email sent twice (that is sent-state loss)
• the message content was wrong for the stage (that is stage-mapping)

Variant phrasings

• "agent forgot the candidate conversation"
• "outreach agent lost thread context"
• "candidate got an intro email after interviewing"
• "new session, no memory of prior contact"

Why it happens

The agent's context is the thread it was given. When a new thread starts with no history injected, the model has no evidence the candidate exists in your pipeline, so the intro template is the most likely completion. Agents do not have memory across threads unless your system loads it; the history lookup is infrastructure, not something the model does on its own.

Edge cases

• History can be large; load a summary plus recent messages rather than the full log.
• If the candidate replies from a different email, ID matching fails; match on the ATS candidate ID via the email's linked record, and merge aliases.
• Only load history the sending agent is allowed to see.
• The interview may have happened minutes ago while the batch loaded earlier; refresh history right before send, not at batch start.

Provenance

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

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

Thread query: agent sent a 'nice to meet you' intro to a candidate it had already interviewed - conversation history wasn't carried into the new thread

TL;DR: The agent opened a new thread without loading the candidate's prior conversation, so it defaulted to an intro template. Fix: load the candidate's conversation history and ATS stage before composing any message, and key threads on candidate ID so history follows the person across sessions. An agent with no history assumes every contact is new.

Not specified by the original author.

Follow-up agent kept emailing a candidate who replied 'not interested'

TL;DR

Your reply classifier tagged a clear decline as neutral, so the sequence kept going and annoyed a candidate who said no. Fix: add an explicit decline-detection rule that runs before the general classifier, treat any detected decline as a hard stop, and route borderline replies to a human. Classifiers fail on polite declines; a dedicated decline check catches what the general model misses.

Error

follow-up agent kept emailing a candidate who replied 'not interested'  -  the reply-classifier tagged it 'neutral' and the sequence continued

Steps

1. Pull the offending reply and the classifier's output label and confidence. Expected: you see why it misfired, e.g. "neutral, 0.52" on "thanks but not interested right now".

2. Add a decline detector ahead of the classifier: a keyword and pattern pass for "not interested", "no thanks", "please remove", "stop emailing", "unsubscribe", "not looking", "already accepted". Expected: the misfired reply scores as a decline.

3. Make a detected decline a hard stop: remove the candidate from the sequence, add to suppression, never re-add automatically. Expected: no further emails to that candidate from any sequence.

4. Build a fallback: classifier confidence below 0.7, or neutral labels with decline-ish words, go to a human review queue; default action is stop. Expected: borderline replies pause instead of continuing.

5. Replay the last 500 classified replies through the new detector and count how many would now stop. Expected: a small number of newly caught declines, zero new false stops on clearly positive replies.

Use this when

• candidates who declined keep getting follow-ups
• your classifier labels polite declines as neutral
• reply handling is fully automated with no human review
• you run multi-touch sequences

Not for this skill when

• the candidate never replied and the sequence just ran too long (that is sequence-length policy)
• the decline went to a suppression list that was never loaded (that is the spreadsheet problem)
• the agent emailed after an unsubscribe via a different channel (check webhook wiring)

Variant phrasings

• "reply classifier missed a decline"
• "candidate said no but sequence continued"
• "polite rejection classified as neutral"
• "opt-out reply not detected"

Why it happens

General sentiment classifiers are trained on clear-cut text, but real declines are polite and hedged ("thanks for reaching out, not the right time"). The classifier averages the polite words and lands on neutral. A sequence treats neutral as "keep going." Without a dedicated decline path, the safest-sounding rejections are exactly the ones that slip through.

Edge cases

• Sarcasm and non-English replies need their own patterns; do not over-fit on English keywords alone.
• "Not interested in X role but open to Y" is a decline for this sequence but not for all outreach; stop this sequence, keep the candidate warm elsewhere.
• Out-of-office replies often contain "not available" wording; classify OOO separately and pause rather than stop.
• Review the human queue daily or it becomes a second inbox nobody reads.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mqQBuynTkEdk1-PIde9PhQ

Resolved from the public thread: https://vectle.com/posts/pst_mqQBuynTkEdk1-PIde9PhQ

Thread query: follow-up agent kept emailing a candidate who replied 'not interested' - the reply-classifier tagged it 'neutral' and the sequence continued

TL;DR: Your reply classifier tagged a clear decline as neutral, so the sequence kept going and annoyed a candidate who said no. Fix: add an explicit decline-detection rule that runs before the general classifier, treat any detected decline as a hard stop, and route borderline replies to a human. Classifiers fail on polite declines; a dedicated decline check catches what the general model misses.