Your dashboards report what happened. The reason usually sits in text no chart reads: a resolution note, a ticket comment, a Teams thread from three weeks ago. We wire Glean across both, so anyone can ask in plain language and get an answer with its sources attached.
A senior leader opens the dashboard on a Saturday and the metric is well under target. The dashboard is correct, current, and cannot say why. So the question goes to the analytics team, and the answer arrives Monday morning, after someone spends a weekend rebuilding it by hand.
| When | What happens | Hours |
|---|---|---|
| Sat 08:19 | Request lands. "Find out why, need it Monday." | n/a |
| Sun 09:20 | Write the query. Three joins, two passes at the right grain. | 2.5 |
| Sun 11:05 | Export 84,000 rows to a spreadsheet. | 0.5 |
| Sun 13:30 | Read resolution notes by hand and tag them. | 4.0 |
| Sun 17:45 | Pivot, chart, find the grain was wrong, redo it. | 3.5 |
| Sun 21:10 | Build the deck. | 3.5 |
| Mon 08:00 | The answer is presented, and it is a good answer. | 14.0 |
Prose is not groupable, so it gets dropped at modelling time. That is not a gap you close with a better chart. It is why every question that starts with "why" ends up routed to a person who has to sit down and read.
Countable, chartable, and able to tell you with total precision that you missed by a third, and nothing else.
The root cause, the constraint and the account at risk are usually in one of these fields already, on one row of eighty thousand.
Half the explanation is usually a thread or an email. No warehouse query reaches it, and no BI assistant can.
That combination is the whole thing. A BI assistant reaches the first. An enterprise search tool reaches the second. Answering why almost always needs both at once.
A query action generates read-only SQL or DAX when the question is asked, scoped to an explicit table allowlist and run as the person asking. Nothing is copied, synced or re-indexed. Your warehouse answers an ordinary read-only query.
Glean's standard connectors already index the places the rest of the explanation lives, with each person's existing permissions mirrored. This is how "did anyone already know about this" gets answered. No build from us, and no change from you.
Some of this is engineering and some of it is the unglamorous groundwork that decides whether the engineering is worth anything.
Glean ships query actions for Databricks, Snowflake and BigQuery. We built the ones it does not: Power BI DAX, SQL Server and Azure SQL. Each generates read-only SQL or DAX at question time, guarded so writes are structurally impossible, restricted to an explicit table allowlist, and executed as the person asking.
A query action that returns plausible SQL is worse than none. We supply the column manifest, aggregation rules and instructions that keep the generated query correct, then a test suite that scores answers against known-good results so quality is measured rather than assumed. This is most of the work, and it applies whether we built the action or Glean did.
The agent belongs beside the number, not in another tab. We embed Glean into the surfaces people already use: a live Power BI report with an ask panel next to it, or an agent inside your own application through the web SDK.
Most failed answers trace back to the data, not the model. We do the unglamorous part: the views, the column documentation, the grain decisions and the access model an agent needs before anyone should trust it.
Infrastructure as code, staged rollout with a way back, least-privilege authentication and secrets in a vault. Your team leaves owning the allowlists, the instructions and the evals. Nothing depends on us being in the room.
We will rebuild that one on your data as a proof of value, side by side with the deck your team produced by hand. If the result does not clear the bar, you will hear it from us first.