The Sourcing Nightmare: Finding the Needle in the Haystack
Last quarter, we needed to find a very specific kind of backend engineer: someone with deep experience in Rust, distributed systems, and, critically, a background in financial services compliance. Not just any compliance, but SEC regulations for trading platforms. The kind of person who doesn’t just exist on LinkedIn with a clear job title. Our usual sourcing methods — a mix of manual LinkedIn searches, a few niche job boards, and asking around — were failing us. We were spending hours sifting through profiles, only to find candidates who were close, but not quite right. It was slow, expensive, and frankly, soul-crushing for the recruiting team.
That’s when we decided to build an agent. Not a fully autonomous, ‘hire-them-for-you’ bot, but a smart assistant designed to augment our human sourcers. The goal was simple: find those elusive profiles, qualify them against a strict set of criteria, and present a curated list for human review. This is how AI optimizes talent sourcing in a way that actually moves the needle, not just generates buzz.
Building the Sourcing Agent: What Broke and What Worked
We started with LangGraph. Its state management capabilities felt like a good fit for a multi-step sourcing process: search, filter, enrich, qualify. Our agent’s initial workflow looked something like this:
- Initial Search: Query various public data sources (LinkedIn, GitHub, specific industry forums, even some academic paper databases) using a combination of keywords.
- Profile Extraction: Pull relevant text from identified profiles.
- Filtering & Scoring: Apply our specific criteria (Rust, distributed systems, SEC compliance) to score candidates.
- Enrichment: Attempt to find contact information or additional public data points.
- Output: Present a ranked list of candidates with extracted data.
The first version was a disaster. It’d loop endlessly on certain profiles, or misinterpret ‘experience with Go’ as ‘experience *going* to conferences’. It also had a nasty habit of confidently declaring a candidate a perfect fit based on a single keyword mention, completely missing contradictory information elsewhere in their profile. We quickly learned that agents, left unchecked, are excellent at hallucinating confidence.
Debugging was a nightmare. Without visibility into the agent’s internal monologue, it was just a black box spitting out bad data. LangSmith became essential here. Seeing the trace, step-by-step, where the agent decided to ignore a negative keyword or got stuck in a parsing loop was invaluable. We could pinpoint exactly which tool call failed or which LLM prompt led to a bad decision. For instance, we found one prompt was too open-ended, allowing the LLM to invent experience rather than extract it. Tightening that prompt, and adding explicit negative constraints, made a huge difference.
We also ran into cost overruns. Our initial search queries were too broad, leading to excessive API calls and token usage. Monitoring with Langfuse helped us catch those runaway costs before they became a real problem. We could see, in real-time, which parts of the agent’s execution were the most expensive and optimize them. For example, we implemented a pre-filtering step using a cheaper, smaller model to discard obviously irrelevant profiles before passing them to the more expensive, more capable LLM for deeper analysis.
The Realities of Compliance and Data Handling
When you’re dealing with publicly available PII, even if it’s public, you need audit trails. Our early agent didn’t log *why* it decided to contact someone, just *that* it did. That’s a non-starter for GDPR and other privacy regulations. We had to build in explicit logging for every decision point: what data was collected, from where, what criteria it met, and when it was processed. This isn’t just good practice; it’s a legal necessity when your agent touches real user data.
Integrating with our existing Applicant Tracking System (ATS) was another hurdle. Once we had a clean, qualified list, pushing it into our ATS (we use Workable, which has a decent API for this sort of thing: Workable) was the next step. It’s not just about finding candidates; it’s about getting them into your existing pipeline without manual data entry. We used n8n for the integration, building a simple workflow to map our agent’s output to Workable’s candidate fields. This saved our recruiters hours of copy-pasting, which was a concrete love for the team.
The agent’s ability to consistently pull in candidates from obscure forums, places a human recruiter would never think to check, was a real win. It expanded our reach significantly beyond the usual suspects. But the compliance headaches, though. Ensuring data was handled correctly, that we weren’t scraping private information, and that we had a clear data retention policy for everything the agent touched was a constant battle. It’s easy to forget these things when you’re focused on getting the agent to *work*.