Navigating an applicant tracking system

A handful of systems power most corporate hiring, each customised per employer with a logo and a colour scheme. The layout underneath is broadly stable, which means a generic per-page reasoning approach is doing expensive work that identification would avoid.

Identify from the URL pattern, the markup signature or a known asset path, then load the handler for that platform and fall back to generic reasoning only when detection fails. This cuts both cost and failure rate substantially.

Use more than one signal, because the embedded case defeats URL matching. A form served inside an employer’s own careers page carries the employer’s address and the platform’s form action and asset paths, and only the latter two identify what you are actually looking at.

• URL and host patterns — the cheapest and most reliable signal
• Markup fingerprints — stable per platform, not per employer
• A per-platform handler with known step order and field semantics
• Generic reasoning kept as the fallback path, not the default

Most portals follow the same sequence: account or email, personal details, CV upload with parsed-field correction, work history, screening questions, voluntary disclosures, review, submit. Knowing this lets the agent anticipate rather than rediscover.

Track which step you are on and validate the transition. Landing on an unexpected step means something went wrong — a validation error, a session expiry — and detecting it early is far better than continuing to fill a form that will not submit.

Identify the step by what it contains rather than by a number or a progress indicator. Employers enable and disable sections, so the fourth screen at one company is the third at another, and a handler that counts will eventually fill the wrong form entirely.

Many portals parse the uploaded CV and pre-fill fields, usually imperfectly: dates shifted, employers merged, a job title truncated. An agent that accepts the pre-fill submits an application containing errors the candidate never made.

Treat this screen as a reconciliation against the structured profile you already hold, field by field. It is the single highest-value check in the whole flow, because everything downstream is read by a human recruiter as the candidate’s own words.

The errors matter beyond appearing careless. A shifted employment date becomes an inconsistency a background check flags months later, and the candidate is then explaining a discrepancy they never introduced and have no memory of.

Many portals require an account before applying, and some send a verification code. An agent cannot and should not silently create accounts and manage credentials on the candidate’s behalf without them knowing.

Design for the handoff: detect the wall, persist state, ask the person, resume. Anything involving a code sent to their phone or inbox is theirs to complete, and the agent’s job is to make resuming afterwards seamless.

Note that accounts are usually per employer rather than per platform, so this is not a one-time cost. Making the handoff genuinely quick — a link, a reason, and a resume that picks up exactly where it paused — is what stops this becoming the reason people abandon the tool.

These flows are long enough that sessions expire mid-application, which is the failure most likely to produce a half-submitted mess. Detect it by the symptom — a redirect to sign-in, a step that resets, a form that rejects everything — rather than by a timer.

Recovery should re-authenticate and resume from the last recorded step, not restart. Restarting a flow whose earlier steps already saved server-side is how a duplicate or a corrupted application appears in the employer’s system.

Isolate sessions per candidate. A shared browser profile that carries one person’s cookies into another’s run is a straightforward data leak with no technical difficulty behind it, and it is easy to introduce by accident when optimising for speed.

• Detect expiry by symptom, not by elapsed time
• Resume from recorded state rather than restarting
• A fresh, isolated browser context per candidate
• Credentials from a scoped store, never held in the agent’s context

Voluntary disclosure sections — demographics, veteran status, disability — are the candidate’s to answer or decline. An agent filling them in, however plausibly, is making a personal declaration on someone’s behalf.

The same applies to anything legally consequential: sponsorship needs, notice periods, salary expectations, criminal history. Collect these once, explicitly, as stored answers the candidate confirmed — never as something the model inferred from a CV.

Implement the restriction above the platform handlers rather than inside each one. A classification pass that removes these fields from what any handler may fill means a new adapter cannot reintroduce the behaviour, which is the kind of guarantee that survives the team changing.