SThree's AI recruitment platform is live and used in real hiring. It matches candidates to roles, analyses CVs, conducts phone interviews and produces shortlists for SThree recruiters or client hiring teams. Who takes responsibility for the next decision depends on the workflow.
I joined as one of two founding AI engineers in a five-person group with the COO, Sales Director and Director of AI. Since then, I have helped conceive the platform, design the system, build and improve the AI backend, strengthen its reliability and make wider technical decisions. The AI engineering team grew from 2 to 20, and the dedicated recruitment-platform team is now close to 100 people.
We needed to test the platform while real applicant data was still limited. Manually created cases did not give us enough variety, and they were a poor way to investigate bias or a regression because the conditions were hard to repeat. I wanted to build a controlled applicant population for a particular company and job, then follow those people through the whole hiring journey. I built Aurum to do that.
I conceived, designed, built, tested and productionised the system. Teams across AI engineering, AI safety and testing use it to challenge the live recruitment platform and check whether a change has fixed one problem without causing another.
Building a population, not a pile of CVs
Aurum begins with a company and job description. Research agents gather context, question weak assumptions and improve the job description before the system creates any applicants. It then defines the population those applicants will come from. The distribution can be broadly balanced or deliberately skewed by gender or ethnicity, which gives teams a controlled way to test whether the platform behaves differently for different groups.
The hardest part was turning that distribution into hundreds of distinct people. Early versions repeated names, profile shapes and CV patterns too often. A single candidate could look believable while the batch around them was obviously synthetic. That made the data much less useful as a test of the live platform.
Solving that problem is one reason Aurum grew into a 25-agent system. Different stages need different information, hundreds of candidates have to be produced efficiently, and separate checks are needed to catch repetition and inconsistency. The system now researches the role, builds and checks the distribution, creates profiles and CVs, runs interviews, scores the evidence and analyses the resulting population. Each stage passes only the information the next stage needs, and long runs can recover from a failure instead of starting again.
The candidates are not written as uniformly good or bad. Someone can have a strong CV and then give a weak phone interview. Another person may look less conventional on paper but perform well when interviewed. Aurum creates the interview separately from the CV and records a CV score, interview score and whole-candidate score. This lets a team see whether the recruitment platform is relying too heavily on one source or treating conflicting evidence in an unexpected way.
Once a batch is complete, the system compares scores and outcomes across demographic groups and combinations of groups. These results guide investigation rather than declaring that a system is fair. A team can alter one part of a controlled population, rerun it and see whether the same pattern remains.
The same approach works for deliberate challenges and ordinary engineering changes. Teams can try to expose a weakness, change a prompt, piece of code, model or scoring rule, then rerun the same scenario. This makes Aurum useful both for finding failures and for checking that a proposed fix holds. I cannot publish the individual cases it has found because this is employer work, but the tests are used against the production recruitment platform.
A useful approximation
I do not distrust synthetic data. I think it is a very good and inexpensive approximation of the real world, and it can take development most of the way before enough real applicant data exists. It is less dependable at the tails of a distribution, where cases are rare. Real data has the same practical difficulty in those areas because there are fewer examples to learn from or compare.
The synthetic population is still an approximation. We have begun comparing Aurum's generated distributions with real applicant distributions so we can see where they overlap and where they do not. If they diverge, we need to understand whether the simulation is wrong or whether there is a defensible reason for the difference.
Aurum gives SThree's engineering, safety and testing teams an inexpensive, repeatable way to improve the platform early without pretending that generated candidates are real applicants. Comparison with real distributions shows us where the simulation still needs work, and real applicant data has the final say in refinement and validation.