Key takeaways
- Parsing is the highest-leverage step to verify, because every error downstream inherits from it.
- Targets must be confirmed by the candidate, not inferred from history.
- Cheap ranking first, expensive scoring only on the shortlist — the cost model depends on it.
- The hard stop is before submission: the candidate sees exactly what will be sent.
- The agent hands over at interview preparation and does not come back.
The CV becomes structured data
The document is parsed into roles, dates, achievements with their metrics, and skills with evidence. From this point the file is an artefact; the structure is the source of truth.
Errors here propagate everywhere — a mis-parsed date becomes a wrong employment history on forty applications — so this is the step that deserves a human check before anything else runs.
Two-column layouts and tables are where parsers most often go wrong, and the failure is quiet: the text extracts in reading order rather than visual order, so a job title lands under the wrong employer and everything still looks structurally valid. Showing the candidate the parsed structure rather than the extracted text is what catches it.
Targets are confirmed, not inferred
The agent proposes roles the profile supports and the candidate confirms or adjusts. That confirmation becomes the authority for everything downstream.
Skipping this produces a search anchored to the past, which is precisely wrong for anyone changing direction — and they are the people who most need the help.
The confirmation should capture refusals as well as targets. "Not management", "not this sector", "not these three employers" are cheap to state, impossible to infer, and they prevent the category of mistake that makes a candidate abandon the tool entirely.
Discovery, filtering and scoring
The agent searches several sources, deduplicates by employer and role, filters on eligibility as a hard gate, and ranks what remains against the confirmed target.
The expensive scoring runs only on the shortlist. Postings that look stale, reposted repeatedly or unserious are flagged rather than hidden, so the candidate sees the concern and decides.
Eligibility as a gate rather than a weight is the distinction that matters most here. A role requiring work authorisation the candidate does not have is not a slightly worse match, it is not a match, and a scoring system that lets a strong skills overlap outvote it wastes everybody’s time in a way that is entirely avoidable.
- Multiple sources, deduplicated on identity not URL
- Eligibility as a gate, never as a weight
- Cheap ranking first, careful scoring on the shortlist
- Concerns surfaced, not silently filtered
| Stage | Who decides | Main failure to guard |
|---|---|---|
| Parsing | Agent, human verifies | Silent mis-attribution of roles |
| Target setting | Human | Anchoring to the past |
| Discovery | Agent | Duplicates and stale postings |
| Scoring | Agent | Eligibility treated as a weight |
| Document generation | Agent, human verifies | Unsupported claims |
| Submission | Human approves | Something wrong sent in their name |
| Response handling | Agent, escalates | Acting on an ambiguous reply |
Documents, then the first hard stop
For selected roles the agent plans what to emphasise, generates from the structured record, and verifies every claim against it. Anything unsupported is removed rather than softened.
Then it stops. The candidate sees the complete application — every field, document and free-text answer — and confirms. This is the control that makes the rest of the pipeline safe to run.
Removal rather than softening is a deliberate rule. "Familiar with Kubernetes" is not a safer version of an unsupported Kubernetes claim, it is the same claim with hedging, and it will still be asked about in an interview the candidate is not prepared for.
Submission and tracking
The agent navigates the portal, fills fields from the structured profile, verifies each step, and submits on confirmation. The exact documents sent are stored against the application.
It then watches for responses, classifies them, updates state and surfaces what needs attention. Ambiguous replies go to the candidate rather than being acted on.
Storing the exact document version matters more than it appears. Six weeks later an interviewer will refer to a line in a CV, and the candidate needs to be reading the same document the interviewer is holding — not the current version, which has been regenerated eleven times since.
What the pipeline does when something breaks
Every stage needs a defined behaviour for failure, and the correct default is almost always to stop and surface rather than to retry or improvise. A portal that changed mid-submission, a posting that disappeared, a field the agent cannot interpret — each should produce a clear item for the candidate rather than a guess.
The exception is anything idempotent and cheap. Re-running discovery after a network error costs nothing and duplicates nothing if deduplication is keyed properly, so retrying is fine there and nowhere near the submission step.
Partial submission is the case worth designing for explicitly. If the agent filled eight fields and the ninth failed, the application is neither sent nor absent, and without a recorded intermediate state a restart will either abandon it silently or submit a second copy.
Interview preparation, and the handover
When an interview is scheduled, the agent assembles what is useful: the exact CV version sent, the posting’s requirements, the company summary, what was written in the free-text answers, likely questions.
And that is where it stops for good. The interview is a person evaluating a person, and everything after it — the conversation, the negotiation, the decision — belongs to the candidate.
Stopping is a design decision worth defending rather than a limitation to be removed later. A pipeline that continued into negotiation would be automating the stage with the highest consequence and the least available context, which is the opposite of where automation belongs.
Frequently asked questions
Where does the pipeline need a human?
Three places: checking the parsed CV, confirming the target roles, and confirming each application before submission. Everything else can run unattended.
Why check the parsed CV first?
Because errors propagate. A mis-parsed date becomes a wrong employment history on forty applications, and nothing downstream will catch it.
What does the agent do after submitting?
Stores the exact documents sent, watches for responses, classifies them and updates state — routing anything ambiguous to the candidate rather than acting on it.
Where does the agent stop?
At interview preparation. It assembles the CV version sent, the requirements and likely questions; the conversation and everything after belong to the candidate.
What should happen when a stage fails?
Stop and surface, not retry or improvise — except for cheap idempotent work like discovery. Partial submissions in particular need a recorded intermediate state.
Why store the exact document version sent?
Because six weeks later an interviewer quotes a line, and the candidate must be reading the same document — not the current version, regenerated eleven times since.
Check this against your own resume
Scan your CV against a real job description, or build a parse-safe one from scratch. Your first scan costs nothing.