An AI Database Query Tool For The Questions Between Dashboards

The gap this fills

Every organisation has a dashboard layer for the recurring questions and an analyst queue for everything else. The queue is where the cost is: a question worth ten minutes of someone's time waits two days, and by the time it is answered the decision has been made without it. Ad-hoc questions are cheap to answer and expensive to schedule, which is exactly the shape of problem an assistant fits.

An answer you can check is worth more than a fast one

Every result comes with the SQL that produced it, the number of rows and how long it took. That is not transparency for its own sake — it is what makes the output usable for a decision. An unverifiable number from a black box has to be re-derived by hand before anyone will act on it, which puts you back in the queue you were trying to leave.

• The answer in words, so you know what the number means before you read it.
• The result charted — and every chart is one click from the table it was drawn from.
• The query, in full, for every answer.
• Row count, so a suspiciously round result stands out.
• Execution time, so an expensive query announces itself.
• The chance to re-run it later against current data.

It does not need a modelling layer first

Semantic layers are genuinely valuable and take months. This works against the schema you have today, because introspection reads your actual tables, keys and column values rather than a curated model of them. Where your schema has vocabulary that is not in the column names — "active" meaning `status_id = 3` — you encode that as a rule in a sentence, incrementally, on the questions where it matters.

Query load is the risk to think about

It cannot write, and it cannot run past the statement timeout, so the failure modes that worry people about tools like this are structurally unavailable. What remains is ordinary read load. Point it at a replica if you have one; use a read-only role either way.