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.

Prerequisites

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.)

The Orchid IDE with the agent chat panel open on the right, showing an empty message log and the prompt box at the bottom./docs-images/tutorials/agent-walkthrough/01-agent-open.png
The agent panel docks on the right. It sees the active notebook, the schema, and your selection.

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.

A SQL cell with a yellow pending-review border, an Accept and Reject button beneath it, and the agent panel showing its reasoning./docs-images/tutorials/agent-walkthrough/02-proposed-sql.png
Proposed cells are visually distinct — pending-review border, accept/reject buttons, agent reasoning beside them.

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.

The notebook now has two SQL cells — the original WAU query and the WoW-change follow-up. Both have green Run badges./docs-images/tutorials/agent-walkthrough/03-followup-accepted.png
Two accepted cells from two prompts. The agent kept context across the turn.

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.

A modal dialog titled Approve write operation, showing the proposed UPDATE statement, the target connection, the estimated affected row count, and the integration the change will run against./docs-images/tutorials/agent-walkthrough/04-write-approval.png
The write modal is intentionally heavier than cell approval. Estimated row count plus full SQL preview before anything mutates.

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.

No silent writes

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.