The short version
Every weekday at 6:15am the system reads the job market, checks what is genuinely still open by asking the hiring systems themselves, and builds complete applications overnight. It cannot send anything on its own; that decision is mine, and there is no way for it to go around me.
Read the full story · about 2 minutes
The use case
As a candidate running a serious senior-level search, I want an agent to do the nightly reading, verifying, and drafting, so that my attention goes to the only decisions that matter: which roles to pursue, and whether an application actually goes out.
The problem
A senior job search is a reading problem before it is anything else. Dozens of new postings a day, most of them stale, misfiled, or quietly closed. Job boards routinely show roles that were filled weeks ago. Tailoring a credible application kit takes hours per role. The obvious fix, an auto-applier that sprays applications at everything, gets the tradeoff exactly backwards: it automates the one decision that should never be delegated and leaves the drudgery of verification undone.
This system does the opposite. It reads everything and submits nothing.
How it works
Every weekday at 6:15am, a scheduled job wakes a Claude agent that sweeps LinkedIn, Indeed, and the major applicant-tracking boards, then filters against hard rules: full-time roles, a firm compensation floor, remote or commutable. Instead of trusting aggregator listings, it verifies open-or-closed status directly against public ATS APIs (Ashby, Greenhouse, Lever, Workday), which is the difference between a lead and a dead link. Roles that score above the fit threshold get a full application kit built overnight: a tailored resume, a role brief, and outreach drafts. A separate verifier checks every resume line verbatim against the master record, so no number appears in an application that I cannot defend in an interview. The morning digest lands with everything graded: ready-to-apply, new leads, filtered-out with reasons, and closures found during verification.
Where the human sits
The gate is the whole point. When I decide a role is worth pursuing, the apply command opens the real posting, fills the form from the kit, and then stops. Hard stop, every time. There is no code path that submits an application on its own. The agent’s job ends at “ready”; the decision to put my name on something is mine. That is what augmentation means in practice: the system does the reading, I do the choosing.
Demo
A screen recording of a real, live application run exists (recorded on day zero of the system going live). The redacted, captioned cut is in production; it will show the full flow through to the hard stop, with the gate moment marked on screen.
Outcomes
In a single morning run on August 20, 2026: about 70 distinct roles seen, about 45 fetched or verified directly against ATS APIs, 35 filtered out with stated reasons, 3 new leads logged, and 2 roles sitting in the ready-to-apply queue with complete kits. Time from wake-up to finished digest: about 12 minutes of machine time, none of it mine. Every number here comes from that run’s log and digest, both kept as part of the system’s own record.
What broke in production
The first runs re-surfaced roles I had already applied to, because deduplication only checked the scout’s own lead log and not the existing application folders. An applied-to role showing up as a fresh lead is a small bug with a real cost: it erodes exactly the trust the digest depends on. Fixed: the dedupe pass now checks the application archive itself, so anything with a folder is never pitched again. The lesson generalizes. An assistant you cannot trust to know what you have already done is not an assistant; the fix was making the system read my records, not just its own.


