The Enrichment Engine
A recruiting engine rebuilt to decide before it pays for data, then pointed at two more verticals.
- Timeline
- Contract engagement
- Role
- Solo, contracted through a New York agency: diagnosed, rebuilt, extended, documented
- Status
- Client engagement
- Primary stack
- Clay · Lemlist · RecruiterFlow · Airtable · Apify
Headline metrics
- What it tackles
- An inherited two-sided engine for a US staffing and recruiting firm paid to enrich records before deciding whether it wanted them.
- What it delivers
- The engine rebuilt so every free check runs before every paid step, extended to two more verticals at the client's request, and handed over on runbooks with seven documented failure modes.
The problem in full
A US staffing and recruiting firm places people into schools, everything from special education teachers to substitutes, counsellors, bus drivers and custodians. The business is a two-sided marketplace: one side wins schools that are hiring, the other fills their job orders with qualified people who live close enough to actually take the shift. One side is an outbound problem, the other is a search problem, and both had to run without supervision.
An automation already existed and data moved through it, but version one had one architectural fault that produced all the others: it made decisions in the wrong order. It would find a company, pay to pull its contacts and email addresses, and only then check whether that company was a competitor or the wrong kind of organisation entirely. Every disqualified record had already cost money by the time it was disqualified, and with the routing logic scattered across intermediary tables and external spreadsheet formulas, nobody could say why a given record stopped where it stopped.
Two features of this market punish that design. A K-12 vacancy attracts other staffing agencies as well as schools, and the master list of firms the client can never approach runs to roughly 50,000 companies, so a system that enriches first pays to discover its own competitors one domain at a time. And on the fulfilment side, a job order raises exactly one useful question, who, qualified, lives near enough to take it, and the database holding the candidate pool had no way to search by geography at all.
System design
I rebuilt it as two engines, cleanly separated, each with exactly one job. The sales engine watches LinkedIn and Indeed for fresh K-12 job postings, because a school posting three teaching vacancies is a school with a staffing problem right now. The recruiting engine listens to the firm's applicant tracking system and moves the moment a new job order opens. I worked solo, contracted through a New York agency.
On the sales side, a job posting has to survive four gates before anyone at that school gets an email, and the order of the four is the whole argument. Gate one: a company domain, or stop. If the job feed does not carry one, an AI research agent finds the real website, and if neither can produce a domain the record is dropped with nothing spent. Gate two: the domain is scrubbed against the static list of roughly 50,000 US staffing and recruiting companies and against a dynamic blocklist the system writes to itself. Gate three is the first step that costs money: an AI agent researches the company and classifies it into one of seven categories, and only a clean K-12 school moves forward. Gate four closes the loop: every other verdict is written to the dynamic blocklist, so the next time that organisation posts a job it is blocked at gate two, before the paid step ever runs. The blocklist gets smarter every week and lowers the engine's own running cost.
Qualifying the school says nothing about who inside it to write to. Up to ten contacts are pulled per school and ranked by an AI agent against a hierarchy that understands staffing rather than generic seniority: executive HR first, then district talent leadership, with the founder or CEO used only where there is no HR function to find. Email discovery then runs as a waterfall across five providers in a fixed order, capped at three valid emails per school. The fourth and fifth providers only run if the first three fall short, so most runs halt early.
The recruiting engine solves geography on a database that has none. Every candidate in the pool, tens of thousands of records, is geocoded once on entry. When a job order opens, an agent reads where the job physically is and computes the four edges of a 30-mile box around it, and a second model writes, on the spot, the exact database query that keeps only candidates inside that box. The model is never asked how far apart two places are; it is asked to write the formula that answers that, which runs over the whole pool in one pass and returns a local shortlist within seconds. The one deliberate human step sits here: a person clicks to release a matched batch into candidate email discovery, because enriching every match for every job order automatically could drain a month of credits in an afternoon. That safeguard is the point.
The calls that made it work
Decide before you pay
Every check that costs nothing runs before every step that costs something. Moving each disqualifying decision ahead of each paid one is the single change that made version two cheaper than version one while doing more.
A blocklist that writes itself
A static competitor list goes stale the day it ships. So every wrong-fit organisation the classifier sees is appended to a dynamic suppression list, and the same organisation is never paid for twice. The feedback loop costs nothing and saves a little more every week.
Generate the query, not the answer
Asking a model how far apart two places are gives a plausible number you cannot check, priced per candidate. Asking it to write the database formula gives something deterministic that runs over the whole pool at once, for one call. The database cannot do geography, so the system generates the geography and hands it over ready to run.
The runbook is a deliverable
The handover names every table, every scheduled cadence and every credit account that can run dry, sets out seven documented failure modes with a troubleshooting guide beside each, and flags the two steps that stay in human hands. The contract ends and the system does not.
The results in full
Two automation engines diagnosed, rebuilt and documented, replacing a version that had become expensive and hard to reason about. The rebuilt system makes every disqualifying decision before any paid step, so it does more than its predecessor at a lower cost per run, and it was handed over on written runbooks and recorded walkthroughs, in a state the client's own team could operate without me.
This was an engineering engagement and no outbound ran under my hand, so no campaign statistics are claimed. The verdict it produced is stronger. Once the K-12 build was running, the client asked for the same engine pointed at healthcare, and then at behavioural health. Three verticals on one engine, two of them added at the client's request, and a buyer asking for the same system twice more is the best evidence a build can earn.
Continue reading
The Podcast Pipeline
Finds founders interviewed on small podcasts, reads the episode, and writes about what they said.
The Model Router
Two trained classifiers behind an LLM agent that decides which one to call.
Rebuilding a Dry Market
The addressable market ran out, so I scraped 70,000 records and built a new one.