Exploring Genie Governance Myths: Insights Newsletter

To close out July, I went back through the beliefs I kept running into, the confident sentences said in meetings and threads, and checked each one against what Databricks actually documents. What follows is a guide from past experiences, sorted roughly by theme: the myth, what the docs say, and why the gap between them changes a decision you'd otherwise make wrong.

A few of these I believed myself until a month or two ago. If you've got counter-evidence on any of them, I would genuinely rather be corrected than left confident and wrong.

Part I: The false binary everything rests on

"We have to choose between data democracy and control."

This is the big one, and almost everything else here is a special case of it. The belief assumes that opening data to more people and keeping tight control over it pull in opposite directions, so every step toward democracy costs you a step of safety. On a governed platform that's just false, because the two things live at different layers. Democracy is a property of the interface. Control is a property of the data. Genie is the interface and Unity Catalog is the control, and they don't compete, because they aren't the same layer.

Concretely: you can let a thousand people ask questions in plain language, which is about as democratic as an interface gets, while the rows and columns each of them actually sees are decided by Unity Catalog and are identical to what they'd get from a notebook or a dashboard. Nobody trades one for the other here. You democratize the question and you centralize the boundary on the answer, and those are two different knobs. Once you see the tension as a layering question, it stops being a dilemma and turns into a configuration.

Why this matters for Valeria's dashboard creator, and for anyone building on Genie: the fear of losing control is usually what pushes teams to one of two bad ends. They lock everything down until nobody uses the thing, or they open everything up and hope. Both are the same misconception wearing different clothes. The platform's whole design premise is that you don't have to pick, and the rest of this guide is really just the mechanics of not picking.

Part II: Who sees what

"If a hundred people share one Genie Agent, they all see the same data."

This is the one I'd most want to kill, because it's the belief that drives teams to build a separate agent per sensitivity tier and then drown maintaining them. A Genie Agent runs on a SQL warehouse, and the docs are blunt about it: the author's compute credentials get embedded and used to process every query for every user. Stop reading there and you'd reasonably conclude everyone inherits the author's sight. They don't. Compute identity and data identity are two different things wearing similar names. The embedded credential runs the warehouse engine. Each end user's own data credentials still get applied to the query itself, so a person only sees data they're entitled to, and a question about data they can't reach comes back empty rather than throwing a "you're not allowed" that would confirm the data even exists. One agent, one warehouse, a hundred users, and potentially a hundred different result sets out the other side. That's the mechanism that makes part one real instead of a nice slide.

"Removing a table from the agent hides it from users."

Comforting, and wrong in a way that can bite. The list of tables on an agent is curation: it shapes what Genie reaches for by default. It's not an access boundary, and the docs say so directly. Genie can query tables beyond the ones you added when a user holds the Unity Catalog permission and prompts for a join or just edits the SQL. So if a table is genuinely sensitive, the control is a Unity Catalog permission, a row filter, or a column mask sitting on the table, never its absence from an agent's config. Treating the table list as a security control is how something you thought was walled off shows up in an answer six weeks later.

"Genie needs its own security model my team has to go learn."

Understandable worry, happily false. There's no separate Genie permission universe to master. Row filters and column masks defined in Unity Catalog are enforced per user, at query time, automatically, no matter how the agent gets shared. Define them once on the table and every surface that touches it inherits the same rule, Genie and a dashboard and a notebook alike. The security model you already run for the lakehouse is the one Genie obeys. If there's a lesson, it's the reverse of "learn something new": it's don't build a second, weaker model inside the agent when the strong one already lives on the data.

"Row filters are set-and-forget once they're on."

Check this one tonight. Seriously. A row filter is a SQL function bound to a table, and its parameter type has to match the column it reads. When it doesn't, say a STRING column handed to a filter someone wrote for an INT, then with ANSI mode off the mismatched value casts silently to NULL. A filter written to allow NULL rows will then wave through every row instead of blocking them. The control fails open, and it does it without a sound. Flip ANSI mode on and that cast throws, so the bug surfaces the day you make it instead of the day an auditor finds it for you. A security control should fail loud and obvious. Quiet, fails-open, off-by-default is the exact opposite of what you want standing between a user and data they shouldn't see, and it's the kind of thing that passes every demo and only breaks in production with real data in the table.

Part III: The belief that bigger is better

"The more tables I add, the more capable the agent."

Closer to the reverse. The public guidance is to aim for five or fewer tables per agent, with a hard ceiling of thirty, and accuracy tends to slide as the schema widens because a broad, loosely related pile of tables produces messier generated SQL and a lot more room to pick the wrong join. When a topic genuinely needs more, the documented move is to prejoin the related tables into a view or a metric view first, so the agent reasons over a handful of clean inputs instead of thirty raw ones. Capability comes from focus and curation, from how well five tables are described, not from how many tables you managed to cram in. An agent pointed at five well-modelled tables will usually beat the same agent pointed at twenty-five, and it'll be cheaper to run while it does it.

"Instructions are free, so I'll just keep adding them."

They're not free in either sense of the word. There's a documented ceiling of a hundred instructions per agent, where each example query, each SQL function, and the whole general-instructions block each burn one slot. There's a second, separate ceiling of two hundred knowledge store snippets covering table descriptions, join relationships, and SQL expressions. And past the hard numbers, the docs warn that piling on instructions actively degrades quality, worst of all in longer conversations, because the model has more contradictory guidance to reconcile every turn. Expansion is a budget, not an open tab. Every instruction should earn its slot against that ceiling, and anything that's really business logic belongs in a SQL expression or a metric view, where the model applies it exactly as written, rather than in a paragraph of prose it has to interpret and might interpret differently tomorrow.

