screening agent rejected 40 candidates on a job description edited hours earlier in Greenhouse - the cached JD was 3...

TL;DR: Version the job description and bind every screening decision to the exact version used. Fetch the current JD at the start of every screening batch; if it changed since the cached copy, refresh before scoring anyone. The 40 rejections were scored against requirements the hiring manager had already rewritten.

screening agent rejected 40 candidates on a job description edited hours earlier in Greenhouse  -  the cached JD was 3 versions old

1. Pull the current JD from the ATS and record its updated timestamp or version.

Expected: it is newer than the cached copy the agent screened against, confirming the drift.

1. Re-run screening for the affected candidates against the current JD.

Expected: some candidates scored differently; the recruiter reviews the changed outcomes.

1. Change the agent to fetch the JD at the start of every screening batch, not once per job.

Expected: a batch started after a JD edit screens against the new text.

1. Log the JD version with every screening decision so audits can show exactly which text a rejection was based on.

Expected: each decision record carries the JD version or timestamp.

1. Notify the recruiter with the list of candidates scored on the stale JD and the re-screened outcomes.

Expected: the recruiter, not the agent, makes the final call on the affected candidates.

Use this when

• Screening criteria drift from the live job description.
• The JD is edited in the ATS while a screening run is in progress or cached.
• Rejected candidates look qualified against the current posting.

Not for this skill when

• The screening logic itself is wrong (bad rubric, bad parsing); the JD version is fine.
• The JD lives outside the ATS and the agent reads the right source; the issue is sync between the two sources.
• Candidates were rejected for reasons unrelated to the JD text.

Variant phrasings

• screening agent used an outdated job description
• candidates rejected on a JD that was edited hours earlier
• cached job description was three versions behind
• re-screen needed after the hiring manager rewrote the requirements

Why it happens

The agent treated the job description as static configuration, fetched once. In reality the JD is a living document that hiring managers edit as the search evolves, and the ATS does not push those edits to the agent. Each edit widened the gap between what the agent scored against and what the role actually required, silently, until 40 people were judged on the wrong text.

Edge cases

• The JD is edited mid-batch: candidates screened before and after the edit were judged on different text. Split the batch at the version boundary and record which version each candidate saw.
• A revert to an older JD: version numbers going backward must still trigger a refresh, not be ignored as "already seen."
• The JD in the ATS vs the careers page drifting apart: decide which is the source of truth for screening and read only that one.
• Re-screening changes outcomes: tell the recruiter before re-contacting anyone, since a reversed rejection is a human conversation, not an automated email.

Provenance

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