Building an autonomous job-search agent
It fetches postings, scores them against my resume, and drafts tailored applications for the ones worth applying to — on its own.
Why build this
A real job search means dozens of new postings a day, across several sites, and each one needs an honest answer to the same question:
Does this actually fit my background, or does it just share a few words with it?
That judgment call — not just "does it mention machine learning" but "does the seniority, the domain, and the actual scope of the role line up with mine" — is the part that takes real time. Multiply that by every posting worth a look, and then multiply again by the time it takes to write a genuinely tailored CV, cover letter, and screening answers for each one that passes, and a careful job search stops being something you can do alongside anything else.
That's also exactly the kind of task an LLM is well-suited to, given the right inputs: the full posting text, my actual resume, and a clear rule for what "worth applying to" means. So I built an agent that does the whole first pass on its own — fetch, judge, and draft — and only asks for my attention on the applications that actually cleared the bar.
How it works
The pipeline runs end to end, with no manual triage in the middle:
The scoring step is where the real judgment happens: the LLM is given the full posting text and my actual resume side by side, and asked for a 1–10 relevance score plus a short explanation of why. Anything below a 5 gets discarded automatically — I never see those postings at all. Drafting only runs for the survivors: for each one, the same LLM writes a tailored CV, a cover letter, and answers to any screening questions, ready for a final read before I submit.
The obvious risk with letting an LLM draft a CV is fabrication — a project I didn't do, a number I didn't hit, a skill I don't have. Every drafting prompt is explicit about this ("do NOT fabricate experience," "use ONLY facts from the candidate profile"), and the fields most likely to matter in a screening step — salary expectation, visa status, notice period — are injected as fixed, exact values from my profile rather than left for the model to phrase freely.
But an instruction is not a guarantee. Nothing in the pipeline today automatically checks a drafted bullet point or cover letter claim back against the source profile — this is prompt-level mitigation, not verification. That's exactly why nothing gets auto-submitted: every drafted application is a strong first draft for me to read and correct before it goes anywhere, not a one-click apply. Closing that gap with an actual automated fact-check pass against the profile is the next thing worth building.
That review step happens in a small browser GUI on top of the same pipeline: filter and sort the scored postings, open the generated CV/cover letter/screening answers side by side, and track status through to an interview:
Testing two models
The scoring step is the one place quality matters most — everything downstream depends on the model actually understanding whether a posting fits me, not just whether it contains the right keywords. I tested two models for this: Qwen3-4B, and Bonsai-27B, a much larger model.
Worth being precise about what "much larger" means here, because the two aren't apples-to-apples in an obvious way. Qwen3-4B runs at its native FP16 precision — about 4 billion parameters, roughly 8GB just to hold the weights. Bonsai-27B has roughly 6.7× as many parameters, but it's quantized down to close to 1 bit per weight:
Despite having 6.7× the parameters to draw on, the quantized model has the smaller footprint — on an 11GB card, that's the difference between comfortably fits and barely fits at all. The Qwen figure is the standard FP16 weight-size calculation for a model this size; the Bonsai figure is the actual GGUF file size measured on disk.
The difference wasn't really about which jobs got flagged as a match — it was about the reasoning behind the call. Same postings, same resume, both models:
"Senior Data Scientist at Thoughtworks PTE. LTD. in Singapore focuses on applying statistics, machine learning, and data mining to drive business value."
"The job requires a Senior Data Scientist role focused on statistics, data mining, and business insights, which does not align with the candidate's strong background in ML engineering, computer vision, and LLM systems."
"A research engineer role involving MEMS fabrication, piezoelectric devices, and machine learning applications."
"The candidate lacks experience in MEMS fabrication, piezoelectric devices, and hardware simulation, which are core requirements for this research role."
"A mid-level data scientist role focused on using data science and statistical analysis for process optimization and evaluation."
"The candidate is a senior ML engineer specializing in deep learning, computer vision, and LLMs, which does not align with the data management and statistical process analysis role."
Qwen3-4B's explanations mostly restate the job description — descriptive, not evaluative — and scored a hardware research role, a statistics-heavy process science role, and a generalist data science role all 8–10/10, seemingly because each mentioned "data" or "machine learning" somewhere in the text. Bonsai-27B's explanations name what the posting actually requires and weigh it against what's actually in my background. Bonsai-27B is the model this pipeline runs on now.
What it found
Across 199 real job postings, scraped and scored end-to-end:
Relevance score (1–10) → number of postings
Only a single job landed anywhere near the 5-point cutoff — the model isn't hedging in the middle, it's making a clear call almost every time.
What kinds of roles matched — 149 relevant postings, grouped by category:
"Other" is the second-largest bucket, and it's worth unpacking rather than leaving opaque — it isn't a sign of a weaker match, it's an artifact of the taxonomy: the model only labels a job's category as one of four fixed buckets (ML Engineer, Computer Vision, AI Inference Engineer, Quant/ML), so a posting can be a completely legitimate, high-scoring fit and still not land in any of those four. Breaking down what's actually inside the 38:
- Research scientist / research engineer roles — 9
- Recommendation & ranking algorithm engineering — 6
- Applied AI in robotics, industrial, or embedded systems — 6
- General AI engineering titles that didn't map to a specific bucket — 6
- Staff / lead / director-level AI roles — 4
- AI + data science hybrid roles — 4
- ML infrastructure / MLOps — 3
The category label is a taxonomy convenience, not part of the relevance judgment — the fit score is decided independently of which of the four buckets (or none) a posting ends up in.
The score alone doesn't show why a job was accepted or rejected — that's the more interesting part. Four matched, four rejected, straight from the raw output:
"The candidate's extensive experience in computer vision, real-time inference optimization, and deep learning at senior levels aligns perfectly."
"5+ years of experience building production ML systems including video recommendation models with real-time serving, directly aligned."
"Extensive experience as a Staff ML Engineer with expertise in generative AI, LLMs, and deep learning aligns strongly with the role."
"Extensive experience in LLM-based agentic systems, RAG, and computer vision, aligning perfectly with the job's focus on generative AI."
"The role requires a strong focus on statistics and data analysis rather than deep ML engineering, which does not align with the candidate's background."
"The role is explicitly for a PhD graduate, while the candidate has a Master's degree and 5+ years of professional experience."
"The candidate is a senior ML engineer with 5+ years of industry experience, significantly overqualified for an AI Researcher Intern position."
"The candidate's expertise in deep learning, computer vision, and LLMs is entirely unrelated to the quantitative finance skills this role requires."
The rejections aren't "no ML keywords found" — they're seniority mismatches (a PhD-only graduate role), overqualification (a senior engineer against an intern posting), and domain mismatches (quant research, not ML) that a naive keyword filter would have passed straight through.
A few of the highest-scoring matches also happened to carry the widest salary bands in the whole dataset — a multimodal algorithm researcher role at 20,000–40,000 SGD/month scored 9/10, for instance — a nice confirmation that the fit signal and the postings actually worth an application point the same direction.
The part that actually matters, though, isn't just that this is faster — it's whose time it spends:
"By hand" splits into two very different kinds of work, not one flat rate. Most of the 199 postings are an obvious no within a minute or two, but a meaningful minority warrant a closer read before ruling them out, so ~6 hours is a reasonable estimate for the whole screening pass across four sites. Drafting is not from a blank page each time: with a strong base CV and cover letter to adapt, tailoring one to a specific posting is closer to ~2 minutes than a from-scratch rewrite, putting 149 applications at ~5 hours. "With the agent" is measured wall-clock — the scoring time comes straight from this run's server logs, the drafting time is 149 × the measured average generation time per job (~18.3s) — but the number that matters more than the 57 minutes itself is that none of it needs to happen at my desk: it runs unattended while I do something else, and the only time I actually spend is reading the shortlist afterward.
Where this leaves things
This agent now runs my job search for me: every posting gets an honest first read, and the only ones that reach me are the ones actually worth a tailored application. That's real time back — time that used to go to skimming postings now goes into the applications themselves.