The agent inside ALLinOne, an AI recruitment platform. She answers
questions, places real phone calls, searches the data and writes back
into the platform. She has some forty tools for that, each one bounded
by rules that limit what she is allowed to change.
She is called Adèle because I named her. Adel, Adèle. Nobody caught it,
and the name stuck. She has since been covered on M6, Brut and Le
Parisien.
An agent that only answers questions is of limited use. It becomes
valuable once it acts on the data, and that is also where the risk
starts.
A recruiter repeats the same handful of actions all day: find a job
posting, filter applications, call someone, move an interview, follow
up. Each one takes a minute or two. Put end to end, they fill most of
the working day.
Automating reads is straightforward. Automating writes, meaning
creating, editing and sending, takes far more care. A model that gets a
read wrong gives a wrong answer and you correct it. A model that gets a
write wrong damages a customer's data.
All of this also had to work over the phone, with real
candidates, in real time.
02
What I built
A tool-using agent loop
Adèle runs on an orchestrator that chains tool calls across several
turns, streaming, until it produces an answer. Every tool is declared
with its schema, its nature (read or write) and its scope. Some forty
tools cover job postings, applications, calls, statistics and
scheduling.
The two-step write cycle
This is the most important part of the system. A write tool never
executes directly. It first returns what it would do: the old
value, the new one, the record concerned. The user sees the exact effect
and confirms. Execution then goes out with a signed action token
that encodes the approved operation.
The model can only execute what was shown on screen. The token, verified
at execution time, is what provides that guarantee.
Real-time voice calls
Adèle places and receives real calls. The telephony audio stream is
bridged to a real-time voice model, in both directions, for the whole
length of the call. She qualifies the candidate, offers time slots and
confirms an appointment. She also handles the case where the person on
the line cuts in.
Tenant isolation
The platform hosts several customers on the same infrastructure. Every
tool filters by organisation at the query level, not at display
time. Personal data is masked before it goes to the model and restored
on the way back: the LLM provider never receives a phone number or a
candidate name in clear text.
03
What was hard
Memory between tool turns
“This week's calls”, then “call the first one back”. If the context
keeps only the identifiers of the previous results and not the data
attached to them, the agent no longer knows who “the first one” is. It
asks again, or it points at the wrong person.
The fix goes through the tools. I standardised the return shape of
every tool: one envelope, one identity key, one label. That
normalisation repairs memory between turns, personal-data masking and
summary quality in a single pass.
Being interrupted on the phone
When a candidate cuts in, stopping audio playback is not enough. The
model believes it delivered its whole sentence and carries on as though
it had been heard out. You have to truncate its history and tell it
where playback actually stopped. The calculation runs on the
audio that was heard, not the audio that was sent, because telephony
buffers the sound.
Without that correction, the drift compounds with every interruption and
the agent ends up answering the previous question.
A system prompt that keeps growing
A system prompt that swells almost always points to badly designed
tools: you write in natural language what should have been a schema
constraint. Fixing the tools lets you shorten the prompt, which improves
reliability, latency and cost at the same time.
What only shows up in production
Telephony providers replay their webhooks. That is documented and it is
normal. Two callers can also confirm the same slot two hundred
milliseconds apart. These situations do not come up in a demo, they come
up once the service is open to users. The treatment is standard: make
every operation idempotent, and put a lock where two writes can cross.
What I take from it
The quality of an agent comes down to the design of its tools and to
the guardrails around its writes. A customer accepts letting an AI
modify their data when they see the preview before execution, when
they confirm it themselves, and when they know how to roll it back.
04
The stack
Back endNestJS and TypeScript, modular architecture, asynchronous processing queues
DataMongoDB, isolation by organisation applied at the query level
Front endReact and TypeScript, reactive state, replies displayed as they are generated
AgentMulti-tool loop, declarative schemas, preview then confirmation, signed action tokens, replay protection
VoiceTelephony audio stream bridged to a real-time voice model, interruption handling
PrivacyPersonal data masked before it reaches the model, per-user quotas
Real timeWebSocket for updates, server streaming for the agent's replies
An agent for your business?
Describe the task your team repeats twenty times a day, and I'll tell
you how much of it an agent can take on.
