Chat
How the SQL agent works
When you ask a question in chat, GoPie doesn't recall an answer — an agent queries your data and reports what it finds. This page is the mental model: how the agent finds the right tables, writes and repairs SQL, and why every answer comes with evidence. If you haven't chatted yet, start with the chat tutorial.
Follow the loop#
The agent works in a loop of tool calls, and the chat streams each step as it happens — you can watch the phases in the transcript (Context, Discovering datasets, Planning query, Running query, Validating results) and expand them later with Show steps.
- Read the context. The agent starts from what you attached: the schemas of your selected datasets and views, and an overview of the selected projects.
- Find the data. If the attached context doesn't obviously answer the question, it searches your datasets semantically (see below) — and, when the project has context documents, it can search those too.
- Write and run SQL. It drafts a query against the schemas it found and runs it in the same SQL dialect as the SQL playground.
- Check and repair. If the query errors, the error goes back into the loop and the agent rewrites the query. After a couple of failed repairs it stops and explains what went wrong instead of guessing.
- Answer. The reply is prose grounded in the executed results, with the SQL and the rows attached as evidence.
A chart is generated only when you ask for one — "show the monthly trend as a line chart" — never speculatively. See Reading results.
Know how it finds your data#
Dataset discovery is a semantic search, not a keyword match. Every dataset and view is indexed with its name, description, column names, column descriptions, and sample values — as vectors that capture meaning, combined with a classic keyword ranking. That's what lets "sales" find a revenue column, or "customers" find a user_accounts table, even when the words don't match.
Two practical consequences:
- Descriptions are leverage. The richer your dataset and column descriptions, the better the agent's aim — they are indexed and searched, not just displayed.
- Business terms work. You don't need to know table names. Ask in the vocabulary your team uses, and keep using it consistently.
Watch loose values get matched#
When a question names a value loosely — "revenue for electronis", "orders from califronia" — the agent doesn't guess the spelling. It searches the actual column values with pattern and fuzzy matching, finds Electronics or California, and filters on the value that really exists. You'll see this in the steps timeline as a lookup against the column before the main query runs.
This works for spelling, casing, and partial names. It can't invent values that aren't there — if nothing in the column resembles the term, the agent says so.
Know what the agent sees#
Every piece of context you invest in reaches the agent:
| Context | Used in chat |
|---|---|
| Dataset schemas — columns, types, sample values | Always, for attached and discovered datasets |
| Dataset & column descriptions | Always — indexed for search and injected into prompts |
| Custom AI prompts on datasets and views | Always, for the datasets/views in play |
| Project-level custom AI prompt | Always, once per attached project |
| Context documents | Searched on demand when the question needs them |
| Query results | A sample of the executed rows — large results are truncated for the model, while the full rows stay in the results panel |
Dictionaries are the exception: they inform data cleaning during ingestion, not chat.
Understand the limits#
- Each turn has a budget. The agent gets a bounded number of tool calls (around ten) and a few minutes of wall-clock time per question. If it can't converge, it stops and tells you rather than looping forever.
- Conversation memory is bounded. Long chats keep roughly the last twenty messages of context. When you change topics, start a new chat.
- The model reasons over a sample. Very large query results are truncated before the model sees them (a few hundred rows); the full results stay available in the results panel and in exports.
Trust, but verify#
Every answer carries its own evidence: the datasets it used are cited under the reply, every executed query is inspectable in the steps and the results panel, and the actual rows are one click away. If a question can't be answered from the data, the agent says so in plain language instead of inventing a number — that's a normal response, not an error.
For exactly what does and doesn't leave your deployment on the way to the model, see AI data privacy.