Automating Lever applications

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.

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

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.

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.

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

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.