# agent's interview prep email leaked another candidate's name - the template variable rendered from the previous iteration

## TL;DR

The template renderer reused context from the previous loop iteration, so candidate B's prep email carried candidate A's name. Scope the render context per iteration: build it fresh inside the loop, never reuse. Leaked names are a privacy incident, not a typo.

```text
agent's interview prep email leaked another candidate's name - template variable from previous iteration
```

## Steps

1. Confirm the leak: check the sent email against the intended recipient's record.
   Expected: The wrong name is in the sent mail.

2. Fix the scoping: construct the template context fresh inside each loop iteration.
   Expected: No iteration can see another's data.

3. Apologize to both candidates; a name leak tells each of them about the other's candidacy.
   Expected: The incident is owned and disclosed.

4. Add a render assertion: the rendered output must contain the recipient's own name/email.
   Expected: Leaks fail before sending.

5. Review other templated emails from the same renderer for the same bug.
   Expected: The class of bug is eliminated.

## When to use

- an email contains another candidate's data
- templates render in a loop
- context is reused across iterations

## When not to use

- the name was correct but the candidate disputes it (check the record)
- each email renders in isolation already (look for a different leak path)
- the leak came from a shared draft, not the renderer (process fix instead)

## Tool compatibility

- any templated email agent
- loop rendering

## Variant phrasings

- "prep email leaked candidate name"
- "template variable previous iteration"
- "wrong name in candidate email"

## Why it happens

Template contexts are often built once and mutated per iteration for efficiency, but a missed assignment leaves the previous candidate's values in place. The email looked personalized; it was personalized for the wrong person. Candidate data crossing between candidates is a privacy breach with legal edges.

## Edge cases

- the assertion should check several fields, not just the name; emails and phone numbers leak too
- BCC mistakes compound this; verify recipient lists as well as bodies
- log the rendered output for a retention window so leaks are auditable

## Provenance

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