A universal ATS agent

Job applications are not uniformly distributed across systems. A small number of applicant tracking platforms account for the large majority of postings at companies that use one at all, with a long tail of bespoke forms behind them.

That shape argues against a single generic solution. Optimise the head with specific knowledge, and handle the tail generically — accepting that the tail will be slower, costlier and less reliable, because it is also rarer.

It also tells you where engineering time goes. Three well-maintained adapters covering most volume are worth more than a clever generic system that handles everything mediocrely, and that ordering is uncomfortable for teams who find the general problem more interesting.

Before doing anything, work out which platform you are on. This is usually cheap and reliable: the URL, a form action, a script source, a distinctive element, a meta tag.

Detection should be deterministic, not a model call. It is a lookup, it happens on every application, and paying tokens to identify something a regular expression can identify is exactly the kind of cost that makes these systems unviable at volume.

Detect from several signals rather than one, because the embedded case breaks single-signal detection. A form hosted inside an employer’s own careers page has the employer’s URL and the platform’s form action, and only the second one tells you anything useful.

Each known platform gets an adapter implementing the same interface: locate the form, enumerate fields, map them to profile keys, handle the multi-step flow, detect the confirmation state.

Behind that interface an adapter can be a hand-written script for a stable platform, or a model-driven routine for a less predictable one. The caller does not care, which means you can upgrade a slow generic path to a fast scripted one without touching anything else.

Version the adapters and record which version handled each application. When a platform changes and success rates drop, the first question is which adapter version was running, and a system that cannot answer that debugs by guesswork.

• detect(page) — is this my platform?
• fields(page) — enumerate inputs with labels and types
• fill(profile) — map and populate, reporting what it could not map
• advance() — handle multi-step flows and conditional sections
• confirm() — recognise success, distinctly from a silent failure

For unrecognised forms, the model-driven path classifies each field from its label and context, fills what it can map with confidence, and escalates the rest to a human.

The important discipline is that the fallback escalates rather than guesses. It is handling the cases you have never seen, which is precisely where confident invention does most damage.

Confidence needs to be a real threshold rather than a feeling. A field the classifier maps weakly should go to the candidate with the label shown, and the difference between a system that does this and one that fills it anyway is the difference between an occasional question and an occasional wrong answer sent to an employer.

Every generic run is data. Record the form fingerprint, the field classifications, the human corrections. When the same shape appears repeatedly, promote it: generate an adapter from what you learned and move that traffic onto the cheap path.

This is what makes the system improve rather than merely cope. Without it you pay full agent cost forever for forms you have processed a hundred times.

Human corrections are the most valuable rows in that dataset. A field the classifier got wrong and a person fixed is a labelled example of exactly the case the system fails on, and collecting those systematically is worth more than any amount of prompt iteration.

Platforms change, and an adapter’s failure is not always loud. A renamed field can leave a form submitted successfully with one section empty, which looks like success to everything except the recruiter reading it.

Monitor per-adapter success rate, the proportion of fields it could not map, and the rate at which it falls through to the generic path. A drift in any of the three is the signal that the platform changed, and it arrives days before a user reports anything.

Have the fallback ready as the failure mode. An adapter that starts failing should degrade to the generic path automatically rather than erroring, so a platform redesign makes applications slow for a week instead of stopping them entirely.

• Success rate per adapter, tracked over time
• Proportion of fields the adapter could not map
• Fall-through rate to the generic path
• Automatic degradation rather than a hard failure
• An alert on drift, not just on errors

Some things should not be automated on any platform, and the adapter interface should not offer them: right-to-work declarations, background questions, salary commitments, free-text motivation answers.

Making that a property of the architecture rather than of each adapter means no future adapter can quietly reintroduce it — which is the kind of guarantee that survives a team growing.

The clean way to express it is a classification step that runs before any adapter sees a field. Fields classified as personal declarations or legally consequential are removed from what the adapter is allowed to fill, so the restriction is structural rather than a rule each implementation has to remember.