Building an AI Job Search with GPT-6 Astra: What Changed and What Broke
Field report: September 24, 2026. This is an update on my own job-search project, with engineering results separated from job-search outcomes.
The company directory had grown to 18,490 profiles. The command running the search still checked the original 600 active feeds.
Both facts were true. That was the problem.
I had expanded the research tools, added discovery queues and written better instructions. But the pieces weren't connected to the command the automation was using. A bigger directory looked like progress before the daily workflow could use it.
I've been using GPT-6 Astra in OpenAI Codex to help plan, build, troubleshoot and improve this AI job search system. The most useful change has been making the work inspectable: what ran, what it found, what was checked and what remains unfinished.
What this case study covers: truthful AI resume tailoring, employer-direct applications, application tracking, a specific discovery failure and the repair. It does not demonstrate guaranteed interviews, a job offer or a fully autonomous search.
From a job application agent to a connected search process
My earlier Claude job-application build documented an earlier version. Its historical figures, schedule and downloadable package describe that version, not the current system. This field report covers the later evolution with GPT-6 Astra and Codex.
The goal has stayed practical: find suitable work and make a truthful application without rebuilding the same information every time.
The system now has a reviewed career history, fixed employment dates and role progression, employer-specific resume tailoring and PDF inspection. It also has more discovery channels and a ledger that distinguishes a lead from a confirmed application.
That distinction matters when evaluating AI agents for job searching. Finding a role, deciding I'm qualified, preparing the application and confirming submission are four different jobs. Combining them into one number hides where the process stops.
What GPT-6 Astra and Codex contribute
I use GPT-6 Astra to work through requirements, inspect the project, help write changes and troubleshoot failures. Codex is the environment where that work connects to the files and tools involved.
OpenAI describes GPT-6 Astra as a model for complex reasoning, coding, computer use, research and document creation. Its Codex guidance describes a coding agent that can help write, review and debug code. Those descriptions explain why I chose the tools. They don't prove that my particular workflow is reliable.
For that, I need evidence from my own runs.
An instruction can say “search every source.” The useful question is whether the running program reaches those sources, records where it stopped and exposes the work still waiting. September 24 gave me a clear example of why I need to check.
The failure: new tools existed, but the old command still ran
The project had gained a directory of 18,490 company profiles, public-search leads and LinkedIn discovery queues. Those were research inputs. They weren't 18,490 verified employers hiring for me.
The production command still collected the original 600 active feeds. The expanded directory and candidate queues lived separately, without the connection needed to use them in that run.
A second problem made the status look quieter than it was. A public search returned zero changed results because that day's search was already cached. That didn't mean the review queue was empty. Previously collected leads still needed attention.
The diagnostic that changed the repair: follow the command that runs, then inspect the queue it leaves behind. A new script sitting in the project doesn't establish that the automation calls it.
Here's the before-and-after of that specific failure:
Before: the recurring instructions described broad discovery, but the production command ran the narrower feed collection.
Repair: one required runner now connects public search, rotating company research, full-description collection, verified feeds and cache maintenance.
Verification: starting and resuming the repaired pipeline produced one employer feed sweep, rather than repeating that sweep.
Still open: company research, missing search pages and candidate review remained incomplete. The check reported them that way.
That's a useful improvement even though it isn't a completed job search.
The evidence board: what these numbers do and don't mean
The September 24 repair validation recorded:
157 regression tests passed. These check software behavior. They don't establish that every real application site will work.
114 company profiles visited, with 74 company job queries complete. Additional research was retained for later work.
1,165 distinct company-job URLs observed. These were discovery results, not 1,165 qualified opportunities.
109 full provider descriptions cached. These help with review. They don't establish eligibility or employer verification.
No applications submitted by the repair pass. Collection and engineering validation were the work being measured.
Twenty confirmed applications per day is a target. I'm not claiming the system consistently reaches it. I also haven't measured comparable before-and-after token costs, interview improvements or time savings for this repair.
The clearest result was narrower: the expanded discovery work became part of the running process, and unfinished coverage stayed visible.
AI resume tailoring starts with facts that cannot move
A job description can change what I emphasize. It cannot change when I worked somewhere, the role progression or what I did.
The career history is the source of truth. A tailored resume selects relevant evidence, orders it for the employer and checks the finished PDF. ATS resume optimization, in this workflow, means making truthful experience easier to find and read. It isn't permission to invent a qualification because the posting contains a useful keyword.
An illustrative tailoring decision: suppose a posting asks for onboarding and cross-team coordination. If the career record supports both, the resume can bring those examples forward. If the same posting requires a credential the record doesn't establish, the system must flag that gap. Repeating the credential in a summary would make the document more keyword-rich and less truthful.
Employer requirements also need a full read. A search-result card or provider description is a lead until the employer's actual posting has been checked.
Job application tracking needs a separate “not confirmed” state
A filled form is not a submitted application. A click on Submit is not enough either.
The application ledger counts a new submission only after an observed success screen. It preserves uncertain attempts so that an interruption doesn't turn into a duplicate application on the next run. A job application tracking dashboard should expose those distinctions rather than report every attempted action as success.
Aggregators, LinkedIn Jobs searches and Gmail alerts can help discover opportunities. Applications go to verified employer sites. The current posting-age window is 72 hours. Freshness needs employer evidence or a reliable observation window. If that evidence is missing, freshness stays unverified and the application remains pending.
Monitoring is scheduled on weekdays every 90 minutes during an Eastern workday. That cadence doesn't promise an application within one hour. Scheduled checks also depend on the runtime and access being available.
Inbox cleanup has its own boundaries: preserve interviews, action-needed messages and protected correspondence. Adding Gmail alerts as an input isn't a claim that the inbox is empty or that every message can be handled automatically.
The remaining gap: a finished page isn't a finished search
One public search had claimed completion with 2,174 distinct jobs captured against 2,175 reported. All six LinkedIn search scopes also had incomplete first-page capture.
That one missing result matters less than the definition of “complete.” If a system can declare success with missing pages, it can hide a much larger gap next time.
The repair requires saved coverage evidence. Page capture, distinct results and remaining continuations must agree before coverage is called complete. Missing pages, failed stages and unreviewed candidates stay on the record.
The latest check still reported incomplete coverage. That's the honest status. It also gives the next run a place to resume instead of repeating completed work or guessing where to start.
Python collection, SQLite duplicate checks, cached descriptions and compact summaries handle repeatable work in this project. The system can reuse an inspected resume only when the source facts, job posting and generated files still match. Those are design choices intended to reduce repeated work. I haven't run a comparable trial that establishes a token or cost reduction.
A five-question check for your own AI workflow
This is the part I'd bring to a business process review, whether the work is job applications, customer onboarding or invoice follow-up:
Which command or action starts the real workflow? Trace that route, not just the written plan.
What proves each stage ran? Look for saved outputs, timestamps and a clear result.
What does zero mean? No new items, no eligible items and no pending work are different claims.
What happens after an interruption? Resume unfinished work and preserve uncertain outcomes before trying again.
What evidence permits “done”? Define the confirmation before you let the system count it.
Use the AI workflow testing checklist to test those questions with messy inputs and interrupted runs. The implementation library has other examples of the business processes behind these builds.
If your team has an AI workflow that sounds complete but still needs someone to chase every handoff, I can review the current process and help implement a bounded improvement. The first step is finding where the work stops and what evidence would show that it moved forward.
Questions about AI job search automation
Can AI apply for jobs for you?
An authorized workflow can prepare materials and interact with supported application forms. My system counts success only after observing confirmation. Access problems, unsupported forms and steps needing human involvement can still stop an application. This case study is not a claim of universal autonomous submission.
How do you tailor a resume without inventing experience?
Keep a reviewed career history as the source of truth. Select relevant experience for each employer, preserve dates and role progression, flag missing qualifications and inspect the final PDF. Keywords must describe evidence you can defend.
Why isn't a larger company database enough?
A directory is a research starting point. The running workflow must visit relevant profiles, find current employer postings, inspect full requirements and record a decision. My 18,490-profile directory wasn't connected to the old production command until the repair.
How do you prevent duplicate job applications?
Use a persistent ledger and check it before submission. Record confirmed submissions separately from uncertain attempts. Review an ambiguous outcome before retrying, so an interrupted browser session doesn't automatically trigger a second application.
Did GPT-6 Astra get you a job or guarantee 20 applications a day?
This update doesn't establish either outcome. GPT-6 Astra helped me develop and repair the workflow in Codex. Twenty confirmed applications per day remains a target, and the September 24 repair pass submitted none. The verified result is a connected discovery process with remaining gaps explicitly recorded.
Comments