A job application agent operates at an awkward boundary: it can read an external page, prepare answers from a person's profile and interact with a form that may submit information to a third party. That makes “fill the form” an incomplete design goal. The system also needs to represent uncertainty, preserve provenance and stop before a consequential action.
One practical way to reason about this is a small state machine. The example below is illustrative pseudocode, not a description of a shipped product or a particular browser automation framework.
Separate preparation from submission
Use states that reflect what the user can truthfully know: discovered, assessed, preparing, needs input, ready for review, submitting, submitted and failed. A prepared application is not a submitted application. A clicked button is not necessarily a confirmed submission.
assess(posting, profile):
facts = extract_with_source(posting, profile)
missing = required_information_without_evidence(facts)
if missing:
return NeedsInput(missing)
return Assessed(facts)
prepare(assessment):
draft = propose_fields_and_attachment(assessment)
if draft.has_unresolved_questions():
return NeedsInput(draft.questions)
return ReadyForReview(draft, fingerprint(draft))
approve(review, fingerprint_seen_by_user):
if fingerprint(review.draft) != fingerprint_seen_by_user:
return ReadyForReview(review.draft, fingerprint(review.draft))
return Approved(review.draft)
submit(approved):
result = attempt_submission(approved.draft)
if result.has_reliable_confirmation:
return Submitted(result.confirmation)
return SubmissionUncertain(result.evidence)
The fingerprint represents a binding between approval and the exact draft shown to the user. If a field, attachment or destination changes after review, approval should no longer apply. The exact mechanism is an implementation choice; the invariant is that the user approves what will actually be sent.
Treat missing information as a state
An agent should distinguish “no” from “unknown.” A blank work-authorisation answer, for instance, is not evidence that the applicant lacks authorisation. Store the source for each proposed answer: a profile field, a document passage or a user response. If the source is absent or ambiguous, ask the person instead of guessing.
The same rule applies to narrative answers. A model may produce fluent text even when the profile lacks supporting facts. Require a user-supplied example or an explicit review of the proposed wording. Do not make a confident answer merely because a required field cannot be left blank.
Make review meaningful
The review screen should show the employer and destination, role, proposed answers, declarations and attachment identity. Include enough context to spot a mismatch, such as the CV filename and a way to inspect it. Let the user edit an answer or stop entirely. If the external form changes during review, return to preparation or review rather than silently applying the old approval to a new payload.
Consent and declarations deserve special treatment. Display their actual wording and require an explicit user choice where appropriate. A generic “approve application” button should not conceal a separate decision the person needs to make.
Handle the uncertain boundary
Browser automation can encounter expired sessions, validation errors, navigation changes or a network interruption after a click. Retrying immediately may create a duplicate application if the first request succeeded. Record the attempt and available evidence, mark the outcome uncertain, and let the user check the destination before retrying. Only record submitted when there is a reliable confirmation appropriate to that site.
External page content is untrusted input. A job description or form instruction should not override the agent's approval rule, reveal unrelated profile data or instruct it to submit. Keep the action policy separate from page text, limit access to the information needed for the task and make the final action an explicit, checked transition.
Test the invariants
Useful tests include a required question with no evidence, an attachment changed after approval, a destination changed between review and submission, a validation error and a timeout after a submit click. Assert both the visible state and the forbidden action: no submission before valid approval, no invented answer and no automatic retry of an uncertain submission.
A state machine does not eliminate every browser or model failure. It gives the application a vocabulary for handling them honestly, and it makes the boundary between assistance and the applicant's decision testable.
Top comments (1)
승인한 초안과 실제 전송할 내용을 연결하고, 클릭 뒤 확인이 없으면 불확실 상태로 남기는 구분이 명확하네요. 첨부파일 이름이 같아도 내용이 바뀌는 경우를 승인 무효화 시험에 넣으면 좋겠습니다. 검토 화면에서 목적지와 첨부 문서를 함께 확인하도록 한 부분도 유용해 보입니다.