Run the desk, not the noise.

Five recruiters, two months

We didn't start with a product. We started with conversations. Five agency recruiters, in depth, over the first two months. Phone calls, video calls, coffees in London. Not sales calls — listening sessions. We asked one question over and over: where does your time actually go?

We didn't shadow them or watch them work. We didn't need to. Every recruiter we sat with described the exact same day. Not similar — identical. Unprompted, in different agencies, different verticals, different cities, they walked us through the same workflow in the same order with the same frustrations.

That's when we knew the process was standardised. The tools just hadn't caught up.

The same loop, every desk

Every recruiter described the same cycle. A requisition lands — a new role from a client. Sometimes it's a clean brief, sometimes it's a phone call with half the details missing. Either way, the clock starts.

They take the brief and try to understand it. What does the client actually need? What's the salary? What's negotiable? Half the time they're guessing because the hiring manager gave them three bullet points and a deadline.

Then they publish. The role goes out across job boards — LinkedIn, Indeed, Reed, totaljobs — each one with its own login, its own format, its own posting flow. Copy-paste, adjust, publish, repeat.

Then the applications arrive. And this is where the day disappears.

291 applications. One pair of eyes.

Screening is the bottleneck nobody talks about because everybody accepts it. CVs come in. The recruiter reads them, one by one. Some are obvious no's. Some are obvious yes's. Most sit in the middle and require judgment — is this person's 3 years at Deloitte really equivalent to what the client means by "Big Four experience"?

Every recruiter we spoke to described this as the most draining part of the job. Not the hardest — the most draining. It's repetitive, high-stakes, and happens before the recruiter has done anything that feels like actual recruiting.

The heart of the machine

And then they log it. Every CV reviewed, every phone screen completed, every stage change, every note — it all goes into the ATS. Applicant Tracking System.

The ATS kept appearing in every conversation. It was the one thing every recruiter mentioned without us asking. Bullhorn. Vincere. JobAdder. Recruit CRM. Different names, same role: the central nervous system of the agency.

We'd seen CRMs before in other industries — the concept wasn't foreign. But the ATS was different. It wasn't just a contact database. It was the system of record for every candidate, every role, every placement, every fee. The billing runs through it. The compliance lives in it. The pipeline is defined by it.

It became obvious: if we wanted to agentify recruitment, we needed to be inside the ATS. Not sitting next to it. Not reading exports from it. Inside it. Reading and writing, in real time.

That was the first real architectural decision. Everything else followed from it.

The five functions

After two months of listening, we pinned the workflow to the wall. Every recruiter's day — regardless of vertical, desk size, or ATS — breaks into five functions:

Five functions. Every desk. Every agency. Every day.

The question was no longer "what do we build?" It was "which of these five can an agent run?"

The answer, it turned out, was all of them.

The meta-agent wasn't wasted

The consulting work we'd been doing for months — building agent orchestrators for other companies — turned out to be the foundation. We'd already solved the hard problem: how does one system receive a message, decide what kind of task it is, and route it to the right specialist?

That's exactly what a recruiter's desk needs.

But there was a harder problem underneath it. One we kept running into on every agentic build we'd shipped.

Horizontal intelligence. Vertical ignorance.

A general-purpose AI agent is horizontally capable. It can read, write, reason, summarise, extract, and draft. It can do all of these things reasonably well across almost any domain.

What it cannot do is predict the consequences of its actions.

Agents don't have a world model. They don't know that sending a candidate a follow-up message three hours after they just declined is a reputation risk. They don't know that moving a candidate to "offer stage" in Bullhorn before the client has verbally approved triggers a billing clock. They don't know that a contractor whose assignment ends on a Friday needs to be redeployed by the Wednesday before — not the Monday after.

These aren't intelligence failures. They're domain failures. The agent has no map of how the recruitment world actually works — the unwritten rules, the timing sensitivities, the sequence dependencies, the commercial consequences.

Left unsupervised, a horizontal agent in a vertical workflow doesn't just make mistakes. It makes expensive mistakes. Candidates ghosted at the wrong moment. Clients billed incorrectly. Compliance records left incomplete.

To automate with minimal supervision, the agent needs to know the domain before it acts.

