You set up a Databricks Genie agent for the sales team on 14 tables. Users report that "revenue last quarter" gives different numbers from the finance dashboard, and "active customers" is answered 3 different ways. How do you make it reliable?

Genie writes SQL from what it can read: table and column descriptions, the business definitions you give it, and examples. Here it has too many tables and no definition of revenue or active customer, so it guesses. Narrow the data (ideally a few prejoined views or a metric view), define revenue and active customers as SQL expressions, add example SQL for the hard questions, keep text instructions short, and measure the result with benchmark questions before and after each change.

1. Find out why each answer differs

Open the generated SQL for the wrong answers and compare it with the finance dashboard's query. Typical differences:

• Gross instead of net revenue, or refunds and tax included.
• order_date used where finance uses invoice_date.
• "Last quarter" taken as the last 90 days instead of the previous calendar or fiscal quarter.
• Joining orders to order lines and summing a header total, counting it once per line.

Each of these is a missing definition, not a bad model.

2. Shrink and clean the data

Databricks advises starting with 5 or fewer tables. Replace the 14 raw tables with 2 or 3 views shaped for sales questions, or a metric view that already defines measures and dimensions. Write clear Unity Catalog descriptions for every column left, hide columns that invite mistakes (such as gross_amount_incl_tax when nobody should use it), and add synonyms such as "client" for customer.

3. Define the business terms in SQL

Databricks puts these in this order of preference: SQL first, text last. Long lists of text instructions lose effect and start to conflict, for example an instruction to round to 2 decimals while an example query rounds to 0.

4. Make it ask instead of guess

For questions that need a detail, write the clarification rule with its trigger, the missing detail, the action and the question to ask: "When users ask about revenue without a time range or currency, ask: Which period and currency do you want?"

5. Measure, then widen

• Turn the questions finance can answer into benchmarks with the expected SQL, and run them after each change.
• Watch the Monitoring tab and user feedback for new failures, and add examples for the questions that fail.
• Add tables only when a real question needs them.

What interviewers want: reading the generated SQL to find the cause, fewer and better-described tables, metrics defined once as SQL expressions, example queries over text instructions, clarification rules, and benchmarks to prove accuracy rather than spot checks.