An always-on WhatsApp bot that answers leadership's data questions through guarded text-to-SQL. Numbers are computed in code - the model only narrates.
INTERNAL SYSTEM · REAL INTERFACE, PROTECTED DATA · WALKTHROUGH AVAILABLE ON REQUEST
The company's numbers lived in dashboards nobody opened. Management lives in WhatsApp. A person spent 20 minutes every day screenshotting reports into the group.
It answers as a designed card, right in the group leadership already checks.
20 minutes of daily screenshotting, gone.
SOURCE: His figures + decision log, July 2026



REAL UI · SYNTHETIC DATA · MORNING CARD · CONTROL CENTER · END-OF-DAY CARD
Pick a moment. Watch the calls the system makes that no one sees.
EVERY STEP MINED FROM THE REAL BUILD · NOTHING INVENTED
A one-prompt WhatsApp bot demos well. This one has to be right in front of leadership every morning.
Mid-June. He asks for May's numbers; the bot answers confidently with 2023 data. He pastes the screenshot: "What happened here, how did it get 2023?" The model's instinct: patch the prompt.
Most of the time it's right. But I found cases where it confidently gives a wrong number and nothing catches it. [...] Every fix this session was "add another sentence to the prompt / another veto regex." That approach has a ceiling, and I hit it - I found 7 fresh failures in under an hour of the *current* code. The architecture, not the prompt, is the limiter.
Based on the data dictionary file we have - would it make sense to go through that and maybe basically update the current system we have for this bot to better understand questions and find out how to run this?
The fix that shipped was structural, not another prompt patch. The date window, every number, the definitions and a second-model review all moved into code.
A leadership bot cannot be "usually right". Everything dangerous moved out of the model's hands.