Analytics agent
Haris Muhibić built an internal analytics app where staff ask questions about company data in plain language and get dashboards and scheduled reports. The text-to-SQL behind it is designed to hold up in production.
- Role
- Architect, near-sole author
- When
- 2026
- Stack
The problem
Every metric question went to an engineer, and dashboards went stale. The company needed self-serve answers that stay correct when filters change.
How it evolved
This started as a dbt warehouse on Redshift. Once the production database replicated into Redshift through Zero-ETL, I turned it into a product: a chat agent that queries the warehouse, builds dashboard widgets and schedules PDF, Excel or CSV reports by email.
What makes the SQL trustworthy
- Filter placeholders. Saved widgets use placeholders for customer and date filters, so they rerun correctly when someone changes the dashboard filters.
- Validate before save. Every widget’s SQL runs against the warehouse before it is saved.
- Linting. Widgets with hardcoded dates or IDs are rejected.
- Correct time ranges. “Last week” is computed in the customer’s timezone, with explicit start and end times.
- Real cancellation. The Stop button cancels the running database query, not just the chat.
- Numbers stay untouched. Replies are cleaned up in code, which never changes a number.
- Fallbacks. Models fall back across providers when one is throttled, and token cost is tracked per user.
A lesson worth sharing
In a Zero-ETL database you can’t create views, and late-binding views break across databases. Derived data has to be materialised as tables that the agent refreshes.
Building something similar? Book a 30-minute call or email haris@chern0.dev.