Work with the agent.
The agent reads your schema, drafts queries, and proposes them as cells you review before running. Writes always require an explicit approval — that's the whole point.
What you'll build
A two-cell analysis built entirely through agent prompts: a query for weekly active users by source, then a follow-up that breaks out week-over-week change. Along the way you'll see the propose-review-accept loop and the write-approval modal that gates anything destructive.
A connected database with an events or sessions-style table. The free tier uses Gemini out of the box — see Agents overview if you want to switch to Claude or GPT.
1. Open the agent panel
Click the chat icon in the activity bar to open the agent on the right. By default you're in single agent mode — one assistant with the full tool registry. (Multi-agent mode routes to specialists; toggle it in agent settings if you want to try it, but single is fine here.)
2. Prompt for the first query
Type a plain-English description of what you want. Don't over-specify — the agent will ask follow-ups if it's unsure.
Show me weekly active users by source for the last 12 weeks.
Use the events table.The agent inspects your schema, picks the right columns, and streams a response. Critically, it doesn't just print SQL into chat — it inserts a proposed SQL cell directly into the notebook with a pending-review badge. See Single agent mode for what tools it has access to.
3. Review the proposal
Read the SQL. The agent will explain its choices in chat — which tables it joined, why it chose date_trunc('week', ...), what assumptions it made about source (a column? a UTM param?). If it got something wrong, say so. If it got it right, click Accept and the cell becomes a normal SQL cell you can run.
SELECT
date_trunc('week', occurred_at) AS week,
source,
COUNT(DISTINCT user_id) AS active_users
FROM events
WHERE occurred_at >= now() - interval '12 weeks'
GROUP BY 1, 2
ORDER BY 1, 2;Hit Cmd-Enter to run. The result lands inline. The agent sees the result in its context, which makes the next prompt much cheaper to write.
4. Iterate with a follow-up
You don't need to restate context — the agent remembers the active cell and its output.
Now break out week-over-week change in active users for each source.The agent proposes either an edit to the existing cell or a new cell — whichever is more appropriate. In this case, a new cell that builds on the previous result is cleaner. It uses a LAG() window function and references the prior cell's variable name in its reasoning.
SELECT
week,
source,
active_users,
active_users - LAG(active_users) OVER (PARTITION BY source ORDER BY week) AS wow_delta,
ROUND(100.0 * (active_users - LAG(active_users) OVER (PARTITION BY source ORDER BY week))
/ NULLIF(LAG(active_users) OVER (PARTITION BY source ORDER BY week), 0), 1) AS wow_pct
FROM ({/* previous query */})
ORDER BY source, week;Accept, run, and you have your week-over-week breakdown.
5. Reject and re-prompt
Try a deliberately ambiguous prompt to see what rejection feels like:
Add the same chart but only for paid sources.Suppose the agent guesses wrong about which sources count as paid. Click Reject. The cell disappears and the agent asks a clarifying question in chat — typically something like "Which sources should I treat as paid? I see 'google_ads', 'facebook_ads', 'newsletter', and…". Answer in plain language and the agent re-proposes. See Prompting the agent for tips on cutting down the clarify-and-retry loop.
6. See the write-approval modal
The agent gates write operations behind a separate, more deliberate approval step. To see it, ask for a destructive change:
Set source = 'organic' for all rows where source IS NULL in the events table.Instead of inserting a pending-review cell, the agent surfaces a write approval modal. The modal shows the exact SQL it intends to run, the target integration, and the estimated row count (sampled via a COUNT(*) dry run). You must click Approve and run for anything to happen — accepting the cell is not enough.
If you reject, nothing runs. If you approve, the agent executes the write and reports back with the actual affected row count. The full operation — prompt, proposed SQL, approval, result — is logged in the agent activity tab. See Approvals for the full safety model.
There is no setting to disable the write modal. INSERT, UPDATE, DELETE, DROP, TRUNCATE — all require explicit approval on every run. This is by design.
Where to go next
- Prompting the agent — write prompts that need fewer clarifications.
- Agent tools — the full registry of what the agent can do (query, plot, write files, fetch URLs, run shell commands in the project sandbox).
- Multi-agent mode — orchestrator + Data, Analyst, Viz, and Report specialists for longer workflows.
- Approvals model — the read-vs-write distinction and how to audit past agent actions.