What an AI sourcing tool does today
A sourcing tool starts with a database of people. You describe the role: a title, a seniority band, a few skills, a location. The tool turns that into a query, ranks the profiles in its index against it, and returns a shortlist. An export button turns the shortlist into a CSV or a push into an ATS. Some products bolt a sequence builder onto the list so one message can go to everyone on it.
The retrieval is the part this category does well. Searching LinkedIn by hand for a niche skill across four open roles is slow work, week after week. A database query answers it in seconds. Juicebox, hireEZ and Pin sell this shape of product. Each has its own data approach and a published seat price: Juicebox, hireEZ, Pin.
What comes back is a list of profiles. The row carries a headline, an employer, sometimes a skills list. What it cannot say is whether that person applied last week, was contacted in March or was passed on after a final round. Your ATS holds that record.
The two steps a ranked list leaves to you
The first is the check against the pipeline. A ranked list has no memory of who you have already spoken to. The recruiter reads each name against the ATS before writing. Kortix runs the same order on every sweep. Its sample run carries a label: "Illustrative example. Your counts depend on the role and the sourcing profile." In that sample, 31 profiles came back from LinkedIn and 13 of them were already in Greenhouse.
The second is the first touch. A template with a swapped-in name reads like a template. The people worth sourcing get several of them a month. A message that references one real detail takes a few minutes each to write. The detail can be a project someone shipped or the stack they list. Under time pressure, that is the first thing a recruiter skips.
Both steps sit after the search and before the send. A tool that ends at the export leaves both with you: a list to dedupe, and a batch of first touches to write before any of it is worth sending. A faster search only starts that work sooner, on a longer list.
What the Kortix agent does instead
On Kortix, the sourcing job runs as an agent in your repo on a schedule you set. A cron trigger fires at 07:00 UTC. It opens a fresh session on its own cloud computer, scoped to one open role. The role's sourcing profile comes from a skill file in the same repo: titles, seniority, skills, locations. The bar for a role is written down instead of rebuilt in each search.
Greenhouse comes first. The first rule in the skill file is: "Read the role's Greenhouse pipeline first: applicants, candidates already contacted, and anyone rejected or passed on." Only then does it search LinkedIn. A match that appears in the pipeline is dropped instead of drafted: "Drop every match that is already in the pipeline before you draft anything."
Drafting has its own rule: "Write each email from one or two real details in the candidate's background. If the draft reads the same without them, rewrite it." The two-detail rule separates a batch a recruiter can send from a batch they rewrite from scratch. The run ends with one batch of drafts in a review inbox.
The agent's prompt sits in agents/candidate-sourcing.md. The sourcing and drafting rules are in skills/outbound-sourcing/SKILL.md, and the schedule is in kortix.yaml. A change to any of them goes through a change request: "Session work reaches main through a change request. Merge is default-deny for agents."
The limits it sets on itself
The skill caps a run at 20 drafts: "Draft at most 20 candidates per run." Twenty is a batch one recruiter can read with attention in a sitting. A batch of two hundred gets skimmed. A skimmed draft is worse than no draft because it looks approved.
The second limit is the send. "Never send an email, and never create, update or tag a Greenhouse record." The agent has no send action and no write access to the ATS. Its own setup line reads "Sources and drafts only · recruiter reviews and sends". The recruiter edits each draft, sends it and decides whether the candidate enters Greenhouse. Everything after the send, from the reply to the interview, sits outside this agent's job.
Those limits live in the repo rather than in a vendor dashboard. Say your team wants 30 drafts in a batch, or a second role with its own profile. The change is a diff in a skill file that a person approves. The narrower question of what you run yourself is covered in the open-source case for the job.
What a week of runs tells you
Duplicates dropped is the number to watch first. If it stays at zero for a week on a broad profile, something is off. Either the profile is too narrow or the pipeline read is coming back empty, and both are worth fixing before the volume goes up.
Edits per draft tell you whether the personalization rule is landing. A recruiter who rewrites every draft has a skill file that needs their own examples in it. Take the angle that got a reply from a payments engineer: it belongs in the outreach notes, not in someone's head. Replies are the outcome measure. They take a couple of weeks to accumulate before they mean anything.
The last number is time from a role opening to the first reviewed batch. The step order is the same one a person runs by hand, set out in how to source candidates. Run as a daily job, the search, the pipeline check and the first draft are finished before the recruiter starts work.