Ask your data in Rig

Ask a question

1. Click Chat in the Build group of the left rail, or go straight to /chat.
2. The left panel of the page is your session list — one entry per chat thread. The two controls at the top of it are New chat and a show/hide toggle, which reads Show chat history when the panel is collapsed. ⌘⇧K also starts a new chat.
3. Type your question into the composer at the bottom and press Enter. The placeholder reads Ask a question (Enter to send)…

Ask it the way you would ask an analyst who knows your business but not your head. Full sentences are fine. You do not need table names, column names or any SQL.

Read the answer and its SQL

While Rig works it shows its steps in the transcript — checking business context, looking at tables, writing SQL. You do not have to read any of it, but it is there when a number looks odd, and it is usually where the surprise is explained.

The answer itself arrives as a result card: a short written explanation plus the rows themselves, and often a chart when the shape of the data suits one. On that card, look for the View SQL Query control and open it. That SQL is exactly what ran against your warehouse — the same query, not a paraphrase — so it tells you which tables were read and how the filter and the time window were written.

Allow actions

An action is any step that changes something rather than just reading: creating a workflow, writing a metric, triggering a sync. In the bottom row of the composer there is an Allow actions switch, and it is off by default, which keeps the session read-only.

This switch is the gate. There is no per-action approve or decline card to wait for — with the switch off, Rig answers questions and builds nothing; with it on, Rig can act when you ask it to. So turn it on only when you actually want Rig to build or change something, and turn it back off afterwards. If you asked for something to be built and nothing was built, this switch is the first thing to check.

Fast and Thinking

Next to the actions switch is the mode picker, with two settings: Fast and Thinking. Leave it on Fast, which is the default and right for almost everything. Switch to Thinking for a genuinely hard question — several joins, an unusual time window, a definition you expect Rig to have to reason about. It is slower.

Refine, steer and re-run

Ask your follow-up in the same session and Rig keeps the thread's context, so "break that down by month" or "now just the top five" works without restating the original question. Refining in place is nearly always better than starting over with a longer question.

You can also type while a turn is still running. Your message is applied at the next step rather than starting a new turn — the composer shows Steer the agent (Enter to send)… while it is busy, and the send button becomes Stop. Use it to redirect a run that is heading somewhere you did not intend, instead of waiting for an answer you already know you will throw away.

Find a past session

Every thread is saved. Scroll the session list on the left of /chat, or press ⌘K and search — the command palette has a Chats section alongside pages, metrics and data apps. Searching is usually faster than scrolling once you have more than a few days of history.

Good questions vs vague questions

A good question names a measure, a grain and a time window. A vague one leaves Rig to guess at least one of the three, and a guess you did not see is the thing that makes an answer feel wrong later.

• Instead of how are we doing? ask revenue by month for the last six months.
• Instead of customer numbers ask how many new customers signed up each week this quarter.
• Instead of anything odd in refunds? ask refunds by reason last month, highest first.
• Instead of compare the regions ask orders and average order value by region, this month vs last month.

If you are unsure a term means the same thing to Rig as it does to you, ask directly — how is active customer defined? — before you ask for the number.

Common problems

• No rows came back. Open View SQL Query and read the filters and the date range first — an empty result is usually a window with no data in it. If the SQL looks right, the source may not have synced yet; check /connections or ask an admin.
• The answer looks wrong. Open View SQL Query. Most of the time the SQL is reasonable and the definition is not the one you had in mind, which is a fix in the context layer rather than a chat problem — see teaching Rig your definitions.
• Rig says it cannot find the data. The table may not be in the schemas your role has been granted, or the source has not landed yet. Both are worth raising with an admin rather than rephrasing the question repeatedly.
• You asked it to build something and nothing happened. Allow actions was off. Turn it on and ask again.
• The chat is read-only. A chat shared with you can only be continued by its owner, and a chat that started in Slack is answered in Slack. The composer tells you which case you are in.