"Higher accuracy just means spending more tokens."

Grazia raised this exact question in a thread a couple of days ago, and it deserves an answer that isn't "yes, pay more." A lot of accuracy on Genie comes from things that cost you nothing per token: a tighter table set, a column description that finally tells the model what "net" means in your business, entity matching so "Florida" maps to the stored "FL" instead of an ILIKE that returns nothing, a SQL expression that pins down a KPI once. Those move accuracy by improving the context the model reasons over, not by throwing more compute at a vague prompt. Tokens are the lever people reach for because it's the obvious one. Curation is the lever that actually pays, and it keeps paying after you've set it.

"One big Genie room can serve the whole organization."

Valeria argued this better than I can in her earlier post on steering away from the single catch-all room, so I'll just bolt on the governance angle she didn't need to make. A room spanning many domains doesn't only answer worse, it also makes the access reasoning harder, because the wider the table set the more filters and masks have to line up correctly for that one room to be safe for everyone who can open it. Narrow rooms with a clear purpose are easier to make correct and, the part people forget, far easier to prove correct when someone asks. Scope is a quality decision and a governance decision at the same time, which is why it keeps showing up in both halves of this guide.

Part IV: The belief that it just works

"Genie efficiency is a prompt problem, so I'll tune the model."

Genie writes the query and a SQL warehouse runs it against your tables, and that's where the time and the money actually go. When an agent feels slow or expensive at scale, the lever is almost never the prompt. It's how much data each answer scans and how the warehouse behind it is set up. Serverless SQL warehouses use intelligent workload management to autoscale for the load Genie creates, which is spiky by nature, a hundred people asking around nine in the morning rather than smoothly across the day. Result caching, local and remote, means the second person asking this week's same number reads a cached result instead of paying to recompute it. Heavy repeated aggregations belong in a materialized metric view so the expensive work happens on a schedule, not on every question. Not one of those levers lives in the prompt. They live in the warehouse and the data model, which is exactly the part people skip past when the thing feels slow.

"It's a chat tool, it doesn't need a benchmark."

Genie is nondeterministic, which is the whole reason it does. The failure mode of a nondeterministic system isn't a red error you can't miss. It's a question that used to return the right number and now quietly returns a slightly wrong one, spotted weeks later by the one person who still remembered the old figure. A small fixed set of real business questions with known-correct answers, run before and after any meaningful change, turns that silent regression into a diff you can see. Ten to fifteen questions is plenty to start. Skip it and your regression detector is a user quietly losing trust, and by the time they mention it the trust is already gone. That's doubly true once you start expanding an agent, because every table you bolt on is a change that can move an answer that was already right.

Part V: Governing more than one

"You govern a Genie space in the UI."

You govern one space in the UI perfectly well. You do not govern forty that way. Once the estate grows past what one person can hold in their head, clicking through each space to eyeball its scope and owner and instructions stops being realistic, and the question an auditor actually asks, who changed the finance space on the twelfth and can you show me the same holds across all of them, has no answer that a UI can give. The pattern that scales is to treat each space's definition as governed data in a Unity Catalog table and let a scheduled job reconcile the live estate back to that table. Now the definition is something you can query, diff between two dates, and hand over. The rule that makes it real is the uncomfortable one: the job has to own the estate, or the table is fiction. A manual UI edit that the next reconcile run silently overwrites is worse than having no automation at all, because now you've lost a real change and nobody knows why the answer regressed.

"If a colleague edits a space directly, I'll notice."

By looking? You won't. Unity Catalog records it for you, though. The audit system table captures each action against a Genie Agent with the user identity, the action, and the timestamp. Put a scheduled Databricks SQL alert on a query that asks whether any space changed since the last reconcile by anyone other than the deploying identity, and drift turns into a notification the same day instead of a mystery regression a month later. Databricks even documents monitoring Genie Agents exactly this way. Governance you can query beats governance you remember, and the audit log is the whole difference between the two.

The meta-myth, and where I want to leave it

"Governance slows adoption down."

Here's the belief sitting underneath all the others, and it has the causation backwards. In a regulated shop the thing that actually kills adoption isn't governance, it's the lack of it, because without a control you can point at, the honest answer to "can we open this to the business" is no, or a nervous yes that gets yanked the first time someone sees a row they shouldn't. Governance is what lets you say yes and mean it. Row filters are what let you share one agent widely. An audit trail is what lets you attest to what happened when someone asks. A benchmark is what lets you change an agent without holding your breath. Every one of those enables democracy rather than braking it, which lands us back where Valeria started this morning. Data democracy and control were never opposites. Control is the machinery that makes democracy safe enough to actually hand out.

If I take one thing from a month of these conversations, it's that most Genie governance mistakes aren't technical at all. They're a wrong mental model, held confidently. People bolt a second security layer inside the agent when the strong one already sits on the data. They add tables chasing capability and lose it. They read the embedded-credential line in the docs and design around a wall that was never there. Almost every time, the platform turns out more capable than the myth assumed, and the fix is to do less and trust the governed layer more. If any of this lands differently in your environment, or you've hit an edge I haven't, that's the reply I actually want to read. Happy Genie-ing!

Complete your Databricks User Groups profile!