An experiment from Halo Powered Labs

Halo BI Assistant icon

Halo BI Assistant
Questions in. Insights out.

A desktop app that answers business questions over your own warehouse — by planning the analysis, writing the SQL, running it, and explaining what came back. Every number traces to a query you can read.

Databricks SQL PostgreSQL macOS & Windows Runs on your machine
The Halo BI Assistant window: a question about which teams got the most out of their chances, the assistant's answer with a ranked table, and the chart it built from that answer in the right-hand panel.
One window: the conversation on the left, the visual it produced on the right. Shown against the World Cup demo database that ships with the app.

BI tools make you build the question. This one answers it — and shows its work.

You ask in plain language. The assistant maps the question onto the real entities and columns in your data, runs read-only SQL until it has the answer, and replies with the numbers, the comparison, and a short takeaway — citing the tables it used. When the data doesn't cover what you asked, it says so instead of filling the gap.

Grounded

Every factual claim comes from SQL executed in the conversation — never from what the model already believes.

Tailorable

Visuals are conversation participants. Ask for a change; the chart updates, versioned, revertible.

Local

One installer. The app, its API and its database all run on your machine — no service to stand up.

How it works

From a question to an answer you can defend.

One loop per question. Each step is visible in the app, so a reviewer can follow the reasoning from the sentence you typed down to the rows that produced the number.

Step 01

Point it at your data — and only the part that matters.

Connect a Databricks SQL warehouse or a PostgreSQL database and browse the catalog as it really is: schemas, tables, column types, sample values. Tick the entities that belong in a dataset, and a session works over those — nothing wider.

You can define a metric here too. Write finishing quality once as a SQL expression and every answer that needs it reuses that expression instead of re-deriving the number and drifting.

The dataset editor: a catalog tree of World Cup tables on the left, and the selected table's eleven columns with their SQL types on the right.
The catalog as the assistant sees it — every column, every type, nothing inferred.
Step 02

Ask in business language. It asks back when the question is ambiguous.

"Which teams got the most out of their chances?" has three defensible answers in this data, and they do not rank the same. So the assistant does what a good analyst does: it puts the options in front of you — each one described in terms of the columns it would actually use — and waits.

This is the difference between a tool that produces a number and a tool you can quote. It will not pick a definition of "best" on your behalf.

The assistant asking how finishing quality should be measured, offering three options drawn from the data, and then the answer once one is chosen.
One short question, three concrete options, each tied to real columns.
Step 03

It writes the SQL, runs it, and shows you both.

Read-only queries, chained as far as the analysis needs. The first one here checks what the dataset actually covers before anything gets ranked; the second computes the answer. Each carries the reason it was run, the statement itself, the row count and the rows.

Nothing in the answer comes from what the model already believed. If you want to check a number, the query that produced it is two clicks away — and it is the query that ran, not a reconstruction.

The expanded data provenance panel showing two executed SQL statements, their stated rationale and their row counts.
Every answer opens up into the SQL behind it, with the reasoning that led to each query.
Step 04

The chart is part of the conversation, not the end of it.

Ask for a visual and it is built from that answer's own rows. Then keep talking: drop the one- and two-match teams, they're noise. The chart changes, and the old one is still there — every version kept, every version labelled with the instruction that produced it, any of them one click from being restored.

Export it and you get a self-contained page: the question, the chart, the written analysis, the SQL and the data. The kind of thing you can send to someone who was not in the room.

The visual panel's version history open, listing version 2 as current and version 1 with the instruction that created it.
Tailoring is versioned: every instruction is a version you can go back to.

What's inside

The parts that make the answers trustworthy.

Most of the app is not the chat box. It's the machinery that keeps an answer honest when the schema is messy and the business vocabulary is not in the column names.

Your rules

Teach it your vocabulary once. It applies it every time.

Your business words are not in your column names. Write down what finishing quality means, which filter should apply unless someone says otherwise, and the standing instruction that a ranking must always state its sample size — and the assistant follows them, ahead of whatever it would have guessed from a column name.

When a rule shapes an answer, the answer says which one. Turn a snippet off and the next answer changes accordingly.

The Knowledge screen listing curated instructions, glossary terms and default filters, each individually enabled.
Glossary terms, standing instructions and default filters — authored once, enforced per answer.
Under the hood

Not one prompt. A crew, each with one job.

The assistant plans and runs the analysis. A separate verifier re-derives the SQL independently to corroborate the answer. A fixer repairs a statement the engine rejected. A designer turns a finished answer into a visual and tailors it. A judge grades eval runs so a prompt change that quietly breaks an answer shows up as a regression rather than a surprise.

You never have to think about any of this. It is here because it is why the answers hold up.

The Agents screen listing the six registered agents — assistant, SQL verifier, SQL fixer, visual designer, knowledge bootstrap and eval judge — with a one-line description each.
Six specialised agents, each doing one thing the others are not trusted to do.

Deep analysis

For the bigger questions: the assistant plans several angles of attack, investigates each one, and synthesises the findings into a written report saved to the session.

Verified queries

Promote SQL you trust into a reusable, known-good answer, so the next person asking the same question gets the same numbers.

Evaluations

Run a question set against the agent, grade the results, and compare runs over time — so a prompt change that quietly breaks an answer shows up as a regression.

Sessions with memory

Each session keeps its own transcript, memory thread and workspace, so follow-up questions build on the analysis instead of restarting it.

Bring your own model

Point it at OpenAI or at LenAI, Halo's internal OpenAI-compatible gateway. The key is stored encrypted on your machine and tested from the settings screen.

Single-app delivery

The installer ships the interface and its API together. Launch the app and everything it needs starts with it — no runtime to install, no server to operate.

Get the app

Download Halo BI Assistant.

Installers are built per platform. Pick the one that matches your machine — on a Mac, Apple silicon is arm64 and Intel is x64.

macOS · Apple silicon

.dmg — M1 and newer

Download
macOS · Intel

.dmg — x64 Macs

Download
Windows

.exe installer — x64

Download

On first launch, open Settings and add your model provider key and a data connection. macOS builds are not notarised yet — if Gatekeeper blocks the app, open it once via right-click → Open.

Where your data goes

It runs where you run it.

The assistant is a desktop app, not a hosted service. Your warehouse credentials, your sessions and your answers stay on the machine that installed it.

Data sources

Databricks SQL warehouses and PostgreSQL databases, queried read-only.

Storage

Sessions, datasets, knowledge and settings live in a local database in the app's own user-data directory.

Leaves the machine

Queries go to the warehouse you connected; prompts go to the model provider you configured. Nothing else.

Credentials

Model provider keys are stored encrypted locally and never rendered back into the interface.

Platforms

macOS (Apple silicon and Intel) and Windows x64.

Status

An active Labs experiment — shipping often, and built alongside the teams using it.

Have a question your dashboard can't answer?

That's the one we want. Bring it to the bench and we'll come back with a working answer — and the evidence behind it.

Talk to the Labs