outreach agent sent offers to candidates the hiring manager already rejected - the rejection stage sync lagged 6 hours

outreach agent sent offers to candidates the hiring manager already rejected - the rejection stage sync lagged 6 hours

TL;DR

The agent's cached stage data was 6 hours old, so it sent offers to candidates the hiring manager had already rejected. Read the candidate's live stage immediately before any outbound action, and treat cached stages as hints, not facts. Stale stage data turns outreach into an embarrassment.

outreach agent sent offers to candidates already rejected - stage sync lagged 6 hours

Steps

1. Confirm the lag: compare the agent's cached stage timestamps against the ATS audit log. Expected: The cache was hours behind.

2. Add a live stage check immediately before any offer or outreach send. Expected: Sends act on current truth.

3. Shorten the sync interval for stage data, or switch to webhook-driven updates with a poll fallback. Expected: The cache stays fresh.

4. Apologize to the affected candidates with a human-written note; an offer-then-rejection whiplash damages the brand. Expected: The incident is owned.

5. Add a pre-send verification checklist: live stage, correct candidate, current comp. Expected: Every send is verified.

When to use

• outreach contradicts recent ATS changes
• stage data is cached with a long TTL
• offers or emails go to wrong-stage candidates

When not to use

• the stage was current and the rejection came after the send (timing, not staleness)
• the ATS itself shows the wrong stage (fix the ATS workflow)
• outreach reads live already (check the send authorization instead)

Tool compatibility

• any outreach agent
• ATS stage APIs and webhooks

Variant phrasings

• "offer sent to rejected candidate stale stage"
• "stage sync lag outreach"
• "agent acted on old ATS stage"

Why it happens

Stage syncs run on schedules, and hiring managers reject candidates between syncs. The agent acted on a snapshot, and the snapshot lied. For irreversible actions like offers, snapshot data is never sufficient; only a live read counts.

Edge cases

• webhook-driven sync still lags when webhooks fail; the pre-send live read is the backstop
• rate limits on live reads need budgeting; cache the reads for seconds, not hours
• the apology matters; candidates remember offer whiplash

Provenance

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