Tony Bleything

THE JOB SEARCH

Reads everything. Submits nothing.

The human gate: approve, then submit.

Personal OS

High-volume triage where the reading can be automated but the sending cannot.

In operations and intake: Claims, vendor or applicant queues: read everything, verify against the system of record, and stop before the irreversible step.

A pattern, not a past engagement: it describes how this system would be used, not where it has been.

Reads the market6:15am · boards + ATSVerifies open or closeddirect ATS API checksBuilds application kitsresume · brief · outreachTHE GATETony decidesSubmittedwith my name on itno automated path exists
Nothing gets past the person in the gate.
The morning run, reading and verifying before anything is drafted.
The morning run, reading and verifying before anything is drafted.
The gate: kits wait here until I send them.
The gate: kits wait here until I send them.
What the run produces for a role worth pursuing.
What the run produces for a role worth pursuing.

The stages

  1. At 6:15 every weekday morning, the system starts itself
  2. Reads the new postings across LinkedIn, Indeed and the major job boards
  3. Throws out anything failing a hard rule: full-time only, above a salary floor, and either remote or close enough to drive
  4. Checks whether each job is genuinely still open by asking the hiring systems themselves — Ashby, Greenhouse, Lever, Workday — rather than trusting the posting
  5. Grades how well the role fits, and builds a complete application for anything that clears the bar
  6. A separate pass checks every line of the resume word for word against my master copy, so nothing gets quietly embellished
  7. The morning summary arrives sorted: ready to apply, new leads, rejected with the reason why, and roles that have since closed

Where the gate sits

I approve, then it sends. There is no path through the code that lets it submit on its own, and the apply step stops dead and waits, every single time.

What moves between stages

Before suggesting anything it checks my actual application records, not just its own list of what it has seen. A job I have already applied to never comes back around.

What broke, and how it surfaced

The first runs kept offering me jobs I had already applied to, because it was only checking its own notes rather than my records. An assistant that does not know what you have already done is not an assistant. The fix was making it read my files.

Outcomes, with sources

~70distinct roles seen across sources in one morning runSource The scout's own morning report, 20 Aug 2026 (the 'Sources searched' section of the daily digest)
~45postings checked as still open by asking the hiring systems directly, not the job boardsSource Same morning report. Each posting was checked with the employer's own hiring system (public Ashby, Greenhouse, Lever and Workday endpoints)
0applications ever submitted without explicit human approvalSource How it's built: the apply step stops before submit and waits for me, and the code has no way to submit on its own (/job-apply)

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.