The board I saw
The operational shape of the funnel was doing the damage. Customers were ready to buy; the funnel kept dropping them on the way.
Before Fenix, 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.
Three patterns showed up the moment we instrumented the flow. Payment friction was the primary conversion killer (the transfer-first model asked customers to bank-transfer and then wait for manual verification, and warm leads cooled within the hour). Operator response time turned out to be a function of cognitive load, not headcount (adding people did not help linearly, because the bottleneck was the number of context switches per conversation, not the message volume). And in the dashboard, a low-intent price-scanner and a high-intent buyer who gave up at a clumsy intake step looked identical, so the team was guessing at the fix.
That is exactly the kind of problem an AI agent solves, on one condition: the operator surface around it has to be built with the same care as the agent itself.
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
The agent reads an inbound WhatsApp message, qualifies it, quotes from the live ERP catalog, creates a sales order on the customer's Odoo record, and confirms it back, natively in Spanish, without a human on the common path. The production channel runs GMATE glucometers (the agent is product-agnostic and handles other lines including cosmetics, but the live focus is medical devices). It was built in thirteen days, and it is running in production now.
What makes it safe to trust on a live customer channel is a small set of guardrails, each one load-bearing:
- A closed-set handoff vocabulary. Thirteen fixed reasons, refuse-to-improvise. The agent picks one; unknown reasons fail safe to a logged catch-all.
- A stoplight console that shows the decision, not the diagnostics. Red for a human-judgment rescue, orange for a payment task in flight, green for the bot working, gray for done. Operators sort by what to do next, not by which technical state the system happens to be in.
- Auto-pause on human reply. The moment an operator types into a conversation, the bot goes silent and stays silent until the operator explicitly resumes it, so it can never talk over a human mid-rescue.
- A confirmation step on every outbound human message and payment link. No accidental sends in the company's voice.
- A price-integrity rail. Every quote is cross-checked against Odoo's authoritative price before it goes out, and a mismatch refuses and routes to a human. This is the rail that prevents the worst outcome of an AI sales agent: confidently quoting a wrong price the business is then expected to honor.
Under all of it sits one append-only event log, written by the agent and the operators in the same vocabulary. That single file is the audit trail, and it is also where the conversion math comes from, so the numbers and the accountability share one source and neither can drift from the other.
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.
That scaffolding is the part I build, and it is the same discipline whether the operator you are supervising is a person or a language model.