Most Genie Agents start life the same way. Someone opens a workspace, adds a few tables, writes instructions and example queries, tests a handful of questions, and shares it. That flow is fast, and it is exactly right for getting started. The trouble shows up later, when the agent becomes something a business actually depends on.
At that point, the click-built model quietly runs out of road. There is no change history, so nobody can say what changed between last week's good answers and this week's odd ones. There is no clean way to promote a proven agent from a test workspace into production without rebuilding it by hand. And there is no rollback when an edit makes things worse. The agent that a team relies on is managed less carefully than the smallest piece of application code.
The fix is to treat a Genie Agent as you would any other important asset. Define it as code.
Genie Agents can be defined in a Bundle
Databricks documents this directly. The guidance is to use Declarative Automation Bundles to define, deploy, and version-control your Genie Agents as code. In bundle terms, the resource is genie_spaces, which maps to the Genie create API, so the agent configuration lives in a repository rather than only in a workspace UI.
Once the configuration is in a bundle, three things follow that you cannot get from clicking. You get reproducible deployments because the same definition produces the same agent every time. You get the change history because the repository records what changed and who changed it. And you get the ability to promote agents across environments, from development to staging to production, from one source of truth.
One honest caveat before you try it
There is a real constraint worth stating plainly. Defining Genie Agents in a Declarative Automation Bundle is supported only when you use the direct deployment engine. If you are on the default engine, the resource will not deploy, and the failure is confusing if you were not expecting it. Check that first, and you save yourself an afternoon.
Code alone is not quality. Pair it with curation
Version control makes an agent reproducible. It does not make it accurate. The two have to travel together, and the public curation guidance pairs naturally with a code workflow.
Keep the agent focused, starting with five or fewer tables rather than a sprawling everything space. Prefer SQL expressions and example SQL queries over text-only instructions, because concrete examples are what actually steer behaviour. Use metric views to predefine metrics and dimensions so a term like active customer means one thing. Add column descriptions and synonyms so the agent maps business language to your schema consistently. All of that lives in the same bundle, so the agent's meaning is versioned alongside its structure.
Make benchmarks the promotion gate
Here is where the lifecycle gets its teeth. Before you promote an agent from staging to production, run its benchmark set and read the accuracy. Benchmarks are the systematic checks that a change actually improved the agent rather than just changing it. Wiring that checks into the promotion step turns benchmarks from a nice-to-have into a gate: an agent moves forward only when the numbers show it has earned the move. That is the difference between hoping a curation edit helped and knowing it did.
A lifecycle you can actually run
Putting it together, here is the loop I would set up for an agent that matters.
Author in a workspace. Build and rough-tune the agent the fast way, by clicking, until it is roughly right.
Capture it as a bundle. Move the configuration into a
genie_spacesresource in a repository, and confirm you are on the direct deployment engine.Curate in code. Add metric views, SQL example queries, column descriptions, and synonyms, and keep the table count tight.
Gate on benchmarks. Run the benchmark set in staging and promote to production only when accuracy holds or improves.
Promote and record. Deploy from the single source of truth, so every environment matches and every change has a history.
Roll back when needed. When an edit regresses quality, revert to the previous version instead of trying to remember what the agent used to look like.
Why this matters
A Genie Agent that a business depends on is production software, even though it was built through a friendly UI. The moment more than one person relies on it, the questions become the same ones you ask of any production system.
What changed? Can we reproduce it? Can we promote it safely? Can we undo it?
Defining the agent as code with Bundles answers all four, and pairing that with curation and a benchmark gate means the version you promote is also the version you can trust. The click-built start is fine. The dependable finish needs a lifecycle.
A few questions for the community
Are you defining any Genie Agents as code today, or is everything still click-built in the workspace?
If you promote agents across environments, what is your gate before production, benchmarks or something else?
How are you handling rollback when a curation change makes answers worse?
If you want to trade Genie lifecycle patterns, connect with me on LinkedIn: linkedin.com/in/lingeshwarankanniappan.
Sources
Curate an effective Genie Agent, Databricks documentation: docs.databricks.com
Declarative Automation Bundles resources, Databricks documentation: docs.databricks.com
What are Declarative Automation Bundles, Databricks documentation: docs.databricks.com