Course overview/Bring in the agent1 of 4
Ask the agent for a query
Ask the agent for a query
Turn a plain-English question into a well-formed request, and always read the SQL first.
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
Establish the reflex now: 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. Open that file and read the "How to teach" section, so you can see where the rule lives and what the agent has been told to do.
Ask the spine question
Here is the question this course is built around. Ask it, let the agent surface the decisions, answer them, and save the query it writes to queries/agent_v1.sql.
"Which product categories grew from 2023 to 2024, and which customers drove that growth?"
Ask your coding agent
Which product categories grew from 2023 to 2024, and which customers drove that growth?
Before you write any SQL, tell me what you need me to decide: what "grew" means, whether to measure it in revenue or order count, which revenue column to use, how many customers counts as "drove that growth", and what grain you will return. Wait for my answers, then write the query and show it to me before running it.
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.
Two notes on what to expect. First, the project's AGENTS.md tells the agent not to write course exercises for students who have not attempted them - but it may write queries when you ask it to directly, and this prompt asks directly, so it will. Second, 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.
Checkpoint
Save the agent's query to queries/agent_v1.sql and confirm its 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
productsas 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.
You are not auditing the logic yet. That is the next lesson. Here you are checking that the request was specific enough to produce a query you can read.