200 profiles reviewed, fewer than 5 worth reaching out to

Direct sourcing means companies proactively reach out to talent instead of posting job ads and waiting for applicants. Senior and lead-level talent rarely appears on the job market, so companies have no choice but to make the first move.

The problem is that the entire process is manual — LinkedIn searches, profile analysis, skill assessment, message writing, and scheduling. The image below shows the full direct sourcing pipeline automated in this project.

Before diving into the details, take a look at how this pipeline actually works in practice. This SaaS platform demo shows the entire flow — from position definition to candidate search, evaluation, and outreach — all handled through a chat interface in one place.

From B2B list delivery to a self-service SaaS sourcing platform

The first meeting wasn't at the client's office — it started beside the TA team of a company actually struggling with hiring. We watched a recruiter opening LinkedIn profiles one by one from morning, copying names and experience into a spreadsheet.

Then we asked a hiring manager, "What kind of person do you want?" and stories poured out that weren't in any JD. "Someone who's personally dealt with large-scale traffic at least once. Not someone who follows the manual, but someone who can make judgment calls during incidents." None of that context was in the JD. Closing that gap was the starting point of this project.

The first thing we built was a 'Role Definition Engine.' When a hiring manager inputs their expectations in natural language, the AI breaks it down into must-haves, nice-to-haves, and risks.

Enter "They need to solve this problem within 6 months of joining" and you get items like '3+ years distributed systems ops experience,' 'open-source contribution history,' 'risk: management-only background with no hands-on.' It also defines 'skill signals' to verify each item, down to what specific projects or metrics confirm 'large-scale traffic experience.'

It was the first time the hiring manager's mental model of 'a good hire' was actually written down.

To get accurate criteria out of this engine, we couldn't rely on gut-feel prompting. We built a system that automatically generates 100+ prompt variations combining Chain-of-Thought, Few-shot, and Negative prompts, then has an in-house recruiting expert team qualitatively evaluate each result. We selected the highest-accuracy combination and built it into the system.

Next was candidate discovery, and this is where we hit the biggest technical challenge. Good people aren't gathered in one place. LinkedIn profiles, GitHub commits, tech blogs, conference talks, open-source contributions — all scattered across different platforms.

Just collecting data wasn't enough. The key was 'competency metadata enrichment.'

We stitch scattered data fragments into a single candidate profile and layer capability signals on top. How much someone contributed to what scale of projects on GitHub, what depth of technical writing they do on their blog. Stitch these fragments together and capabilities invisible on a resume alone start to emerge.

Once the data was collected, the real challenge began. For the LLM-based inference system to evaluate candidates, the AI needed to precisely understand 'what this person did, when, and where.'

But LLMs have a weak sense of time. A candidate with a tenure from 2020-2022 would be evaluated based on press releases from 2018-2020 — a pattern that kept repeating. It was a problem validated by the academic community as well.

To solve it, we had to rework the RAG (Retrieval-Augmented Generation) pipeline itself. We attached time-series metadata — employment start and end dates, time buckets — to the embeddings, and applied hard filters at retrieval to return only chunks overlapping with the requested employment period. With this in place, cases of the model citing irrelevant historical data as evidence completely disappeared.

After solving the time-series problem, we hit context window limits. As a candidate's competency tags grew, the evidence context for each tag increased non-linearly. Exceeding the context limits of commercial models became frequent.

We solved it three ways. First, we decomposed queries by tag and ran parallel retrievals. Second, for data with long, repetitive content like news articles, we used an LLM to compress down to key sentences and keywords before embedding. Third, we placed the query at the end of the prompt to mitigate the 'Lost in the Middle' phenomenon.

On top of that, we introduced a multi-model ensemble — one model reasons, another cross-validates. This filters out hallucinations and biases from any single model, producing evaluation results that hiring managers can genuinely understand and trust.

Collecting candidates is an engineering problem, but evaluating them is different. We needed to capture that intuition where a hiring manager looks at a profile and says 'not this person' within 10 seconds. Simple keyword matching doesn't work. '5 years of Python' on a profile doesn't make someone a good backend engineer.

What we built is a 'job performance prediction engine.' For each rubric item, it maps evidence collected from a candidate's public data and generates both a score and a summary.

'Does this candidate have distributed systems experience?' → 'Key committer on a Kubernetes-based microservices project for 2 years, 3 blog posts on handling large-scale traffic.' Evaluation with evidence attached.

Every decision was designed to record 'why.' Why this candidate made the short-list, why that one was excluded. When you tell a hiring manager 'it's automated,' skepticism is the default. We had to show them the actual basis for every call.

Even with a short-list, it's useless if candidates won't meet you. Template message reply rates are usually below 5%. That's 95% of effort going nowhere.

So we built a hyper-personalized message engine. Based on a candidate's public activity data, it automatically generates messages with 'why you' (mentioning this candidate's unique strengths) and 'why now' (the context of why this team is opening this position).

"I was impressed by your recent blog post on distributed tracing. Our team is dealing with exactly that problem right now." Messages at that level for 30 candidates, done in 20-30 minutes.

After a reply, the auto-conversion pipeline kicks in. Suggested available time slots, a 1-page candidate summary auto-shared with the hiring manager before the coffee chat. Candidates get the impression 'this team is well-prepared,' and hiring managers can understand why this candidate is good within 10 minutes.

After automating search and filtering, the client's next expansion area was 'actual connection with candidates.' It started as a B2B model — we built the shortlist and delivered it. But as demand grew, the client began transitioning to a SaaS tool that lets companies run their own sourcing. The structure allows everything from position definition to candidate search, evaluation, and outreach in one place, through an interface as intuitive as a chat UI. It's proven technology with a usable product layer on top.