Shikho Intelligence.
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.
A WhatsApp bot living in the group leadership already checks. Ask it a question, it runs guarded read-only SQL against the warehouse, computes the numbers in code, and replies as a designed card. 18 managers, 226 real questions answered so far.
What changed: the manual daily report is dead - 20 minutes of screenshotting a day, gone.
SOURCE: His figures + decision log, July 2026
REAL UI · SYNTHETIC DATA · MORNING CARD · CONTROL CENTER · END-OF-DAY CARD
Pick a moment. This is what the system does with it - every step a deliberate call, none of it visible from the outside.
A one-prompt WhatsApp bot demos well. This one has to be right in front of leadership every morning.
- The platform itself was a research finding. The official WhatsApp API cannot post into a normal group at all - the working design (a dedicated account on an always-on box, two linked devices so the sender and the listener never fight over one socket) came out of directed deep research, not a first guess.
- Correctness was earned, decision by decision. Thirty-five numbered decisions govern this bot. Which model writes the SQL was chosen by measurement - the brand-name favourite silently broke date filters - and "Friday is not special-cased" is business judgment, not a default.
- It is grounded in data no model has seen. A 786-line company data dictionary - 194 tables, the canonical revenue definition, forty documented gotchas - is what the bot reasons from. That artifact cannot be prompted into existence.
- It was battle-tested before leadership saw it. A 56-question bilingual harness ran through the real pipeline and caught six real bugs before handoff - including a jailbreak that tried to pull personal data.
Mid-June. He asks the bot for May's numbers and it answers, confidently, with data from 2023. He pastes the screenshot: "What happened here, how did it get 2023?" The model's instinct, each time, is to patch the prompt - inject the date, add a rule sentence, add another veto.
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 is structural, all of it now in code: time windows computed by a resolver, every number computed in Python, definitions authored and read, and a second model reviewing every query before it runs - grounded in the company's 786-line data dictionary.
A leadership bot cannot be "usually right". Everything dangerous moved out of the model's hands.