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.**