What open source changes in a sourcing job
Sourcing a candidate comes down to two decisions and one message. Is this person already in your pipeline, and is anyone on your team about to email them? Open-source candidate sourcing puts both decisions in files your team can read. The rule that drops a name is then as visible as the draft that arrives.
Inside a closed product, the dedupe logic sits inside the product. You get back the profiles it kept. The condition that removed someone already in Greenhouse stays with the vendor, where you cannot diff it. A repo changes that. The rule is a line in a file next to the prompt and the schedule, so a change to who gets contacted arrives as a diff you can read before it applies.
The rest is ordinary work, most of it covered in how to source candidates. Read the role's Greenhouse pipeline. Search LinkedIn against a profile of title, seniority and skills. Drop everyone already known. Write an email for each new match from real details in that person's background. Kortix publishes one version of this as a setup you can put into your own project (Kortix).
The dedupe rule, before the first draft
A candidate who receives the same cold email twice remembers it, and the second one costs you the first. The agent reads the role's pipeline for applicants, anyone already contacted, and anyone rejected or passed on. Then it drops every match it finds there before writing a word. The rule names the stages it checks, so a team whose pipeline has an unknown stage adds it to skills/outbound-sourcing/SKILL.md, and the next run applies it. One line removes the failure that is hardest to apologize for.
A sourcing product that ranks profiles stops at the list, and AI candidate sourcing covers that shape. The list is where the expensive part starts. Someone still has to check every name against the pipeline before a message goes out, and that check is the one skipped on a busy day.
The send boundary is a capability the agent does not have
Instructions in a prompt can be argued with. The sourcing agent's boundary is an action that does not exist: each run ends with one batch in the review inbox, and sending is a step a person performs. Drafts carry the candidate's current role and the reason they matched, so the review is mostly a read. The Greenhouse connection stays read-only, which makes the ATS a source the agent consults and never a place it edits.
The profile and the run cap are lines you can argue with
Most weak batches start with a profile that is too broad or too narrow. Review time is set by how many drafts one run produces, and both are written down. The profile is text in the skill. The cap is the sentence "Draft at most 20 candidates per run." A team that wants ten drafts a day edits 20 to 10, and the change request shows the edit to whoever reviews it. A cap that lives in a vendor's settings panel gets negotiated with a support ticket instead.
Where the rules live
Three files hold the job. agents/candidate-sourcing.md carries the prompt for one sweep. skills/outbound-sourcing/SKILL.md carries the rules that prompt loads: the dedupe, the profile, the rewrite instruction and the cap. kortix.yaml carries the agent block and the daily-sourcing-sweep trigger that fires it every morning at 07:00 UTC. Session work reaches main through a change request. Merge is default-deny for agents.
That arrangement matters most for the rule that decides who gets contacted. The person who owns the pipeline can review the change, and the review shows the old line next to the new one. A rule nobody outside the vendor can read is a rule you can only trust or leave.
What self-hosting means for candidate data
Candidate data is other people's information: a name, a current employer, the detail that made them a match. Self-hosting decides which network holds it. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.
The connections work the same way in either place. Connector credentials are brokered server-side and never enter the machine. That covers the LinkedIn and Greenhouse connections the sweep uses. The Greenhouse connector reads the role's pipeline. The batch comes back through the review inbox as plain text a recruiter can edit. Each sweep is scoped to one open role, and only the drafted emails are written back out.
What you still do yourself
Open source moves the rules into your repo. It leaves three jobs with the recruiter: reading every draft, sending the ones worth sending, and deciding who goes into the ATS.
Kortix's own walkthrough shows one worked run with this caption: "Illustrative example. Your counts depend on the role and the sourcing profile." In that example, 31 LinkedIn profiles are reviewed, 13 are dropped as already in the pipeline, 18 emails are drafted, and nothing is sent.
Expect different numbers in your first week. Note how many profiles a sweep drops as already known. Note how many drafts you would send without editing, and which edit you make twice. The repeated edit belongs in the skill file, where it changes every later run. If you are still comparing options, candidate sourcing tools covers the pieces each one ships.
Starting with one role
Pick one open role with a bar you can describe, write its sourcing profile as three lines, and run one sweep by hand before any schedule exists. Read every draft in the batch. The first batch tells you three things: whether the profile is right, whether the drafts sound like your team, and whether the dedupe catches the people you already know.
Then let the cron take over and keep the review step. The agent's value is a morning batch that has already searched and deduped. The send stays a decision a person makes, which is what makes the setup reasonable to run against real inboxes.