RealAIzation ran the hiring loop as one system: a job description generated from a brief, candidates found across five or more data sources, each one scored against the role with a written rationale, then outreach personalised per person. The hard part was never the model call — it was making the machine's judgment legible enough that a recruiter would act on it, or overrule it.
- 50+Enterprise clients deployed toStated as deployment to more than fifty enterprise clients. Whether this counts trials or production tenants is not described. Method, denominator and measurement window unspecified. · as of 1 Mar 2025
- 1,000+Passive candidates identifiedStated as more than a thousand passive candidates surfaced across five or more data sources. Method, denominator and measurement window unspecified. · as of 1 Mar 2025
- 40%Sourcing efficiency gainStated as a 40% improvement in sourcing efficiency against the prior manual workflow. The baseline is not described. Method, denominator and measurement window unspecified. · as of 1 Mar 2025
- 30%Hiring accuracyStated as 30% higher hiring accuracy with the scored pipeline. Who assessed it, against what, and over what window are not described. Method, denominator and measurement window unspecified. · as of 1 Mar 2025
The problem
Sourcing was capped by how many places one recruiter could search by hand. The candidates worth approaching were passive and scattered across several platforms, each with a different schema, a different rate limit, and no shared notion of who a person is.
A score with no reason attached is unusable in hiring. Nobody forwards a ranking they cannot defend to a hiring manager, and any system that ranks people inherits a bias problem the moment it is switched on.
The system
Four stages in one loop: orchestrate, source, score, sync.
What it is made of
- An orchestrator that selects a strategy per job and re-plans between steps, with reflection passes that read the previous step's output before committing to the next.
- A sourcing agent that queries five or more data sources, with a scripting layer that generates custom scrapers for niche talent pools exposing no usable API.
- A scoring engine held to a written rationale per candidate, with bias guardrails in the path and a semantic memory that contextualises each assessment against historical hiring data.
- An applicant-tracking bridge with two-way webhook sync across three or more providers, so postings go out and candidate state moves back without anyone re-typing it.
My role
I built the AI layer across the three-month engagement: the orchestrator and its reflection loop, the sourcing agent and its scripting layer, the scoring engine and the rationale format it had to produce, and the applicant-tracking integrations. Most of the work was not model work. It was getting four unreliable inputs to agree on a single candidate record: third-party data sources with their own idea of identity, a model that will assert anything fluently, a webhook feed that arrives out of order, and a recruiter who is right often enough to be worth listening to.
The decisions
Explainability sits inside the scoring path, not beside it. Every score carries a written rationale produced in the same pass as the score, with bias guardrails in the path and past hiring decisions supplied as context. A ranked list with a bare number is faster per candidate, cheaper to run, and far easier to render in a table. The trade is more tokens and more prompt surface per candidate, in exchange for a recruiter being able to dispute one specific line instead of distrusting the whole ranking.
Sourcing reaches past what integrates cleanly. The sourcing agent generates and runs custom scripts against talent pools with no usable API, rather than confining the search to sources with a stable integration. API-only sourcing is stable and cheap to operate, and restricts every search to the same handful of indexed pools every competing tool also reads. The standing cost moves to the scraping layer, which breaks whenever a source changes its markup and fails quietly by returning fewer candidates rather than an error — so it has to be treated as an expected failure mode with its own monitoring rather than as an incident.
The outcome
The platform shipped inside a three-month engagement, with the sourcing agent, the scoring engine and the two-way applicant-tracking sync all in it. Every number on this page is self-reported from the role period rather than an audited measurement.
What is unresolved
The bias guardrails sit downstream of a semantic memory that contextualises each assessment against historical hiring data — which is the record of who the company hired before. A guardrail applied after the context has already been assembled from the past's preferences is a filter on the output, not a fix for the input, and I never found a clean way to separate useful precedent from encoded preference. The accuracy claim has the same shape of problem: hiring accuracy is only knowable a year out, when you can see who stayed, and a three-month engagement is not long enough to test it. What the number really records is that the hiring team agreed with the system more often.