Skip to Content

An AI Sales Agent on a Live Channel: The Guardrails Are the Product

DTC medical devices · WhatsApp Cloud API · Claude + Odoo · In production
July 5, 2026 by
An AI Sales Agent on a Live Channel: The Guardrails Are the Product
Acurio Moncayo Hugo Alfredo

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 isn't an embarrassment. It's a liability. 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 — and the part that matters was never the intelligence. It's the control. 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 close to half of its 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 not a marketing problem. It's a response-time problem, and it was bleeding real 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 real customers, real money, and real 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 genuinely in the ERP. It cannot invent a number. The hallucination everyone's scared of isn't hoped away with a good prompt — it's closed off structurally. 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 isn't really an engineering question. It's an operations-and-liability question wearing engineering clothes. 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 close to half of our warm leads). 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 agent isn't the moat. The agent packaged inside middleware that talks to anything, holds it inside guardrails, and writes an auditable log of every move — that's the moat. 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.

Share this post
Tags
Archive