Why is the agent failing people on background checks?
Start dates keep slipping for support hires in Illinois. After one bad stretch of background check delays, you give the agent a narrow job. It reads the screen results, checks them against each role’s hiring rules, and sends the clear passes through while it sends flagged files to a person.
The queue also has a legal clock on it. Recruiters still need notices out on time, and hiring managers still want seats filled. So the agent shows one status for each applicant, keeps the hard files moving, and leaves the last call on flagged cases to reviewers.
The setup feels sane. You already use shared hiring rules across roles and states so similar records get similar treatment. The agent just applies those rules faster and keeps recruiters from chasing every file by hand.
The review note
What the reviewer sees:
Role: Support
State: Illinois
Record match: likely
Tagged record: theft
Status: person review
Due by: 4:00 p.m.
If still unclear by deadline: fail screen
What the agent didn’t do:
- It didn’t notice that the Illinois feed was repeating the same bad match across unrelated people.
- It didn’t pull those files out of the normal line once that pattern showed up.
- It didn’t keep still waiting on proof separate from record really blocks the job.
- It didn’t mark that week’s rushed closes so they stayed out of the next shared rule update.
One support applicant in Chicago loses a start date when an unclear file runs out of review time and is treated like a record that really blocks the job.
The shared hiring rule
You’d call that a local mess if it stopped there. It doesn’t. The same shared hiring rule used for Illinois support roles also sits under sales roles in other states. When reviewers get buried, they stop fixing bad flags and start closing files so the clock does not beat them.
Say the queue gets 30 flagged files a day during that stretch. 30 rushed closes × 15 workdays = 450 hiring calls from one bad state feed before the next monthly shared rule update.
| When | Where you see it | What changes |
|---|---|---|
| Weeks 1-3 | Illinois support hiring | More flagged files wait, then some close as no when review time runs out |
| Month 2 | Sales hiring in other states | More people stop at screen or wait longer to clear, even with clean local data |
The bad data starts in one place. The hiring damage does not. Recruiters in states with clean feeds still lose candidates, and legal has to explain why a local error changed hiring far from Illinois.
You already add human review for unclear screens, and that’s the right setup, but it doesn’t cover a queue that turns not resolved yet into no or a later rule update that treats that bad week as normal.
The suspect batch
The weak point isn’t the bad match by itself; it’s letting one bad week count as truth twice.
Everyone talks about human review and bias checks. Nobody talks about a backed-up queue closing unclear files as no and a later company-wide update copying those rushed calls into new rules.
In food safety, this is called lot quarantine: when one batch may be contaminated, you hold it out of the shared supply until you know what is clean. That Illinois stretch is one suspect batch, and its rushed hiring calls can’t be allowed to teach every other state what risk looks like.
Treat overload weeks as suspect batches, keep unclear screens neutral, and keep that period out of any shared rule update and later company-wide hiring update.
If your team needs engineers who can quarantine bad screening periods before they spread across hiring rules, that’s what we do at InTheValley.
- Why is the agent failing people on background checks? - May 12, 2026
- Tests passed. Why is checkout broken again? - April 1, 2026
- The patch looked safe. Why did release night stall? - March 31, 2026