Complete your Databricks User Groups profile!

Fill out a few details about yourself so the community can get to know you.
Genie Community

Understanding the Risks of Expanding a Genie Agent Beyond Its Capacity

Summary: Lingeshwaran Kanniappan discusses the challenges and limits of expanding a Genie Agent, advising on the prudent use of tables to ensure optimal performance. They highlight hard limits such as 30 tables and suggest strategies like expanding in place, using metric views, or splitting into multiple agents. The importance of monitoring for regressions with a fixed set of questions is emphasized to maintain trust and efficiency. Practical questions are posed to the community to foster further discussion and insights.
AI Summary

Have you ever thought of how big can my Genie Agent (formerly known as Genie Spaces) get?

What will happen if I start hitting the limits of a Genie Agent - can I still get the best results from it?



There is an advice out there - Don't use more than 5-10 tables in a Genie space for the best results.

The five-table advice is good and everyone repeats it. What almost nobody writes down is what happens in month three, when an agent that launched clean has to absorb six more tables the business now wants in it. Each addition is a change to a system that was already giving correct answers.

Genie is nondeterministic (it is probabilistic) and tuned to your enterprise and how you benchmark it, so the failure mode is not a red error. It is a question that used to be right and now quietly is not, found weeks later by the one person who still remembered the old number.

So the skill that matters is growing an agent without silently breaking it. Building the first version is the easy half.

The three ceilings nobody mentions until you hit them

Genie Agents have hard limits, and casual expansion reaches them faster than people expect.

  1. 30 tables per agent, with the documented recommendation to aim for five or fewer.

  2. 100 instructions per agent. Each example query, each SQL function, and the entire general instructions block each count as one.

  3. 200 knowledge store snippets, shared across table descriptions, join relationships, and your SQL expressions (measures, filters, and dimensions).

After a few months of adding things because someone asked, you find these walls. By then, working out which of 100 instructions and 200 snippets still earn their place is real work. Expansion is a budget, not an open tab.

The question to ask before adding anything

Every time the business wants more in the agent, I would first decide which of three moves it actually is.

  1. Expand in place: The new table serves the same purpose and adds a few columns to questions the agent already answers. Add it, define its joins, describe its columns. This is the only case where "just add the table" is the right answer.

  2. Pre-join into a metric view: The request is really about reusing the same metrics across more dimensions, or you are about to pass the table count. Define the metric once in a Unity Catalog metric view, keep the joins and agent metadata there, and point the agent at that rather than five more raw tables. One well-modelled input beats five loose ones, and the metric definition stops drifting every time the schema grows.

  3. Split into a second agent: The new questions have a different audience, grain, or trust level. That is a new agent. Forcing unrelated domains into one room is how you end up with something broad and slow that answers nothing well. Valeria's post on narrow rooms argues this case better than I can.

Most "it got worse after we grew it" stories are a case two or a case three that got handled as a case one.

Catching the regression before a user does

Genie will not warn you that an old answer broke. You need a small fixed set of real business questions with known-correct results, run before and after every meaningful change, so a regression shows up as a diff instead of a complaint. Ten to fifteen questions is enough to start. The Evaluations surface and knowledge mining (Genie proposes joins and SQL expressions from the queries authors thumb up) help you curate, but the before-and-after habit is yours to enforce. If you cannot measure the answers you already trust, you cannot safely add to the agent.

Treat the agent's scope like a schema, not a scratchpad. Every table earns its place against a ceiling. Metrics live in one definition, not scattered across instructions. And each expansion clears the same small benchmark the last one did. Do that and the agent grows more useful. Skip it and it loses trust while looking exactly the same from the outside.

Can you answer these questions?

  1. Once you pushed an agent past ten tables, did you keep expanding in place, or did metric views end up carrying the weight?

  2. What is the smallest regression check you have that actually gets run every time, rather than the thorough one that gets skipped?

If you are working through this on real agents 🤖, connect with me here: linkedin.com/in/lingeshwarankanniappan

Sources

0 comments