The short answer
In 13 days, I (Hugo Acurio) put a production AI sales agent on a live, regulated WhatsApp channel, and it recovered ~45% of warm leads that were going cold overnight. It holds up because the model never authors a fact of record: prices, names and dates of birth are read from the ERP through tool calls, every action lands in one append-only audit trail, and a human can take over any thread instantly.
Watch the 90-second version
The board I saw
Every health, pharma, and diagnostics operator I talk to wants an AI agent on their customer channel. And nearly every one of them is quietly terrified of the same thing: that it says something it shouldn't, quotes a price that doesn't exist, invents a customer's name or date of birth, or takes an action nobody can trace back later.
On a regulated channel, that's a liability, not an embarrassment. So most of them never ship. They pilot. They "explore." The agent lives in a sandbox forever because nobody's solved the part that actually matters. The part that matters is the control, not the intelligence. The model is commodity now. Anyone can call an API. The scarce thing is the architecture you build around it.
Before the AI Agent, the sales motion ran end to end on human effort. Meta Reels drove traffic to WhatsApp, and from there a small team replied by hand, requested customer data field by field, generated payment links one at a time out of Odoo, and verified bank deposits after the fact. Every step had drop-off, and two of them were cliffs.
The system I invented
I built the system around a single principle. One middleware is the only thing that talks to everything, and it is the single point of trust. Meta points one webhook at it. It reasons with the Claude API, it reads and writes the business in Odoo over XML-RPC (products, stock, partners, orders, Nuvei payment links), and it sends the reply back out on WhatsApp. Claude and Odoo never connect to each other directly. That one choice is what makes the whole thing auditable, because every action passes through a place I control and gets recorded there.
The system runs as one process against one ledger. No message bus, no microservices, no separate front-end app. At this operation's scale, the distributed-systems reflex would have added surface area and bought nothing (and if we outgrow the shape, splitting it is a one-day refactor, which is a good problem to have later, not one to solve now).
The discipline that makes the agent reliable has little to do with the model and everything to do with the vocabulary it works inside. When the agent hands a conversation to a human, it does not write a freeform note. It picks exactly one of thirteen fixed reasons (seven customer-side, two payment-side, four system-side). If it tries to invent a reason outside that list, the tool refuses the call, defaults to a logged catch-all, and writes a warning, so the case is captured instead of lost. The same discipline runs through the seventeen fixed event types and the small set of conversation states. I moved the variability out of the agent's outputs and into the structure of the system, which gives the agent the easy job (pick from a short list) and gives everything downstream the easy job (assume the list is complete).
What I built
A DTC medical-device operation was losing warm leads to reply lag and payment friction. Someone messages at 9pm, ready to buy. By the time a human answers the next morning, they've cooled off or bought elsewhere. That's a response-time problem, not a marketing problem, and it was bleeding revenue every night.
I put a production AI sales agent on the live WhatsApp channel (Claude API, wired into Odoo). It qualifies the lead, quotes off the live ERP catalog, and creates the order on the customer's own record. Thirteen days from nothing to production. Runs 24/7. It recovered roughly the 45% that had been leaking.
That's the result. But the build isn't the story. The guardrails are.
The part engineers skip
Here's what actually makes an agent safe to put in front of customers, money, and regulation. It comes down to one principle: the model never authors a fact of record. Anything that has to be exactly right (a price, a name, an address, a date of birth) is read from and written to the system of record through a tool call, never generated as free text. The agent decides what to do. It never invents what's true.
- A price-integrity rail. The agent can only quote what's in the ERP. It cannot invent a number. The hallucination everyone's scared of is closed off structurally, not hoped away with a good prompt. There's no path for it to happen.
- An identity-integrity rail. The same lock applies to the fields that identify a customer (name, address, date of birth). The agent never types them from memory; it reads and writes them through tool calls against the system of record, so it can't transpose a digit or invent a match. For more sensitive deployments the same pattern extends to tokenized tool calls for PHI. The framework is already built for it.
- A confirmation gate on every send. Nothing fires blind.
- Auto-pause on human reply. The second a person steps into a conversation, the agent steps back. It never fights the operator.
- A stoplight operator console. A human sees every thread (red, amber, green) and can take over instantly. In the loop, not notified after the fact.
- One append-only audit trail. Every decision logged, nothing overwritten. If anyone ever asks "why did it do that," there's an answer. In a regulated channel, that's stopped being a nice-to-have. It's fast becoming the exact artifact a regulator will ask you to produce.
This is the layer most people skip, and I understand why. It's an operations-and-liability question wearing engineering clothes, not an engineering question. Knowing where a human has to sit, what has to pause, what can never be automated. That's a design discipline, and it's the whole difference between a demo that impresses your board and a system that survives contact with your customers.
I'd argue it's harder than the agent itself. The agent took days. The judgment about where to put the guardrails took fifteen years.
The result
The system covers the channel around the clock with no response lag, which closes a gap that manual replies never could (before Fenix, response lag alone was costing us warm leads every night). Every conversation is now visible in one console, every action is logged, and orders land in the ERP as they are created. That operational result is the one I stand behind cleanly: a live channel that runs itself 24/7, with a human in the loop exactly where judgment is required.
Over the same period, we also refocused the ad channel on GMATE devices and worked on the quality of the leads coming in. Across that window the commercial numbers moved materially: return on ad spend went from 1.8X to 7X, and conversion rate from 2.5% to 8.75%. I want to be precise about attribution: those gains came from the agent and the channel changes together, and there is no honest way to split the credit between them.
What this proves
The portable lesson is the one that surprises people. The AI is the easy part. The model already works. The hard part is the scaffolding around it: the closed vocabulary the agent operates inside, the operator surface built around how people actually work, the audit trail that makes every action accountable, and the kill switches that let you stop it cleanly. Build those carefully and the agent becomes safe to trust in production. Skip them and you are one bad message away from a brand incident.
The moat is the agent packaged inside middleware that talks to anything, holds it inside guardrails, and writes an auditable log of every move. The model is the part anyone can rent. The scaffolding is the part I build. It is the same discipline whether the operator you are supervising is a person or a language model.
Hiring for AI leadership? See what to look for in a Fractional Chief AI Officer.
More on how I keep AI auditable in regulated work: AI regulatory compliance for healthcare and pharma operations.