HelixML
Helix Recruiter

Sourcing that keeps going after your consultants go home.

LinkedIn Recruiter has no public API, so an agent has to use it the way a person does. Helix gives the agent its own Linux desktop and a real browser, hands it the seat at the end of the day, and writes the results back to Bullhorn. A human reads and sends every message.

Talk to us about a pilotRead how we built it →
Your Recruiter seatBullhorn stays the system of recordNothing sends itself
Why this is hard

Recruitment automation stops at the tools with no API

A recruitment agency in London asked us for something their CRM vendor could not sell them. They wanted sourcing to continue after their consultants went home.

The obvious version is an integration. Bullhorn has a documented REST API, so writing candidates and notes into it is ordinary software work. The problem is that Bullhorn is where sourcing ends, not where it happens. Sourcing happens in LinkedIn Recruiter, and LinkedIn Recruiter has no public API.

  • Constraint 01No API means the browser is the interfaceAnything the system does in Recruiter, it does by loading pages and clicking. There is no shortcut layer underneath, and no LinkedIn Recruiter automation tool can create one.
  • Constraint 02A seat does not like being used twice at onceSeats are licensed per named user. Simultaneous sessions from two places get treated as account sharing, which consultants already notice when they log in from a second device.
The approach

Give the agent a computer, then take turns on the seat

Helix runs each agent on its own Linux desktop: a container with a real graphical environment and a real browser. We built this for coding agents so they could run an IDE and see what they were doing. Sourcing uses the same thing for a different reason. A desktop is a general-purpose interface to software that has no other interface.

The desktop is shared. A consultant connects through their browser, sees what the agent sees, and has the mouse and keyboard. That turned out to matter more than the automation did. The criteria that make a candidate right for a brief are mostly tacit, so a consultant running the search once while talking through what they are looking at transfers more than an hour of written instructions would.

One Recruiter seat · 24 hours
  • Consultant
  • Agent desktop
The consultant uses the LinkedIn Recruiter seat from 08:00 to 18:00 and the agent desktop uses it from 18:00 to 08:00A 24-hour bar. The daytime segment is the consultant sourcing, calling and sending. The overnight segment is the agent sourcing, screening and drafting. Handover markers sit at 18:00 and 08:00.00:0004:0008:0012:0016:0020:0000:00AGENT · sources, screens, draftsCONSULTANT · calls, meets, sendsAGENT18:00 seat handed to the agent08:00 project populated, drafts waiting
Never both at once: LinkedIn treats a seat used from two places as account sharing. The handover is a product requirement, not a scheduling preference. Recruiter seats are licensed per named user, so the agent only works the account when the consultant is not.
The night shift

What happens between 18:00 and 08:00

At the end of the day the consultant hands their Recruiter session over. The agent has the account to itself for the hours nobody is using it.

  1. 1
    Work the live searchesThe agent opens the saved searches for each open brief and pages through results the way the consultant showed it to.
  2. 2
    Open and screen profilesEach profile is read against the brief. Ones that fit are added to the Recruiter project for that role, with a short note on why.
  3. 3
    Draft outreach in the consultant's voiceA first-draft message sits against each candidate, written in the register of the messages the consultant wrote by hand.
  4. 4
    Write structured records to BullhornCandidate records and notes go into the CRM through its API. Bullhorn stays the system of record.
  5. 5
    Post a batch summary to SlackOne message when a batch lands, so the team knows what is waiting before they open Recruiter.

The output is not a report. It goes back into the tools the team already opens first thing. Nothing is sent. Every draft waits for a human to read it, change it, and press send.

Your stack stays

No migration, and no new tool for consultants to learn

The agent works the systems you already pay for. Results are written back through your CRM’s API, so the record of a candidate lives where it always lived.

Recruitment tasks by tool, whether they are automated today, and whether a Helix agent takes them on
TaskTodayWith a Helix agent
Multiposting job adsJob boardsAutomatedAutomatedAlready solved by the boards and your ATS.
Email and InMail sequencesCRM / sequencerAutomatedAutomatedFires on a schedule. Cannot find new people.
Parsing CVs into fieldsATS / CRMAutomatedAutomatedStructured data out of a document.
Searching and screening on LinkedIn RecruiterLinkedIn RecruiterManualAgent, human approvesNo public API. The agent runs the search in a real browser.
Building the long list into a projectLinkedIn RecruiterManualAgent, human approvesCandidates land in a Recruiter project overnight.
First-draft outreach in your voiceRecruiter + CRMManualAgent, human approvesDrafted by the agent. Read, edited and sent by a person.
Writing sourced candidates back to the CRMBullhorn APIManualAgent, human approvesWritten through the API. Bullhorn stays the system of record.
The top three rows are what recruitment automation software already covers. The four below are where consultants spend their day, and none of them has an API to integrate with.
What to expect

It made them busier, not smaller

The first thing the agency told us after a week was that it was keeping them busier. We had been ready to defend a time-saved number. What actually happened was that the bottleneck moved. Sourcing had been the constraint, so the pipeline was shaped by how many profiles two delivery consultants could get through. Once sourcing ran overnight, the constraint became the number of real conversations the team could have the next day, which is the part of the job they are paid for.

For a high-touch agency that is the trade they want. For one running volume outreach with minimal human contact it is not, and the honest answer there is that a cheaper sequencing tool does that job. Review capacity is the new ceiling: the agent drafts faster than a consultant can approve, and past a point you are queueing work for people rather than removing it.

Planning model · one desk · per working weekEvery input is an assumption. Change them.
Profiles screened3,750750 by consultants, 3,000 overnight
Shortlisted for review300was 60 without agents
Review capacity150150 would queue. This is the ceiling.
  • Shortlisted by consultants
  • Shortlisted by overnight agents
  • Weekly review capacity
The agent screens at the same rate as a consultant in this model. The gain comes from hours the seat would otherwise sit idle. When the shortlist crosses the review line, the bottleneck has moved to your team, which is the point at which adding agent hours stops helping.
Before you buy

What to know before you start

Candidate data is personal data. Sourcing produces CVs, contact details and notes about identifiable people, and the agency is the controller for all of it under UK GDPR. That is one reason the whole system runs on the agency’s own infrastructure with models running locally. It is also why a person approves every message. Automated decision-making about identifiable people is a place you want a human standing.

Browser work is also slower and more brittle than an API. A REST call either succeeds or returns an error. A page load can succeed and be the wrong page, so the agent has to check it is where it thinks it is, and interfaces change without notice. This needs maintenance in a way an API integration does not. The full write-up covers how we handle it.

Frequently asked questions

Is there a LinkedIn Recruiter API?
No. There is no public LinkedIn Recruiter API and no partner programme that opens Recruiter search to a third party the way the Bullhorn API opens a CRM record. If you want a machine to run a Recruiter search, the machine has to use Recruiter in a browser, the way a person does.
Does the agent use the same seat as my consultant?
It uses the same seat, but never at the same time. Seats are licensed per named user, and simultaneous sessions get treated as account sharing. The consultant hands the session to the agent desktop at the end of the day and takes it back in the morning.
Does it send messages to candidates automatically?
No. Drafts are written against each candidate in the consultant's register, and they sit there until a human reads, edits and sends them. Automated decision-making about identifiable people is exactly where you want a person in the loop.
Do we have to move off Bullhorn?
No. Bullhorn stays the system of record. Candidate records and notes are written back through its documented REST API, so consultants keep the tool they already know.
Where does the candidate data live?
On your own infrastructure. The system runs on the agency's hardware with models running locally, which matters because the agency is the data controller for CVs, contact details and notes under UK GDPR.