Stopping the wrong application

The imagined failure is an agent going haywire and applying to anything. The real ones are narrower and more mundane, which is what makes them easy to miss in testing and common in production.

Each has a specific cause and a specific check. Guarding against "the agent might be wrong" in general produces vague safeguards that catch none of them.

They also share a property worth noticing: every one is a state problem rather than a reasoning problem. The model is not confused about what a job is — the system lost track of which one, and no amount of better prompting addresses that.

• Stale identity — the posting was taken down or changed after scoring
• Duplicate confusion — applying to the same role twice via two sources
• Context drift — a long run where the active job silently changed
• Wrong candidate — the profile and the job belong to different people
• Mismatched material — a CV tailored for a different posting attached

Scoring happens when a posting is ingested; submission may happen hours later. In between the role can be filled, edited, or withdrawn — and applying to a withdrawn posting is at best wasted and at worst submitted into a system that reopens later with different terms.

Re-fetch the posting immediately before submitting and compare a fingerprint of the key fields against what was scored. If the title, company or requirements have changed materially, stop and re-score rather than proceeding with a decision made about a different job.

Verify on the page as well as through the feed. Reading the title and employer from the application page the agent is actually on catches the case where a link redirected somewhere else, which a re-fetch of the original record cannot detect.

Context drift is the failure specific to agent architectures. In a long run, the job under discussion is often inferred from conversation history or from whatever was most recently mentioned — and that inference can be wrong, or manipulated by content the agent read.

The fix is structural: the submission step takes an explicit job identifier as a parameter, resolved once and passed through. Never let the tool that submits work out for itself which job is meant. This removes an entire class of failure rather than reducing its probability.

The same applies to the candidate. Resolve identity from the verified session rather than from anything the agent supplies, because an id the model can produce is an id the model can get wrong — and a mismatch there is a data breach rather than a bad application.

When a CV is tailored for a specific role, tag it with that job’s id. At submission, assert that the attached material was generated for the job being applied to.

Without this, a retry or a queue reorder can attach the wrong tailored document — which is worse than a generic CV, because it is visibly written for somebody else’s posting.

Extend the assertion to the free-text answers, which are the more embarrassing half. A cover note naming a different company is immediately obvious to the reader, and it is exactly the artefact most likely to survive a reorder because it was generated separately.

The same role reaches you through four sources with four URLs, and a system keying idempotency on the posting link produces four keys and four applications. The key has to come from candidate, employer and normalised role instead.

Check it before the browser opens rather than after the submission returns. A crash between submitting and recording leaves an ambiguous state, and only a record written before the attempt lets you tell a duplicate from a first try.

Cap per employer as well as per role. Six applications to six different roles at one company in an afternoon arrive in one recruiter’s queue and are read as a single unserious candidate rather than six chances, which no per-role check prevents.

Every check above should refuse on ambiguity rather than proceeding on a best guess. A skipped application costs nothing; a wrong one is permanent.

Then add the batch-level guard: if several submissions in a row fail their checks, halt everything and alert. The same root cause usually affects every item, and the difference between discovering it at two and at eighty is entirely whether something stopped automatically.

Give the user a stop too. Someone who notices something wrong should be able to halt everything in one action without contacting support, and that same control is what you will reach for during an incident.