A browser agent that applies to jobs

The working structure is perceive, plan, act, verify — and the last one is the step teams skip. Without verification the agent believes its plan succeeded, and a plan that silently failed produces an application nobody sent and a confirmation nobody should trust.

Verification means re-reading the page after acting: is the field now populated with what we intended, did the page advance, did a validation error appear. It roughly doubles the interactions and roughly eliminates the failure class where an agent confidently reports success.

It is also much cheaper than it sounds, because verification is a DOM read rather than a model call. Comparing the field’s value against what you intended costs nothing and catches the entire category of actions the page accepted visually and ignored internally.

Screenshots are expensive per step and imprecise about what is clickable. An accessibility-tree representation — roles, labels, states, values — is cheaper, more accurate and directly actionable, because every node maps to something you can address.

Keep screenshots for the cases the tree handles badly: canvas widgets, custom controls with no semantics, and diagnosing a failure after the fact. Using them as the primary perception channel is a cost decision most teams regret.

Summarise the tree before it reaches the model. A full accessibility tree for a complex page is enormous, and filtering to interactive elements with their labels and states produces a fraction of the tokens with no loss of anything the agent needs to act on.

• Accessibility tree as the default representation
• Screenshots reserved for visual-only widgets and failure diagnosis
• Stable element references passed back to the act step
• Page state summarised, not dumped, into the model context

The agent reads pages written by other people, and a page can contain text directed at an agent. If the same component reads that text and holds the ability to submit, an instruction on the page is an instruction to your submitter.

Split them. One component extracts structure and produces a proposed action; another validates that proposal against a policy and executes it. The executor never reads page text as instruction — it only takes a typed action from the validator.

The validator is where the real constraints live: this origin is allowed, this action type is permitted here, this field is on the never-fill list, this submission requires a human confirmation that has been recorded. None of those can be argued with, because the component enforcing them does not read the page.

Every career site has its own login, its own session lifetime and its own idea of suspicious behaviour. Logins expire mid-run, multi-factor prompts appear, and an agent that cannot pause for a human is stuck.

Design for interruption from the start: detect the authentication wall, persist the run state, ask the user, resume. And store whatever session material you keep encrypted and scoped to one user, because this is credential-adjacent data with a real blast radius.

Isolate the browser context per candidate without exception. A reused profile carrying one person’s cookies into another’s run is a straightforward data leak, and it is easy to introduce accidentally when optimising away browser startup time.

A browser agent is the most expensive component in a job application pipeline by a wide margin, and the cost is dominated by model calls per step rather than by browser compute. Reducing steps matters far more than making each one faster.

The largest saving available is not reaching the agent at all. A known form handled by a stored field mapping costs a deterministic fill and a verification read, so the agent’s job becomes handling the long tail rather than every application — which changes the economics by an order of magnitude.

After that, the savings come from perception discipline: filtered accessibility trees rather than raw dumps, no screenshot where a DOM read will do, and no re-perception of a page that has not changed since the last observation.

Set a per-application step budget and stop when it is exhausted. An agent that has taken forty steps on one form is not close to finishing, and stopping with a clear handoff is both cheaper and more useful than letting it continue to an unpredictable end.

• Route known forms away from the agent entirely
• Filter the perception payload; never dump a page
• Cap steps per application, and hand off when the cap is hit
• Reuse the browser process, never the browser profile

Submission is irreversible and outward-facing: the employer sees what was sent, under the candidate’s name. Everything before it can be retried; it cannot.

Show the candidate exactly what will be sent — every field, the documents, the free-text answers — and require an explicit action. This is the difference between a tool people trust with their reputation and one they try once.

Present the assembled application rather than the browser. A screenshot of a form is hard to check; a readable list of what each field contains, with anything the system could not verify flagged, is a review someone will actually perform.

Automation that half-works is worse than automation that stops. An agent that fills six of eight fields and submits has produced an application that makes the candidate look careless, and they will never know why.

Define what complete means, check it before submitting, and stop with a clear report when it is not met. A stopped run is an inconvenience; a bad submission is damage.

Make the stop recoverable in a way the candidate can act on. The saved state, the screen it reached, what blocked it and a direct link turn a failure into three minutes of their time, which is the difference between a tool they keep and one they uninstall after the first incomplete run.