Ask the agent for a query

A good request has four parts

You can read SQL now, so you can start delegating it. A vague request produces a plausible query built on guesses. A well-formed one pins down the four things an agent would otherwise invent:

• The question, in plain language.
• The grain you want back: one row per what?
• The filters that are non-negotiable: which rows must be in or out.
• The definition of any metric you name: which column is "revenue"?

Compare the two. "Show me revenue by category" leaves all four open, so the agent picks a revenue column, a date range, and a grain for you. "Total line revenue as quantity * net_price, by product category, for orders placed in 2024, one row per category" leaves nothing to guess. The second request produces a query you can check. The first produces one you have to reverse-engineer.

Always read the SQL before it runs: see the SQL, read it, then run it. The AGENTS.md file in the project root already tells the agent to show its SQL before running and to ask a clarifying question when the request is ambiguous, so the reflex is built into the setup - you just have to use it.

This course is built around one question, the spine question:

"Which product categories grew from 2023 to 2024, and which customers drove that growth?"

The years are named on purpose. This dataset declines in 2025 by design, so a question about the most recent year returns an empty or negative result that looks like a broken setup. Comparing 2023 to 2024 is the growth story the data actually contains. The question has two halves. This lesson and the next three work on the category half; the customer half returns in the capstone, once you can audit the join it needs.

Your task

Ask your agent the spine question. Make it surface the decisions before it writes any SQL: what "grew" means, whether to measure it in revenue or order count, which revenue column to use, how many customers count as "drove that growth", and what grain it will return. Answer each one, then have it write the query. Read the SQL before you run it. Save the result to queries/agent_v1.sql.

You are not auditing the logic yet - just checking your request was specific enough to produce a query you can read. When saved and run, confirm the shape:

• The result has one row per product category: eight rows, or nine if the agent kept the order lines whose product id has no match in products as their own bucket.
• If the agent measured revenue as quantity * net_price, the 2024 total across a nine-row result reconciles to 338,209.56, the correct 2024 line revenue. An eight-row result sums to 336,812.67 instead - 1,396.89 short. That gap is real, it is not your setup, and finding where it went is exactly the kind of question the next lesson teaches you to ask.

Check your understanding

• What are the four parts of a well-formed request?
• Why read the SQL before running it?
• How many rows should a "revenue by category" result have, and what does an extra bucket mean?

Do it with your agent

Say next lesson and your agent teaches this, asks you these questions, then sets the task above. Do it by hand, then say review my work - it checks your work against a rubric and tells you what to fix or marks the lesson done.