You watched someone build "an entire AI recruiter team in Claude Code in 15 minutes," and now you want to build your own. Or you are the founder who dropped a recruiting retainer, opened a terminal, and wants a repeatable setup instead of one-off prompts. Either way, you are past the point of asking whether Claude can help recruit. You want to construct something.
This is the build guide. It walks through scaffolding a recruiting agent in Claude Code, writing reusable skills as the building blocks, and chaining them with subagents into something that runs a real sourcing workflow. It also does the part the 15-minute videos skip: the honest ceiling every DIY agent hits, and what to do when you reach it.
One thing first, so you spend your time on the right page. If you mainly want to use Claude day to day, dropping a candidate pool into the desktop app and running workflows without building anything, that is a different job, and our Claude for recruiters guide covers it end to end. This article is the level below that: you are building the machine, not driving it. If that is not what you came for, start with the other guide.
What "a recruiting agent" means in Claude terms
The word "agent" gets used loosely, so here is the precise version for a build.
Claude Code is a command-line tool. It reads and writes files on your machine, runs commands, and can work through a multi-step task on its own rather than answering one prompt at a time. That autonomy is what makes it an agent rather than a chatbot. You do not need to be an engineer to use it, but you do need to be comfortable in a terminal and willing to maintain what you build.
Three pieces make up the build. A skill is a saved bundle of instructions (and optionally scripts and templates) that teaches Claude to run one task the same way every time. A subagent is a separate Claude instance you hand a scoped job so the main thread stays clean. And MCP is the protocol that lets Claude reach an outside system, an ATS, a database, a sourcing platform, instead of only the files on your disk. You assemble those three into a setup that scaffolds a role, sources against it, and drafts the output, then reruns the same way on the next req. For the plain-language primer on what skills are and how they behave across Claude products, the Claude for recruiters guide has the fuller version; here we treat them as components to build with.
Step 1: Scaffold the project
An agent that drifts every run is worse than no agent. The fix is a fixed project structure Claude reads the same way each time. In a new folder, the shape most working setups converge on looks like this:
recruiting-agent/ CLAUDE.md # standing instructions: your voice, rules, do-nots skills/ intake-to-brief/ ecosystem-map/ screening-notes/ outreach-draft/ roles/ senior-backend-eng/ # one folder per open req jd.md intake-notes.md shortlist.csv templates/ outreach.md brief.md
The CLAUDE.md file is the load-bearing piece. It holds the instructions Claude reads at the start of every session: your tone, your must-do and never-do rules, the compliance lines you will not cross (no filtering on protected attributes, no autonomous hire or reject decisions). Write it once and every run inherits it. This is also where you encode the rules that keep the build on the right side of US hiring law, which matters more the more autonomy you give it.
Step 2: Build the skills as reusable blocks
Each skill is one job the agent does the same way every time. Build them small and single-purpose so you can chain and reuse them. A skill is a folder with an instructions file and, when useful, a template. The instructions for an intake-to-brief skill read roughly like this:
Read the role's intake-notes.md and jd.md. Produce a sourcing brief using templates/brief.md: must-haves (max 5), nice-to-haves, deal-breakers, ideal titles and company types, a comp band to verify, and the three questions still open for the hiring manager. Do not consider protected characteristics. Flag anything too vague to source against.
The four skills that cover most of a sourcing loop are intake-to-brief (messy notes to a structured brief), ecosystem-map (from the brief, the companies, communities, and title variants to search), screening-notes (a resume against the role rubric, as notes and questions for you, never a score or a verdict), and outreach-draft (a personalized first message per candidate from a real hook). Keep each one narrow. A skill that tries to do the whole pipeline is the one that drifts.
The screening skill is where compliance lives or dies. Write it to produce notes, gaps, and follow-up questions, never a ranking or a hire recommendation. A DIY agent that scores an applicant funnel to drive decisions can become an automated employment decision tool under NYC Local Law 144 and Illinois HB 3773, with audit and disclosure duties attached. None of this is legal advice, but the safe pattern is to keep the human in every decision, and to encode that in the skill itself.
Step 3: Chain them with subagents
Once the skills exist, a subagent runs each stage on a scoped brief and reports back, so the main thread orchestrates instead of doing everything itself. A practical loop for one req: the main agent reads the role folder, hands the brief to a sourcing subagent that runs the ecosystem-map and returns candidates, passes each to a screening subagent for notes, and sends the survivors to an outreach subagent for drafts. You review at the gates. The value of subagents is isolation: a long sourcing run does not clog the context the screening step needs to be accurate.
This is the point where most DIY builds feel like magic, and also the point just before they hit their real limit. The loop works. What it runs on is the problem.
Step 4: Connect real data (this is where it gets hard)
Your agent can now scaffold, reason, and write. What it cannot do yet is know anything about the outside world beyond what you hand it or what it can scrape. That is what MCP and tool connections are for, and it is where the DIY path gets genuinely hard.
Out of the box, a Claude Code recruiting agent reaches three kinds of data: the files on your machine, whatever public web pages it can read, and any service you have wired up through MCP. Recruiters on Reddit report building lead-gen and sourcing loops exactly this way, connecting Claude to their own tools through MCP. That works for data you already own. It does not conjure data you do not have.
And the data a sourcing agent actually needs, a live and current view of the talent market, is the part you do not own. Which is the wall.
Where the DIY path stops
Read back over the build. Every step runs on information you supply or the agent scrapes: your notes, your ATS export, public profiles. That is the ceiling, and it is a hard one.
A DIY Claude agent has no live talent market. It cannot tell you who changed jobs last week or who is quietly open to moving right now. It has no compensation model, so it will guess a salary band or invent one rather than tell you what a Senior Platform Engineer in Denver actually commands this quarter. It has no reliable read on who is receptive before you reach out, so it cannot save you from burning hours on people who will never reply. Contact data scraped ad hoc is patchy and ages fast. And all of it is yours to maintain: every source change, every broken scrape, every model update is your problem now. We made the fuller version of this argument in why DIY and custom-GPT sourcing agents hit a data wall, and it is worth reading before you commit weeks to a build.
None of this means the build is wasted. It means you have built an excellent operator and handed it no engine.
The setup that actually works: DIY agent plus a real data layer
The clean division of labor is to let the thing you built do what it is good at, and hand the market data to a system that actually has it.
Your Claude agent is strong at the work around a search: reading intake into a brief, mapping the ecosystem, drafting outreach, keeping your pipeline notes consistent. Glozo is built for the half your agent cannot reach. Its Sourcing Agent runs in the background on 10M+ market signals a month and returns three reads no DIY setup can produce: a matching summary built from a Skill Graph rather than keyword overlap, a Market Compensation Estimate that puts a live salary range on each person, and an "Open to Offers" signal that surfaces who is likely to be receptive before you spend a credit. It is live today, free, in manual mode.
So the workflow is not "replace your build." It is your Claude agent preps the search and operates it, Glozo runs the sourcing on data your stack cannot reach, and the results come back to your agent for the language work. A Glozo MCP server is in internal testing and expected in summer 2026, which will let your Claude setup call Glozo natively instead of through a browser, and widen the set of things the two can do together. If you are comparing purpose-built agents before you decide, our field test for telling a real sourcing agent from a chatbot with a search box and the roundup of the best AI sourcing agents both help.
Cost and upkeep, honestly
A DIY Claude Code agent runs on API usage, so cost scales with how hard you run it, typically a few dollars a day for an active desk rather than a per-seat license. The real cost is not the API bill. It is maintenance. You are the one who fixes the broken scrape, updates the skill when a source changes its layout, and re-tests the loop after every model update. If you enjoy that, the DIY path is genuinely powerful. If you do not, a self-hosted option like OpenClaw trades setup effort for less prompt-wrangling, and a purpose-built agent trades control for someone else owning the upkeep. Match the choice to how much building you actually want to own.
How to decide
Build a DIY Claude agent if you are comfortable in a terminal, you want full control over how every step works, and you have the appetite to maintain it. You will get a setup shaped exactly to your desk.
Use Claude in the desktop app instead if you want the workflows without the build, in which case the Claude for recruiters guide is your starting point, not this one.
Whichever you pick, pair it with a real data layer for the sourcing itself, because that is the one part no DIY build reaches. The agent you construct is the operator. The market data is the engine. Keep those jobs separate and both get better.