A practical toolkit for iterating Genie Spaces quality

I have spent a good while iterating Genie Spaces now, and I keep relearning the same lesson. A Space is not something you stand up once and walk away from. It is a product that improves through a deliberate feedback loop. I have pulled together the tools and habits that made the biggest difference for me, and I am posting them here to compare notes. If you run Genie Spaces with real business users, I would genuinely like to know what your loop looks like.

Two tools worth knowing

• Genie Workbench turns Space quality into something you can measure, not just feel. It can generate a new Space straight from business requirements and Unity Catalog sources, score an existing Space with a rule-based IQ assessment, propose quick fixes, and run AUTO OPTIMIZE cycles against a benchmark set. The scoring is the part I value most. Most quality debates stall because nobody can say whether a change actually helped. A repeatable score plus a benchmark turns that argument into a number you can move. It also keeps a scan history, so you can see whether a Space is trending up or down over time rather than relying on memory.

  Below is a screenshot showing the landing page of the Genie Workbench app in action.

  

• prompt-to-genie is a Genie Code agent skill that builds a Space through conversation while following the documented best practices. You describe what the business team needs, and it goes through requirements, data sources, sample questions, and instructions before creating the Space via the API. It also has a diagnose and optimize path for Spaces that already exist, which is useful when you inherit one and want a fast read on what is weak. Worth flagging that this is a community repo rather than an official Databricks project, so treat it as an accelerator and review its output.

The practices that move quality most

1. Put a name against every Space and review it on a cadence. A Space with no clear owner slowly falls out of step with the business as definitions shift, new tables land, and the questions people ask evolve. A short monthly session with the people who actually use the Space surfaces the questions that came back wrong, and those failures are the best possible fuel for the next round of tuning. In my experience, ownership is the single thing that separates a Space people keep trusting from one they quietly stop opening.

2. Spend most of your effort grounding the business logic. This is where the quality of text-to-SQL is won or lost. A foundation model has no way to know how your organization defines a metric like win rate / net revenue. That definition lives in your team's conventions, so you have to make it explicit. In practice, that means a few complementary moves. Curated example SQL queries show Genie how real questions map to real queries. SQL expressions capture reusable measures and filters, so a KPI is defined once and reused everywhere, rather than reinvented for each question. Plain-text instructions carry company context, such as fiscal year boundaries, formatting rules, and the language in which a response should be written. Explicit join relationships stop Genie from guessing how tables connect. The Databricks guide on tuning Genie quality walks through each of these with examples.

3. Then layer the smaller levers that compound. Turn on prompt matching and entity matching for categorical columns so Genie recognises how people actually phrase things and forgives misspelt product names or statuses. Hide columns that are duplicated or confusing, so the model is not distracted by noise. Watch the limits as a Space grows, since each one allows up to 100 instructions and 200 knowledge store snippets, which means curation beats volume every time. Adding everything is not the goal. A tight, well-chosen set of examples outperforms a sprawling one.

The loop that has worked for me

Build the first version with prompt-to-genie so the structure follows best practices from the start. Score it in Genie Workbench to set a baseline. Ground the business logic with examples, expressions, instructions, and joins. Run AUTO OPTIMIZE against a benchmark of real questions. Then hand it to business users, collect failures during the monthly review, and feed them back as new examples. Each pass gets cheaper because the hard definitions are already encoded, and you are only correcting at the edges.

If you want a structured place to start, there is an excellent community thread that compiles this into a checklist: iterating on your Genie Spaces quality and a best-practices checklist. I keep coming back to it whenever I set up something new.

A few things I am curious about. What review cadence has actually stuck for your teams, monthly or something tighter? Has anyone built a real benchmark question set and run AUTO OPTIMIZE against it, and what kind of lift did you see? And how are you capturing failed questions from business users so they feed back into tuning rather than getting lost in a chat thread? Keen to learn from how others are running this.