Disclosure: some links in this article are affiliate links. If you sign up through one, HeroHunt may earn a commission at no extra cost to you.
Connection between people has always been driven by our human ability to connect and socialize.
But now more than ever it is also driven by another component: data.
The scarcity stopped being visibility a long time ago. LinkedIn alone reports more than 1.3 billion members, and it is one source among dozens. The real constraint is narrower and less flattering: can you describe who you want precisely enough that a machine can find them, and can you reach them once it has.
RecruitGPT by HeroHunt.ai is built for exactly that. It searches people on autopilot across 1 billion profiles worldwide, and the only thing it needs from you is a job description or even just a single line description of who you are looking for.

What follows is the honest version: what the engine does step by step, why plain English beats a boolean string and where boolean still wins, what reply rates to actually expect once it starts messaging, where it fails, and what it deliberately does not do. If you are evaluating it rather than admiring it, the last three sections are the ones that matter.
What RecruitGPT actually does
RecruitGPT is three jobs welded into one loop: search, screen, reach out. That is the entire product. Understanding the seams between the three is how you predict whether it will work for your roles, because each seam is where the value is created and where the failure modes live.
The search step takes your description and turns it into queries against a pool of roughly a billion public profiles. That pool is not one site. It spans professional profile data plus places where the evidence of skill is the work rather than the job title, like GitHub and Stack Overflow. The important part is what you do not do: you do not build the query, you describe the person.
The screen step is the one that earns its keep, and it is the reason the product is named after a language model rather than a search box. A query that returns 4,000 people is not a shortlist, it is a new problem. A language model reads each returned profile against your description, judges skills, experience and trajectory, and hands back the matches ranked. That is the work a sourcer does by eye over several hours, done at the same depth on every single profile instead of on the first eighty before fatigue sets in.
The outreach step then messages the shortlist and follows up without you touching it. This is the piece most teams underestimate, because a shortlist is not a hire and a hundred perfect matches who never hear from you are worth exactly nothing.
Why a description beats a boolean string
Boolean search asks you to guess the words on the profile. That is the whole trick, and it is also the whole problem. You are not searching for a person, you are searching for the vocabulary that person happened to use about themselves, on a day you were not there, in a job title their employer invented. Every string you write encodes an assumption about that vocabulary, and every wrong assumption silently deletes people you would have hired.
A language model works on meaning instead of tokens, which is why it surfaces the candidates your string was structurally incapable of returning. The clearest example is the career changer: the platform engineer whose title says "Site Reliability" and whose last two years were entirely Kubernetes, or the data scientist filed under "Analyst" because that was the band their company had. Recruiters testing semantic search consistently report the same thing, which is that the system finds people their own boolean logic would have missed because the title did not match but the experience did - Loxo.
Be honest about the other direction, though. Boolean still wins where the criterion is literal and binary, and it wins because it is auditable. If you need a specific security clearance, a named certification, a particular employer, or a hard geographic boundary, a string does that exactly and shows you why each result is there. A model infers, and inference is the wrong tool for a fact you can just look up. The right mental model in 2026 is not that natural language replaced boolean. It is that natural language is the better first pass across a billion profiles, and a filter is the better final cut on the twenty that matter.
The part that never makes the landing page: reply rates
An engine that finds and messages a thousand people is only interesting if some of them answer, so it is worth anchoring your expectations to real numbers rather than to the demo. The best public dataset on recruiting outreach comes from Pin, which analysed more than 4 million messages sent by over 1,500 recruiting organisations to roughly 1.5 million candidates between June 2025 and May 2026 - Pin.
Three findings from it should shape how you use any automated outreach, including ours. Automated cold email replied at 4.96%. Email written by a recruiter replied at 6.31%. LinkedIn messages replied at 17.08%, roughly 3.4x automated email, and that gap held in every quarter of the year measured.
Read those numbers carefully, because they cut against the lazy reading of this page. Automation does not beat a human on a per-message basis. It loses, by about a quarter, on email. What automation changes is the denominator: a recruiter cannot personally write and chase 800 people, so the comparison is never "automated message versus handcrafted message to the same person." It is "automated message versus no message at all," and no message replies at 0%. The practical conclusion is to let the engine do reach and follow-up, and to spend your saved hours on the fifteen people who answer rather than on the seven hundred who will not.
RecruitGPT is not an applicant tracking system
The engine hands off at the reply, and this is the single most common mismatch we see in evaluations. RecruitGPT finds the person, screens them, sends the first message and chases it. Then a human being answers, and the engine's job is finished. It does not run interview stages, hiring manager feedback, scorecards, offers or rejections.
If that reply lands in a personal inbox, the candidate is effectively lost: no stage, no owner, no record, no way for anyone else on your team to see that the conversation exists. Teams without an applicant tracking system feel this within about a week of switching on automated outreach, and they feel it precisely because it is working. Volume is the point, and volume without a pipeline is just a busier inbox.
Manatal
If you do not already have somewhere for those replies to land, Manatal is the cheapest credible place to put them: $15 per user per month billed annually ($19 month to month), with a 14-day trial that does not ask for a card. It gives you the pipeline, the CRM and the shared record that an autopilot sourcing engine assumes exists downstream of it. Read the cap before you commit, because it is the thing the price tag hides: that tier stops at 15 active jobs and 10,000 candidates, so an agency running more than fifteen live roles is really pricing the $35 tier, not the $15 one. And if you already run Greenhouse, Ashby or Teamtailor, ignore this entirely. A second ATS is worse than no ATS.
Where it fails
Every honest description of a sourcing engine is mostly a description of its failure modes, and there are four worth knowing before you buy anything in this category, ours included.
It optimises what you wrote, not what you meant. A vague description produces a confidently vague shortlist. "Senior backend engineer, fintech, Amsterdam" is a wish, not a specification, and the model will happily satisfy it with fifty people you do not want. The teams who get the most out of natural language search are the ones who write two or three sentences about what the person will actually do and what would disqualify them, which is more thought than a boolean string ever demanded of them.
Public data decays. A profile is a self-report, last updated whenever its owner felt like it. Someone who left that job eight months ago still shows up in that job. No engine, ours or anyone's, can search a fact that nobody published, and this is a hard ceiling on the whole category rather than an implementation detail.
A ranked list has no error bars. The model returns candidate number one and candidate number forty with the same calm confidence, and it will cheerfully infer depth of experience from a job title that was awarded for political reasons. Treat the ranking as a very good reading order, not as a verdict.
Scale amplifies whatever you point it at. An engine that can message eight hundred people can send eight hundred bad messages faster than any human could send eighty. If the description is wrong, automation does not surface the error, it multiplies it. Sample the shortlist by hand before you let the outreach run.
The compliance clock you should have in your calendar
If you hire into the EU, AI-assisted screening is regulated and the dates recently moved, so this is worth two minutes even though it is nobody's favourite section. The EU AI Act's Annex III classifies as high-risk any AI system "intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates" - Annex III. Evaluating candidates is exactly what the screen step does, so assume you are in scope rather than hoping you are not.
The deadline for those obligations was 2 August 2026. Under the Digital Omnibus agreement it moves to 2 December 2027, a provisional political agreement reached on 6 May 2026 and confirmed by member state representatives on 13 May 2026 - Gibson Dunn. Two caveats matter more than the headline. The delay is not law until it is published in the Official Journal, and the Article 50 transparency obligations were not deferred at all.
The practical takeaway is about who carries the duty. Buying the tool does not outsource the obligation: you are the deployer, and deployer duties around human oversight sit with you regardless of what your vendor's compliance page says. Keep a human making the decision, keep the reasoning behind a rejection, and never let an automated ranking be the only thing standing between a person and a no.
Who should actually use this
RecruitGPT is a strong fit if your bottleneck is the top of the funnel: you have more roles than sourcing hours, your candidates are passive, your requirements are describable in prose, and you already have somewhere for replies to land. It is at its best on volume and mid-level hiring across a wide market, where the cost of missing good people is high and the cost of a slightly imperfect shortlist is low.
It is a poor fit in the mirror image of that. If you are running one confidential C-suite search, the work is relationships and judgement, not retrieval, and no engine will help you. If your criteria are legal absolutes rather than descriptions, use a filter. If your team has no pipeline to catch the replies, fix that first, because the fastest way to waste an autopilot sourcing engine is to point it at an inbox. An entry-level applicant tracking system like Manatal works out at roughly $180 per user per year on its annual plan, which is a rounding error against a single hire you lost in an unread inbox.
The honest summary is that the last twenty years of recruitment technology made recruiters search faster. RecruitGPT is an attempt at something else: to remove the search step, so the human part of this job, the actual connecting, is what your day is made of. That was always the point. The data was only ever there to get you to the conversation.
Describe the person in one line, and let the engine search, screen and reach out.
Written by Yuma Heymans (@yumahey), who built HeroHunt.ai and RecruitGPT. He has been building AI sourcing tools since 2021, back when getting a language model to read a profile reliably was the hard part rather than the assumed part.
Reply-rate benchmarks and regulatory dates cited here were verified in July 2026. The EU AI Act timeline in particular is still moving, so check the current position before you build a policy on it.








