03Applied AI · Guardrails

AI assistant for business data

A Telegram assistant for questions about sales, inventory and purchasing. Every figure it gives comes from a query it actually ran.

Numbers the model makes up
Zero
Embedded/Vector DB
Golden queries

The story

Every question about sales, inventory or purchasing used to wait for the one person who could write the SQL query. Putting an AI model in front of the data is the obvious fix, and the obvious risk: a model that invents a plausible number looks exactly like one that got it right.

So the rule came first: the model never produces a figure. Every answer comes from the company's data warehouse, where the business data is already modelled and documented. Common questions run prepared, reviewed queries. Anything new goes through NL2SQL: the model writes the SQL, which is parsed into a syntax tree and validated, then dry-run against the warehouse, so a malformed or unsafe query is rejected before it touches real data. Answers arrive in Telegram, and every number in them comes from a query that actually ran.

Try it yourself

Interactive
The AI assistant for business data demo (interactive with JavaScript on)

How it's built

The tools, the architecture and the engineering numbers, one line each.

The other four

05Multi-agent · Local-first

Personal AI operating system

Before anything it can't undo
Asks first
Git is the source of truth
Markdown

The memory is markdown in Git, so it outlives the runtime that reads it.

View full case study: Personal AI operating system

AI assistant for business data

How it's built

Role
Sole engineer
Running
In pilot testing

Built with

  • PythonThe assistant's core, with no outside dependencies
  • Model-agnostic LLM layerAny provider, picked by measured accuracy and latency
  • GroqFast, low-cost model hosting
  • Open-weight LLMsNL2SQL for questions nobody prepared
  • EmbeddingsMatch a question to the right prepared query
  • Vector searchFinds the closest query by meaning, not keywords
  • SQL AST validationEvery generated query parsed and checked before it runs
  • Dry runProves the query executes before it touches real data
  • SQL ServerThe data warehouse
  • TelegramWhere people ask

How it fits together

Two answer paths, one source of numbersA question from Telegram hits an intent router that sends it down one of two paths. The certified path runs closed SQL recipes into a deterministic metric composer. The dynamic path has a language model write SQL, which is lexically validated and dry-run before it touches the warehouse. Both paths read from the same data warehouse, and every model call goes through a single paid-provider entry point.CHANNELROUTINGPATHEXECUTIONANSWERcallsQuestionTelegram, plain languageIntent routerpath mix = health signalPaid-provider gateone entry point,test-enforcedCertified pathclosed SQL recipesDynamic pathLLM writes the SQLMetric composerassembled in codeValidate · dry-runbounded retryData warehousethe only source ofnumbersAnswerevery figure has a query
Two answer paths, one source of numbers

By the numbers

Figures the model makes up
Zero
Answer paths: prepared queries and NL2SQL
2
Way to reach the paid model, enforced by multiple tests
1
Test suite, from SQL validation to spend limits
Robust