What agentic BI actually means - and what it takes to trust it
Sushrut Ikhar, Co-founder, Matih Labs —
What agentic BI actually means - and what it takes to trust it
TL;DR — "Agentic BI" is being used to describe everything from a chatbot that writes one SQL query to a fully autonomous analyst. The difference that matters is the input: a question gets you an answer, a goal gets you a plan - several queries, intermediate checks, and a conclusion you didn't have to assemble yourself. That extra power is only worth having with three disciplines attached: an autonomy dial that defaults to asking permission, an audit trail from every claim back to the SQL and rows behind it, and honest failure when a run hits its limits. Here's how we drew those lines in Matih's agent mode, and why we'd argue any agent you point at your warehouse should have to answer the same questions.
Dashboards answer the questions someone predicted last quarter. Chat-style BI answers the question you actually have today - one question, one query, one answer. Both stop short of the work that fills an analyst's afternoon: the question behind the question. "Why did signups drop last week?" is not one query. It's a segmentation, a comparison against the previous period, a check on the marketing calendar, a look at whether one channel or all of them moved - and then a judgment call about what's signal.
That multi-step investigation is the honest definition of agentic BI: you hand over a goal, and the system plans and executes the steps. Not a bigger prompt box. A different contract.
A question gets an answer. A goal gets a plan.
In Matih, this contract is explicit: every conversation runs in a mode you pick up front - Chat for single questions, Agent for goals. Give agent mode "investigate why signups dropped last week" and it doesn't return a paragraph of speculation; it works through visible steps - profiling the signups table, splitting the drop by channel and region, comparing against the prior three weeks, checking whether the drop coincides with a data freshness gap - and shows you each step as it runs, with a live status and elapsed timer.
Two properties of that loop matter more than the plan itself:
You can stop it. A running investigation has a stop button that actually cancels work, including queries still executing on the engine - and tells you what was cancelled while keeping what was already gathered.
It ends honestly. Long runs carry a time budget. When a turn hits it, Matih says so - "this turn reached its time budget before finishing" - and hands over the partial result, instead of stretching thin evidence into a confident-sounding conclusion. An agent that never admits "I ran out of room" is an agent whose complete answers you also can't calibrate.
Autonomy is a dial, not a switch
The industry conversation treats autonomy as binary: either a human writes every query, or the agent is off the leash. Nobody runs their team that way, and nobody should run their data agent that way either.
Agent mode carries an autonomy setting per conversation:
- Confirm writes - the default. The agent investigates freely but pauses for explicit approval before any step that changes data.
- Review SQL - every generated query stops for your review, and you can edit it before it runs.
- Auto - steps run without check-ins, but only ever inside the access you already have. The agent holds your permissions, not superpowers.
And independent of the dial, the agent pauses itself before an unusually large or expensive step - a scan over a very large row count stops with a "run paused" banner explaining why, and nothing executes until you approve or reject it. Guardrails you can't forget to set are the ones that work; per-plan daily token budgets and workspace spend caps sit underneath for the same reason.
An agent's conclusion needs an audit trail
The more steps a system takes on your behalf, the less realistic it is that you'll re-derive its work - which is exactly why every claim needs a path back to evidence. This is the same argument we made about schema-blind text-to-SQL, compounded: an unverifiable answer is a liability, and an unverifiable investigation is a liability with confidence intervals you can't see.
So agent answers in Matih carry their receipts inline. Statements reference citation markers - hover one and you get the question it answers, the exact SQL, and a preview of the returned rows. Answers built on governed definitions or documentation carry source markers that link to the source. And every answer wears a trust badge: Verified when it's served from a human-approved canonical query, Governed when computed from governed metric definitions, Ad-hoc when the SQL is freshly generated and no human has signed off yet. If a quality check couldn't run during a turn, a reduced-confidence chip says so rather than letting the answer pass as fully checked.
The badge system also gives investigations a flywheel: when the agent produces a good answer, you can propose it as a verified query - and once approved, matching questions get served from the canonical version instead of regenerated from scratch.
The steady state: questions you stop asking
The quiet payoff of agentic BI isn't the dramatic one-off investigation. It's the investigation you never run manually again. Routines take a prompt - "summarize last week's bookings by channel and call out anything unusual" - and run it on a schedule, or when the underlying data refreshes, delivering the written answer to your feed, email, Slack, or Teams. A new routine doesn't go live blind: you test-run it first, see exactly what it produces, and only then enable the schedule.
That's the shape we think this category settles into. Not "chat with your data" - that was the demo. The product is a system that takes goals, shows its work, asks before it does anything expensive or destructive, and gradually turns your recurring questions into monitored, delivered answers.
FAQ
Isn't agentic BI just a chatbot with extra steps?
The extra steps are the point. A chatbot maps one question to one query; an agent decomposes a goal into a plan - multiple queries, checks, and a synthesis. The practical difference shows up in trust requirements: a single query is cheap to eyeball, a twelve-step investigation isn't, which is why grounding and autonomy controls stop being nice-to-haves.
What stops an agent from running a huge, expensive query?
Layers. The agent pauses on its own before unusually large or expensive steps and waits for approval. Underneath that sit per-plan daily token budgets, workspace spend caps that can warn or hard-block, and a stop button that cancels in-flight queries on the engine.
Can the agent change or delete my data?
Not silently. The default autonomy setting pauses for explicit approval before any step that changes data, and even on full auto the agent only operates within the access your account already has. If you want tighter control, review-SQL mode stops every query for inspection before it runs.
How do I know an agent's answer is right?
You don't take it on faith - you check the trail. Citations link each claim to the SQL and rows behind it, trust badges distinguish human-verified answers from governed and ad-hoc ones, and a reduced-confidence flag appears when any quality check was skipped. Verification is a property of the system, not a vibe.