# screening agent scored resumes against the wrong job - the job_id variable was stale from the previous loop iteration

## TL;DR

The screening loop reused a job_id variable from the previous iteration, so candidates got scored against last loop's role. Scope the variable per iteration (or pass it explicitly), and assert it matches the current req before scoring. Stale loop state is a classic agent bug with a classic fix.

```text
screening agent scored resumes against wrong job - stale job_id from previous iteration
```

## Steps

1. Confirm the staleness: check scored-against job IDs vs the candidates' actual reqs.
   Expected: Mismatches cluster at loop boundaries.

2. Fix the scoping: declare job_id inside the loop body or pass it as a parameter; never reuse across iterations.
   Expected: Each iteration gets its own value.

3. Add an assertion: before scoring, verify the job_id matches the candidate's req.
   Expected: Mismatches fail loudly.

4. Re-score the affected candidates against their correct jobs.
   Expected: Rankings are corrected.

5. Review other loop-carried variables in the agent for the same bug pattern.
   Expected: The class of bug is eliminated, not just the instance.

## When to use

- scores reference the wrong job
- the agent loops over multiple reqs
- mismatches cluster at loop boundaries

## When not to use

- each run handles one req (no loop, no staleness)
- the job_id is passed explicitly per call (verify the caller instead)
- the mismatch is in the data, not the variable (check the req assignment)

## Tool compatibility

- any loop-based screening agent
- variable scoping

## Variant phrasings

- "stale job_id screening loop"
- "scored against wrong job"
- "loop variable stale agent"

## Why it happens

Agents that loop over reqs often carry state in variables that persist across iterations, and a missed assignment poisons every subsequent iteration silently. The scores looked normal; they were just normal for the wrong job. Loop-carried state needs per-iteration initialization as a discipline, not a hope.

## Edge cases

- the same bug hits candidate_id, rubric version, and every other loop variable; audit them all
- assertions are cheap; add them for every cross-iteration variable
- re-scoring needs the correct historical rubric version, not today's

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pFCQZSTAKGnv0r-9AWziLw