Stop Building One AI Agent Per Job Opening

Every job opening does not need its own robot.

It is Tuesday morning and Marcus has forty open roles.

He runs a six-person staffing agency out of a shared office in Austin, Texas, placing warehouse leads, bookkeepers, and dental hygienists for eleven small business clients. Resumes come in from Indeed, from referrals, from a careers form nobody remembers building. By 9 a.m. There are ninety-one unread applications across three inboxes.

Marcus does what most owners in his position do. He searches YouTube for "AI resume screening." He finds a tutorial. It shows him how to build an AI agent, in fifteen minutes, that reads a resume against a job description and scores it.

He builds one for the warehouse lead role. It works. He builds a second one for the bookkeeper role. It works too, but it takes him another forty minutes, because the job description is hardcoded into the prompt and every prompt has to be written from scratch.

By role six, he stops.

Why the one-agent-per-job pattern breaks down after five roles

This is the pattern almost every recruiting automation tutorial teaches: build an agent, paste the job description into its system prompt, done. It is the fastest way to get a demo working, and it is also the fastest way to build something you cannot maintain.

Forty roles means forty prompts. Forty prompts means forty places a hiring manager's requirement change has to be copied and pasted by hand. Forty separate workflows drifting in forty separate directions, each one slightly out of date the moment someone edits a job description in the ATS and forgets to update the agent.

The pattern does not fail at forty roles. It fails around role five or six, the moment two roles are similar enough that the agent starts confusing one job's requirements for another's. Builders call this prompt collision, and it is the reason most DIY hiring automations quietly get abandoned three weeks after launch.

The fix is not a smarter prompt. It is a different architecture entirely.

How do you build one AI agent that screens candidates for multiple job openings?

You build one agent with a generic prompt, and you make the job description part of the data the agent looks up at runtime instead of part of the prompt you write by hand.

This is the same trick that lets a single customer support agent answer questions about a hundred different products without a hundred different agents: the product catalog lives in a database, not in the prompt. Applied to hiring, it looks like this. Every open job description gets converted into a vector embedding, a numerical fingerprint of its meaning, and stored in a small database alongside a role ID. When a resume arrives tagged with which role the candidate applied for, the workflow looks up that role's embedding, pulls back the actual job description text, and hands both the job description and the resume to one scoring agent whose instructions never change.

Add a role, insert one row. A hiring manager updates the requirements, update one row. The workflow itself never changes, no matter whether Marcus is filling five roles or five hundred.

Why this is worth building now, not six months from now

The economics changed before most small business owners noticed. Embedding a job description costs a fraction of a cent and takes about thirty seconds, a one-time setup per role. Scoring a single resume against it, once the embedding trick is in place, runs at roughly 2.3 seconds and a fraction of a cent on a small model like GPT-4o mini. You do not need a frontier model to read a resume and check it against four criteria.

Compare that to the platforms selling this exact primitive back to you. Applicant tracking tools with AI scoring bolted on commonly charge in the range of thirty to forty dollars per seat, per month, for what is, underneath the interface, the same lookup-and-score pattern you can build yourself in an afternoon.

One deployed version of this workflow took 38 minutes to go from an empty automation canvas to its first correctly scored candidate. Compare that to the per-role agent pattern: forty roles at roughly fifteen minutes of prompt-tuning each is ten hours of work, and at the end of it you are maintaining forty things that drift independently instead of one thing that does not.

Can an AI agent legally reject a job candidate?

This is the question every owner should ask before shipping this, and the honest answer is: do not let it.

In the United States, the Equal Employment Opportunity Commission has published specific guidance on assessing adverse impact when software, algorithms, or AI are used in employment selection procedures under Title VII of the Civil Rights Act, and the Americans with Disabilities Act's own guidance covers algorithmic disability discrimination in hiring directly. Several states now require bias audits or candidate disclosures before an employer can lean on automated hiring tools at all. The regulatory picture keeps shifting, and country to country it looks different again, so treat that shift as permanent rather than checking it once and moving on.

The fix is architectural, not legal advice: build the agent as a triage layer, never a decision layer. It scores. It ranks. It writes a rationale a human can read in ten seconds. It never auto-rejects anyone, and every candidate that leaves the funnel does so because a person looked at the file and made the call. That is not a compliance workaround. It is also just better hiring, because a résumé missing one exact keyword is not the same thing as a bad candidate, and a model with no human backstop will make that mistake quietly, at scale, and you will not find out until a good hire went to a competitor.

The build: six nodes, one afternoon

Here is the workflow, node by node, buildable in a tool like n8n, Make, or Zapier with an AI step, wired to whatever spreadsheet, Airtable base, or applicant tracker you already use.

1. Webhook trigger. Your careers page form, your ATS, or a simple Airtable automation posts two fields whenever a resume arrives: the resume text (or file) and the role ID the candidate applied for. Nothing else is required at this step.
2. Resume parser. If resumes arrive as PDFs, run them through a document extraction step for text-based files, and route scanned or image-based resumes to a vision-capable model instead. Output clean plain text, and keep it under roughly 8,000 tokens so you are not paying to process formatting noise.
3. Job description vector lookup. This is the step almost every tutorial skips. Before you ever score a candidate, embed every open job description with a text embedding model and store it in a vector database such as Supabase's pgvector extension or Pinecone, tagged with its role ID. At runtime, this node takes the role ID from the webhook payload and pulls back the matching job description text. No embedding math happens live on the job description side, just a fast, cheap, deterministic keyed lookup.
4. Scoring agent. One AI step, and a small, inexpensive model is enough for this job. The system prompt is generic and never changes: it tells the model it is a recruiter, that it will receive a job description and a resume, and that it should score the candidate from zero to 100 across four dimensions, skills match, experience match, seniority fit, and red flags, returning JSON with the four scores, a one-sentence rationale per dimension, and a recommendation of advance, hold, or reject. The job description from step three and the resume from step two are injected into the user message. The prompt is a template. The context is what changes.
5. Validator. If the model returns malformed JSON, retry once, then route the file to a human review queue instead of failing silently. A silent failure that writes nothing back to your tracker will quietly poison a client's or a hiring manager's pipeline, and nobody will notice until someone asks why a strong candidate never showed up.
6. Write-back. Log the candidate ID, role ID, the four scores, the rationale, the recommendation, a timestamp, and which model version produced it. That last field matters more than it sounds: when a hiring manager asks why a candidate scored 62, you need to be able to answer with the exact prompt and model that produced the number, not a shrug.

A seventh, optional node sends a message to whichever channel your team already uses, Slack, WhatsApp, email, whenever a candidate scores above whatever threshold you set, so a recruiter gets a name, a role, and a link, instead of having to check a dashboard.

What you have after this

A week in, Marcus has one workflow instead of six half-finished ones, and every resume that lands gets scored the same afternoon it arrives instead of sitting in an inbox until Friday.

A month in, adding a new client's roles is a spreadsheet row, not a new build. His recruiters spend their mornings talking to the top of a ranked list instead of skimming ninety-one unread emails to find it.

Six months in, the workflow that took him one afternoon to build is quietly doing the job a $39-a-seat-per-month platform charges his competitors for, and the only thing that has changed about it since week one is how many rows are in the table.

Same owner, same team, a completely different Monday morning.