From search to submission

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.

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

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.

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.

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

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.