Key takeaways
- Simplicity moves the risk from navigation to the correctness of pre-filled values.
- Reconcile every parsed field against the structured profile; never defer to the parse.
- Profile links come from verified stored values, never constructed from a name.
- Optional free-text sections are optional to the form and not to the reader.
- Require positive evidence of submission — an absent error is not a confirmation.
A compact form with parsing built in
Lever-hosted applications generally present a single, relatively short form, often with a CV upload that pre-populates the contact and experience fields. For an agent this is a straightforward structure to handle.
The simplicity shifts where the risk sits. There is little navigation to get wrong and a great deal riding on whether the pre-filled values are correct before submission.
That inversion is worth internalising, because it changes where engineering effort belongs. On a long multi-screen portal most of the work is getting through the flow; here the flow is trivial and essentially all of the work is data correctness.
Reconcile the parse, do not accept it
Automated CV parsing is good and not perfect. Names with particles, hyphenated surnames, non-Latin characters, ambiguous date formats and unusual employer names are the routine failure cases, and none of them raises an error.
An agent should compare every pre-filled value against the structured profile it already holds and correct differences rather than defer to the parse. This is the single highest-value check in the flow.
Date ambiguity deserves singling out because it is invisible and consequential. A CV written as 03/04/2021 parses differently depending on the locale assumed, and a one-month discrepancy in an employment date is exactly the kind of thing a background check flags later as an inconsistency the candidate then has to explain.
- Name and contact fields — the most common parse errors
- Date formats, especially where day and month are ambiguous
- Employer and title strings, frequently truncated
- Anything the profile has but the parse left empty
| Failure | How it looks | Consequence |
|---|---|---|
| Particle in a surname | Split across name fields | Addressed by the wrong name |
| Ambiguous date | Month and day swapped | Flagged in a background check |
| Truncated employer | Half a company name | Looks careless |
| Merged bullet points | One long run-on line | Unreadable experience section |
| Empty field the profile has | Silently blank | Missing required information |
Profile links are expected, and easy to get wrong
These forms commonly include fields for a professional profile or portfolio. Leaving them blank is a visible omission on a form where they are clearly anticipated; filling them with a stale or wrong URL is worse.
Keep verified links on the candidate profile and populate from there. An agent should never construct a profile URL from a name — a plausible-looking link to someone else’s profile is a bad outcome that is hard to detect afterwards.
Verify them periodically rather than once. A repository that has been made private, a personal site whose domain lapsed, or a portfolio behind a broken link all read worse than no link at all, because the reader clicked and found nothing.
Optional fields that are not really optional
Free-text sections marked optional — additional information, why this role — are optional to the form and not to the reader. An agent that skips everything not strictly required produces a bare application that reads as low effort.
Fill them when there is something specific and true to say, drawn from the candidate’s real history against this posting. Leave them empty rather than padding them; filler is more damaging than absence.
The decision belongs in the agent’s logic rather than in a prompt. A rule that only generates when the posting contains something the candidate’s history genuinely speaks to, and otherwise surfaces the field for the candidate to fill or skip, produces better results than instructing a model to "write something specific" and hoping.
One candidate, many applications, one profile
Because the same platform is used by many employers, the field semantics recur even where the questions do not. That makes a canonical structured profile — name, contact, links, roles, achievements, standing answers — far more valuable than per-form logic.
Every field the agent fills should trace back to a value in that profile, which gives you a useful invariant: if something appears in an application that is not in the profile, it was invented, and that is a bug rather than a stylistic choice.
It also makes correction compound. A candidate fixing a mangled employer name once fixes it for every future application, which is the difference between a tool that improves over a search and one that repeats the same error forty times.
- Canonical profile as the only source of factual values
- Standing answers for recurring questions, confirmed by the candidate
- Verified links, re-checked on a schedule
- An invariant: nothing in an application that is not in the profile
Verify the submission actually happened
Form submissions fail in undramatic ways: a validation error on a field below the fold, an upload that did not register, a network failure after the click. The agent needs positive evidence, not the absence of an error.
Confirm from the page state after submitting, record the result against the application, and treat an unknown outcome as unresolved rather than complete. A candidate who believes they applied and did not has been failed more thoroughly than one whose agent stopped.
Resolve the unknowns rather than leaving them in the record. A confirmation email in the candidate’s inbox, or the posting appearing under their submitted applications, settles most of them within a day — and a queue of permanently ambiguous states is how a tracking system quietly stops being trusted.
Frequently asked questions
What is the main risk when automating Lever applications?
The parse-and-prefill step. CV parsing routinely mishandles names with particles, ambiguous dates and long employer strings, and none of those raise an error.
Should an agent fill in profile or portfolio links?
Yes, from verified links on the candidate profile — never constructed from a name. A plausible link to someone else profile is a bad outcome that is hard to detect later.
Should optional free-text sections be skipped?
Not if there is something specific and true to say; a bare application reads as low effort. But leave them empty rather than padding, since filler is more damaging than absence.
How does an agent know the application was submitted?
By positive evidence from the page state after submitting, recorded against the application. An unknown outcome is unresolved, not complete.
Why do ambiguous dates matter so much?
Because 03/04/2021 parses differently by locale, and a one-month discrepancy in an employment date is exactly what a background check later flags for the candidate to explain.
What invariant keeps generated applications honest?
Every filled value traces to the canonical profile. Anything in an application that is not in the profile was invented, which makes it a bug rather than a style choice.
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.