Key takeaways
- Verification is the fourth loop and the one teams skip; without it, success reports are unfounded.
- The accessibility tree beats screenshots on cost, precision and actionability.
- Separate the component that reads pages from the one that can submit.
- Design for interruption — authentication walls and expiry are the normal case.
- Define what complete means and stop when it is not met; a stopped run is an inconvenience.
Four loops, not one
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.
Give the model structure, not pixels
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
| Channel | Cost | Precision | Use for |
|---|---|---|---|
| Accessibility tree | Low | High | Everything, by default |
| Raw DOM | High | High | Rarely — too much noise |
| Screenshot | Highest | Moderate | Canvas widgets, diagnosis |
| Text extraction | Lowest | Low | Reading content, not acting |
Separate reading from acting
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.
Sessions are the operational headache
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.
What it costs to run, and where
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
Confirm before submitting, always
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.
Fail loudly
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.
Frequently asked questions
What is the step most browser agents skip?
Verification. Without re-reading the page after acting, the agent believes its plan worked — producing confident reports of applications that were never sent.
Should a browser agent use screenshots or the DOM?
A filtered accessibility tree by default: cheaper, more precise and directly actionable. Keep screenshots for canvas widgets, custom controls with no semantics, and diagnosing failures.
Why separate the component that reads pages from the one that acts?
Because pages are written by strangers and can contain instructions aimed at an agent. If the reader also holds submission ability, page text becomes a command to your submitter.
Should the agent submit without asking?
No. Submission is irreversible and goes out under the candidate name. Show every field and document that will be sent and require an explicit confirmation.
Where does the cost actually go?
Model calls per step, not browser compute. Routing known forms to a stored mapping so the agent never sees them is the single largest saving available.
What should a step budget do when it runs out?
Stop and hand off. An agent forty steps into one form is not close to finishing, and a clear handoff is cheaper and more useful than an unpredictable continuation.
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.