matchmaking-v2/research/docs/AUTOAPPLY_STATE.md

Auto-Apply Engine — State of the POC & Segment Thesis

Companion to ENGINE_DESIGN.md. Captures where the browser-use auto-apply POC stands as of 2026-06-15: what's proven, the honest boundaries, and the segment thesis. Code: poc/browser-apply/. Numbers are from small, directional samples — real direction, not statistical precision.

---

0. What this is

The "heart" of Scout (ENGINE_DESIGN.md §6), built for real. We replaced the dead heuristic mock (which proved nothing — fake ATS, fake liveness gate) with an AI browser agent: open-source browser-use + gpt-4.1 vision driving real Chrome to fill and submit real job applications. The design is a board-agnostic "master key" engine + a thin adapter registry, fed by Apify apply-URLs. It applies on the company's own ATS, sidestepping the LinkedIn/Naukri login + ban zone.

1. Architecture (what's built)

• candidate.py — board-agnostic candidate model: vision-parsed résumé + confirmed facts + a per-job tailored-motivation rule. (Résumé parsing reuses the resume-builder vision pattern.)
• apply_engine.py — the master key: navigate → autofill → fill-every-field → accuracy gate → verify → screenshot. Statuses incl. no_form / login_required so the long tail is legible.
• adapters/ — registry. GenericAdapter (catch-all, pure vision) handles the long tail; AshbyAdapter carries earned Ashby quirks. Route by URL domain. New boards = a few-line adapter.
• apply_ashby.py — the proven standalone (kept untouched).
• apply_harness.py — accuracy/cost/timing measurement rig. apify_probe.py — inbound yield rig.

Design principle: the engine is generic; adapters are thin hints; verification is first-class — screenshot-as-ground-truth + a hard gate, because the agent's self-report is optimistic.

2. What's PROVEN (the receipts)

• Real end-to-end submission. Submitted a real application to OpenAI on AshbyHQ — verified by the on-screen green success banner, not the agent's word.
• The master key generalizes. The generic adapter filled Greenhouse forms it had never seen (GitLab, Figma, Anthropic's long adversarial form) + Ashby via its adapter — 4/5, the 5th honestly bounced on a login wall. 0 fake successes.
• India works, untuned. Cracked Zoho Recruit + Keka (the big India-native ATS) with no India tuning — even read their simple text-CAPTCHAs via vision — and honestly reported no_form on an email-only careers page.
• The loop closes, economics known. Apify direct-ATS actor = 100% offsite Tier-1 links; LinkedIn (harvestapi) = 60% offsite; combined ~43% offsite, 14% immediately autonomous. Cost **$0.13/app clean ATS, ~$0.21–0.27 India ATS**; latency ~3–6 min/app; vision-off ~43% cheaper with no accuracy loss on clean forms. Cheap models (gpt-4o-mini) are a false economy (0/2, step-blowup).

3. Honest boundaries (what's NOT yet solved)

• Login-gated demand stays Tier-3. LinkedIn Easy Apply, Naukri's one-click dashboard, Workday/Oracle account-gates — need persisted session + human/Cloud, not the master key.
• Submit-time anti-bot is the persistent threat. Got spam-flagged once on Ashby; reCAPTCHA/ hCaptcha would wall us; even the simple-CAPTCHA "solve" is unverified (we never submitted to confirm acceptance). This is what breaks at scale.
• Latency needs parallelization (architecture, not a faster model). ToS/account-safety is a real exposure on the login boards.
• The matching engine (ENGINE_DESIGN.md core) is not built. This arc was all apply.

4. The segment (defined precisely)

Not "auto-apply to anything." The defensible segment is:

Autonomous, honestly-verified applications to the public-ATS + India-native-ATS tier — applying on the company's own ATS, sidestepping the LinkedIn/Naukri login & account-ban problem.

Differentiation: existing tools (LazyApply, Simplify) are brittle per-board scripts that operate inside LinkedIn (the ban zone). A board-agnostic vision engine that goes around to the ATS, with no-fake-success verification, is a different, more durable product. India is the sharpest edge — a huge, Naukri-dominated market where the direct-ATS + Zoho/Keka/Darwinbox path is genuinely underserved.

5. POC → segment (the path)

1. Submit-time anti-bot lane (make-or-break): Cloud stealth for spam/CAPTCHA; human-in-the-loop final tap otherwise. Decides the true autonomous conversion rate.
2. Parallelization — concurrent sessions for acceptable latency at volume.
3. Always-JSON output + answer-bank flywheel (small): legible triage; engine learns answers over time so human interventions shrink.
4. Wrapper decision: the apply layer of Scout, or a standalone autonomous-applicant / apply-API product. The tech supports either.

6. Honesty ledger

Proven (de-risked)	Open / must-prove
Generic vision engine fills arbitrary forms across boards & countries	Submit-time anti-bot (spam flags, reCAPTCHA) at scale
Real verified submission; no fake successes	Login-gated tier (LinkedIn/Naukri dashboard/Workday)
India-native ATS (Zoho/Keka) with no tuning	CAPTCHA acceptance (unverified — needs a sandbox submit)
Known unit cost (~$0.13–0.27/app) + the vision-off lever	Latency at volume (needs parallelization)
Apify inbound returns usable apply-URLs (loop closes)	The matching engine (still on paper)

Bottom line

A proven, board-agnostic, honestly-verified apply engine — real submission, generalizes across US + India ATS, known economics. A strong POC and a legitimate segment for the public-ATS / India-ATS autonomous slice. The realism check: "fully autonomous for every board" is not the product — the login tier needs an assisted lane, and submit-time anti-bot is the risk that decides scale. Define the segment around the proven slice, lead with India.