Key takeaways
- Deduplicate on employer and role, not URL, and check freshness before spending anything else.
- Eligibility is a gate; the moment it becomes a weight, a confident score will eventually override it.
- Fabrication enters at document preparation and is plausible enough to survive a quick read.
- Verify every form step — an agent that continues after a silent failure produces a bad application, not an error.
- The approval step is the control that makes the fallible stages above it acceptable.
Discovery
The agent gathers postings from job APIs, employer career pages and aggregators. The recurring problems here are duplicates across sources, postings that are already closed, and listings that exist to collect CVs rather than to fill a role.
Deduplicate on employer and role rather than on URL, and check freshness before anything else runs. Everything downstream is wasted effort on a posting that is gone.
The same role reaches you through four channels with four different URLs, three different titles and two different salary ranges. Identity has to be reconstructed from employer, normalised title and location rather than taken from any single field, and getting this wrong shows up immediately as a feed that looks full and contains twenty roles.
Filtering and scoring
Hard constraints come first because they are binary and free: right to work, location feasibility, employment type. Then relevance scoring ranks what remains, cheaply at first and expensively only at the top.
The failure to guard against is a confident score overriding an eligibility constraint. Keep constraints as gates rather than as weights, or the agent will eventually submit an application the candidate cannot legally take.
Cost discipline lives here too. Running an expensive scoring pass over two hundred postings a day is the difference between a product with margin and one without, and a cheap ranking that narrows to the top twenty before anything expensive runs costs almost nothing in quality.
- Gate on eligibility, never score it
- Rank cheaply, then re-rank the shortlist carefully
- Model the effort each application costs, not just the fit
- Cap how many proceed, regardless of how many qualify
| Stage | Fails as | Guard |
|---|---|---|
| Discovery | Duplicates and dead postings | Identity-based dedup, freshness check |
| Filtering | Eligibility outvoted by fit | Constraints as gates |
| Scoring | Cost per candidate explodes | Cheap first pass, expensive on shortlist |
| Documents | Plausible fabrication | Verify every claim against the record |
| Form filling | Silent step failure | Read back after each action |
| Submission | Irreversible mistake | Human confirmation |
| Tracking | No idea what happened | Store what was sent, watch for replies |
Document preparation
Selected roles get a tailored CV and, where appropriate, a letter or free-text answers. This is where fabrication enters: generated text invents a project, a figure, a technology, and it is plausible enough to survive a quick read.
Generate from structured profile data and verify every claim against it. Anything unsupported is removed rather than softened, because the candidate will be asked about it by someone who has read it carefully.
The verification pass is worth building as a separate step rather than as an instruction inside generation. A second pass that takes the produced document and the structured record, and asks only whether each factual claim is supported, catches things the generating pass will not — because it is not simultaneously trying to write well.
Form completion
The agent navigates the site, maps fields to profile data, handles uploads and works through the flow. Portals differ, sessions expire, validation rules are undocumented, and some questions should not be answered by a machine at all.
Demographic disclosures and legally consequential answers come from what the candidate explicitly confirmed, never from inference. And every step is verified, because an agent that continues after a silent failure produces a bad application rather than an error.
Most volume flows through a handful of platforms, which makes a per-platform handler with a generic fallback the design that actually works. Deterministic handling for the forms you know keeps cost and reliability where they need to be, and the model-driven path earns its expense on the long tail.
The state the loop has to keep
A loop that runs daily needs memory, or it repeats itself. What has been seen, what has been applied to, what documents were sent, what the outcome was, and which employers are excluded are all state that must survive a restart.
Idempotency is the specific property to design for. Every action should be keyed so that replaying it is a no-op rather than a duplicate, because retries are inevitable and a duplicate application is visible to the employer in a way an internal error is not.
Keep the reasons as well as the results. Knowing that a posting was skipped is much less useful than knowing it was skipped because the location gate rejected it, and the second one is what lets a candidate notice that their location settings are wrong.
- Seen-postings set, so a daily run does not re-surface everything
- Application records keyed by candidate, employer and role
- The exact documents sent, retrievable later
- Rejection reasons, not just rejections
- A per-employer and per-week cap that survives restarts
Approval, then tracking
Before submission the candidate sees exactly what will be sent and confirms. This is not friction to be optimised away — it is the control that keeps the whole pipeline honest, because everything above it is fallible and compounding.
After submission the agent records what was sent, watches for a response, updates state and surfaces what needs attention. Without this the candidate has automation that generates applications and no idea what happened to any of them.
Response classification is the part most often left out, and it is cheap. Sorting replies into rejection, interview request, information request and ambiguous — then acting only on the first two and escalating the rest — turns a pile of unread email into a working pipeline.
Frequently asked questions
What are the stages of an automated job application loop?
Discovery, filtering and scoring, document preparation, form completion, human approval, and tracking. Each fails in its own way and the failures compound quietly.
What is the most dangerous scoring mistake?
Treating eligibility as a weight rather than a gate. A confident match score will eventually override it and produce an application the candidate cannot legally take.
Where does fabrication enter the pipeline?
Document preparation. Generated text invents projects, figures and technologies plausibly enough to survive a quick read — so verify every claim against structured data.
Can the approval step be removed?
No. Everything above it is fallible and compounding, and submission is irreversible under the candidate name. It is the control that keeps the pipeline honest.
How should postings be deduplicated?
On reconstructed identity — employer, normalised title and location — not on URL. The same role arrives through four channels with four URLs and three titles.
Why does the loop need idempotency?
Because retries are inevitable. An action keyed so that replaying it is a no-op prevents duplicate applications, which are visible to the employer in a way internal errors are not.
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.