Why Act I wasn't just market research

The five conversations in Act I weren't just validation. They were the domain model.

Every recruiter told us the rules without knowing they were telling us the rules. The sequence of a requisition. How long you wait before chasing a hiring manager — long enough not to annoy them, short enough not to lose the deal. When a candidate going silent means disinterest versus anxiety about the process. What "available immediately" actually means on a CV versus in a phone screen. How a placement fee is calculated and when it crystallises.

None of this is in any API documentation. None of it is in the ATS schema. It lives in the heads of people who've placed hundreds of candidates across thousands of desks over years of agency work.

We extracted it from those five conversations. Then we encoded it.

One message in, five agents listening — each with its own rules

We built a central router. Every input hits the router first — a WhatsApp message, an ATS event, a calendar signal, a contract end date. The router reads the context and decides: is this Intake? Screening? Pipeline? Outreach? Compliance?

Then it hands off to the right agent.

But each agent isn't just a general model with a job title. Each one carries the domain knowledge of its function — the rules, the timing logic, the commercial awareness, the edge cases.

The intake agent knows that a brief with no salary band is incomplete and needs a follow-up question before the role can be opened — not after. The screening agent knows that "8 years experience" on a CV for a role that asks for 5 is a signal, not a filter. The pipeline agent knows that 4 days of hiring manager silence at offer stage is a different risk than 4 days of silence at first interview stage. The outreach agent knows that a candidate who last responded on WhatsApp gets a WhatsApp message — not an email. The compliance agent knows which ATS fields are legally required and which ones create GDPR exposure if filled incorrectly.

These aren't prompts. They're policies. Domain knowledge injected as determinism into an otherwise probabilistic system.

Cheap for extraction, smart for reasoning

Not every task needs the same brain. Pulling a candidate's name, email, and notice period from a message is pattern-matching. Deciding whether that candidate is a good fit for a role that needs "Big Four experience but startup mentality" is judgment.

So we split the models. A fast, cheap model handles extraction — parsing entities, reading ATS fields, categorising messages. A reasoning model handles the hard calls — scoring fit, drafting outreach, explaining risk.

Two tiers keeps the cost sustainable. An agency desk processes hundreds of messages a day. Running everything through a reasoning model burns through the margin we're trying to save the recruiter.

Why not a web app

Every recruiter we spoke to in Act I had the same tell. When we asked "where do you actually talk to candidates?" the answer was never "in the ATS." It was WhatsApp. Or a personal phone call. Or a text.

The ATS is the system of record. WhatsApp is the system of action.

So we built Hamrr on WhatsApp. Not as a chatbot that messages candidates — as the surface the recruiter operates from. The recruiter types /pipeline and sees their desk. They type /risk Amelia Jackson and get a no-show score back in seconds. No browser tab. No login. No dashboard to learn. The tool lives where the recruiter already lives.

YES, EDIT, or NO

The most important design decision wasn't technical. It was philosophical.

Agents cannot predict the consequences of their actions. We knew this from the problem in Scene 02. So the answer isn't to make a more capable agent. The answer is to keep a human at the decision boundary — informed by the agent's analysis, but never bypassed by it.

Every action Hamrr wants to take passes through a gate. The recruiter sees the proposed action and taps YES, EDIT, or NO. One tap.

The domain knowledge tells the agent what to do and when. The gate ensures the recruiter decides whether it happens. This is what minimal supervision actually means — not no supervision. Minimal. The recruiter spends two seconds on decisions that used to take two minutes, and never loses control of the outcome.

Five functions, one thread

The desk came alive the day all five agents ran in a single WhatsApp thread for the first time. A brief came in, the intake agent structured it, the screening agent scored three candidates against it, the outreach agent drafted messages, the pipeline agent tracked the stage changes, and the compliance agent logged everything to the ATS.

The recruiter approved six actions in four minutes. From their phone. On the tube.

The domain knowledge held. No billing clock triggered early. No candidate messaged at the wrong moment. No GDPR field filled incorrectly. The agent knew the rules. The recruiter kept control.

That was the moment it stopped being an experiment and became a product.

Coming soon

This act is being written.

Coming soon

This act is being written.