Where the job-search AI actually runs
The lab's job-search pipeline is the clearest end-to-end example of how AI runs here in production. A scheduled job collects new postings, a free local model reads every single one of them, and only the postings that look like a plausible fit escalate to a paid hosted model behind the same budget-gated gateway the rest of the lab shares. Nothing about the model choice or the escalation is manual.
This page is the companion to the AI guardrails page: that page covers the controls that apply everywhere, and this one walks the one pipeline that exercises all of them together, from the first cheap read to the digest that lands in an inbox each morning.
Built from the job-search pipeline's collection, extraction, scoring, and digest stages, the LiteLLM gateway and its budget layers, and the lab's MCP read-surface boundary decision.
Why this pipeline is the clearest AI-in-production example
Most of the AI work in this lab happens inside a larger operational pipeline, alongside collectors, dashboards, and approval gates that were not built for AI specifically. The job-search pipeline is smaller and more self-contained: it exists to read new job postings, decide which ones are worth a closer look, and tell me about them. That narrower scope makes it a good page-length walk through a real AI path, from the first read of a posting to the message that lands in an inbox.
It is also one of only two consumers that currently spend real money against the lab's shared AI budget, alongside the overnight operations triage. The budget-gate story on the gateway page uses this pipeline's own numbers, because they are the ones that actually moved.
Two passes: a free local read, then a gated escalation
Every new posting gets read once by a local model running in the lab. That pass extracts the skills a posting is asking for and gives the posting a rough relevance read against what I am looking for. It costs nothing per posting, so it runs on everything, including postings that turn out not to matter.
Only the postings that clear that first read go any further. Those get a second, more expensive pass: a hosted model compares the posting against my resume and returns a fit assessment. That second pass is the one that costs money, so it only runs on the subset of postings the free pass already thinks are worth it. The two-pass shape is the same reason the overnight triage keeps a local model in front of a hosted one: the cheap model does the sorting, and the paid model only ever sees the work that survived the sort.
The same gateway and budget layers as the rest of the lab
The hosted pass does not hold its own API key. It goes through the lab's single LiteLLM gateway, the same one every other AI consumer uses, and it has to clear the same three independent limits before a hosted request is allowed out: its own fail-closed credit gate, its per-consumer allowance at the gateway, and the gateway-wide ceiling shared by every consumer. Any one of the three can say no.
This pipeline is also where that layering was tested for real. Its monthly allowance started at 10 dollars and hit the gate during normal use, and it was raised to 20 dollars afterward, as a deliberate decision rather than a drift. That is the layering doing its job: the gate stopped the spend when the number was too low, and raising it was a one-time, reviewed change rather than something that crept upward unnoticed.
The full layering, the numbers for every consumer, and the metrics gap that had to be worked around live on the gateway page.
Why this pipeline does not go through the MCP read server
The lab also runs a narrow, read-only MCP server that lets an AI agent look up things like monitoring state or recent build history without ever holding the underlying credentials. The overnight operations triage reads several of the lab's own systems through it.
Job search does not, and that is a boundary rather than a gap. What this pipeline reads is almost entirely outside the lab: public job-board listings, and postings forwarded by hand into an inbox. What it writes stays inside its own database. Neither side of that is a lab-internal system the MCP server was built to front, so routing either one through it would add a hop without adding any safety. If a future stage ever needs to read lab-internal state as part of scoring a posting, that is the kind of read the MCP boundary exists to cover, and it is a decision that has already been written down rather than left implicit.
From a new posting to a delivered digest
The pipeline runs as a short chain of scheduled stages rather than one long job, so a failure in one stage does not have to take the others down with it. A collection stage pulls in new postings on a schedule. An enrichment stage runs the two AI passes described above against whatever is waiting. A digest stage reads whatever was newly scored above a threshold and sends one summary email.
The local model runs on a machine that is not always powered on, so the enrichment stage is built around that instead of assuming the model is always reachable. It works through a backlog of not-yet-extracted postings rather than only "what's new since last run," and a connection failure is logged and left for the next scheduled pass rather than failing the whole job. A posting that keeps failing eventually stops being retried and shows up in the digest as needing a manual look, instead of retrying forever.
How it runs now
| When | What runs | What happens next |
|---|---|---|
| Daily collection | Job-board sources and a forwarded-mail inbox are checked for postings not seen before. | New postings are recorded and queued for the local read. |
| Local extraction pass | The free local model reads every queued posting for skills and a rough relevance read. | Postings that clear the bar queue for hosted scoring; the rest keep their extraction only. |
| Hosted fit pass | The credit gate, the per-consumer gateway allowance, and the global ceiling are all checked before a hosted request goes out. | An allowed request returns a fit assessment; a denied one waits for the next window. |
| Daily digest | The pipeline reads whatever was newly scored above threshold that day. | One summary email goes out; a quiet day sends nothing. |
What stays off this page
This page describes the pipeline, not what it has found. It does not name which companies are being watched, does not show a score or a gap note the pipeline has produced, and does not go into mailbox or credential detail beyond what is already said above. Those are the pipeline's working data and my own job search, not something this page is trying to demonstrate.
The always-on gap in the local model is a known limit, not a hidden one: a lab-hosted model that does not depend on a machine being powered on would remove the retry logic described above, and it is a real follow-up rather than a finished piece of work.