Product update

Nothing sends, spends or arms without your click

The failure mode of an autonomous recruiter is not a bad shortlist. It is four hundred emails from your domain to people you would never have contacted.

All posts
EL
The EmployLabs team
· 2 min read
In short

Three actions on EmployLabs refuse an AI caller in code rather than by prompt instruction: arming automation on a role, approving an outreach send, and releasing spend. Roles begin fully manual and cannot be armed without an explicit automation level. The AI prepares the full configuration and presents it; the click belongs to a person, and the change log records executor and authorising human separately.

The question every buyer asks second

The first question is what it can do. The second, always, is what it can do without being asked. It is the right question, because the failure mode of an autonomous recruiting system is not a bad shortlist. It is four hundred emails sent from your domain, under your name, to people you would never have contacted.

Three refusals, in code

  • Arming automation. Every role starts fully manual. Autonomous work runs only on roles a person has explicitly switched on, at a level they chose, and a role that has not chosen a level cannot be armed at all.
  • Approving a send. The gate that releases outreach refuses an AI caller outright.
  • Releasing spend. Same refusal. Meera can propose an entire configuration, budget included, and cannot approve it.

These are not prompt instructions. A prompt rule is a request, and it holds until a model decides otherwise or somebody rephrases the question. These refusals are conditions in the code, so the agent asking is rejected the same way a stranger would be.

A prompt rule is a request. The refusal has to be a condition.

What the AI does instead

It does the work up to the decision and then presents it. The full automation configuration with reasons, the spend ceiling it thinks the role needs, the candidates it would contact. Everything except the click.

That division is deliberate. The parts requiring judgement about consequences stay with the person who carries them, and the parts requiring only diligence do not wait for that person to be at their desk.

You can also see what was done

Every meaningful change is on the record with two separate facts: who executed it, and which human’s authority it ran under. An agent acting for you is recorded as the agent, not as you. Those are different claims and collapsing them would make the log worthless in the one situation where anybody reads it.

How to use it

  1. Start a role in manual and watch one full cycle before arming anything. The gates are cheap; an unwanted send is not.
  2. Choose the automation level deliberately rather than accepting a default. “On” means something different to everyone who reads it, which is why we refuse to infer it.
  3. Check the change log when something surprises you. It answers who and under whose authority, which is usually the actual question.

Common questions

What can an AI recruiting platform do without human approval?
On EmployLabs, everything up to a decision with consequences. Arming automation, approving a send and releasing spend all refuse an AI caller in code, so the agent can prepare a full configuration but cannot enact it.
Why is a code-level refusal better than a prompt instruction?
A prompt rule is a request that holds until a model decides otherwise or someone rephrases the question. A condition in code rejects the agent the same way it would reject any unauthorised caller.
Does the audit log distinguish between a person and an agent acting for them?
Yes. Who executed a change and whose authority it ran under are recorded as separate facts. Collapsing them would make the log useless in the one situation where anyone reads it.

Related reading

All posts →

See it on one of your own roles

Upload a job description and watch the pipeline run before you commit to anything.

Start for free