topic Re: Genie Higher Environment deployment using DAB in Generative AI

Genie Higher Environment deployment using DAB

karuppusamy — Wed, 23 Sep 2026 13:19:03 GMT

Hi Team,

I have successfully developed and tested the Genie in the development workspace environment. I now need to deploy the same Genie to higher environments, such as QA and Production, using the CI/CD process through DAB.

Could someone please share any official documentation or relevant guidance on how to perform this deployment?

Thanks in advance for your help.

Re: Genie Higher Environment deployment using DAB

Ashwin_DSA — Wed, 23 Sep 2026 15:21:17 GMT

Hi @karuppusamy,

Databricks fully supports deploying Genie Agents (formerly Genie Spaces) as code using Declarative Automation Bundles (DABs), which makes CI/CD promotion from dev to QA to production straightforward

As of Databricks CLI version 1.3.0, you can define a Genie Agent as a genie_spaces resource in your databricks.yml. A key requirement is that Genie Agent bundles must use the direct deployment engine (engine: direct).

Here is a minimal example.

# databricks.yml bundle: name: my-genie-agent engine: direct # required for genie_spaces resources: genie_spaces: my_genie: title: 'Sales Analytics Agent' description: 'Ask questions about sales data' warehouse_id: ${var.warehouse_id} file_path: ./my_genie.geniespace.json permissions: - level: CAN_RUN group_name: users

The file_path points to a JSON file that holds the full serialized definition of your Genie space, including data sources, column configs, text instructions, and sample questions. You can export this from your existing dev Genie and check it into source control alongside your bundle config.

To deploy the same Genie to QA and Production, define separate targets in your bundle and use variables to swap environment-specific values like warehouse_id and catalog names. Refer here.

variables: warehouse_id: description: SQL warehouse for the Genie Agent catalog: description: Unity Catalog to query targets: dev: mode: development default: true workspace: host: https://dev-workspace.databricks.com variables: warehouse_id: abc123 catalog: dev_catalog qa: workspace: host: https://qa-workspace.databricks.com variables: warehouse_id: def456 catalog: qa_catalog prod: mode: production workspace: host: https://prod-workspace.databricks.com root_path: /Workspace/Production/.bundle/${bundle.name} run_as: service_principal_name: '<your-sp-application-id>' variables: warehouse_id: ghi789 catalog: prod_catalog

Then deploy to each environment in your CI/CD pipeline:

databricks bundle validate --target qa databricks bundle deploy --target qa databricks bundle validate --target prod databricks bundle deploy --target prod

I would recommend using a service principal for production. Setting run_as to a service principal ensures deployments and runs are not tied to an individual user account. Databricks recommends this for any staging or production target.

Also, when you set mode: production, the CLI validates that Git branches match, artifact paths are not user-specific, and permissions are explicitly declared. You can override the Git check with --force if needed.

Hope this helps you get your Genie promoted smoothly. If you run into anything specific during the deployment, feel free to share the error and we can dig in further.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Re: Genie Higher Environment deployment using DAB

karuppusamy — Wed, 23 Sep 2026 16:24:01 GMT

Thank you Ashwin_DSA!

Re: Genie Higher Environment deployment using DAB

stephen4 — Wed, 23 Sep 2026 23:55:08 GMT

Thanks for sharing this, the genie_spaces approach makes the Dev to QA to Prod flow much clearer. Using separate targets and variables for each environment is a really practical setup. The service principal recommendation for production is a useful detail too.

Re: Genie Higher Environment deployment using DAB

karuppusamy — Fri, 25 Sep 2026 10:14:36 GMT

Hi Aswin and Team,

I have tried deploying the Genie to the higher environments using Databricks DAB and Azure DevOps, but the deployment is not working as expected. I am facing the issue shown below.

Additionally, within Databricks, I do not see any option to download or export Genie Agents. For notebooks, I can easily download, export, and manually import them into another workspace, but I cannot find a similar option for Genie Agents.

I am able to deploy notebooks and AI/BI Dashboards successfully; however, the Genie deployment is not working as expected.

I truly appreciate and respect your response and your willingness to help answer my question. However, after testing the suggested approach, I am sorry to say that it does not seem to work as expected in my case.

Could someone from the Databricks team who has successfully deployed Genie using DAB and Azure DevOps please help by sharing the official documentation or recommended deployment approach? This would help establish a standard process that all Databricks users can follow for deploying Genie across their projects.

Thank you for your support and guidance.

Re: Genie Higher Environment deployment using DAB

Ashwin_DSA — Fri, 25 Sep 2026 13:57:58 GMT

Hi @karuppusamy,

Thanks for sharing the error snapshot. What you are seeing is expected behaviour rather than a bundle misconfiguration. Genie Agents are an unsupported asset type for commits in Databricks Git folders, so the workspace Git integration cannot sync the .geniespace.json. That is why your notebooks and dashboards go through fine, but the Genie does not.

The fix is to keep the Genie out of the workspace Git folder sync path and let the Databricks CLI deploy it from your Azure DevOps checkout through the API.

There is no UI download for a Genie Agent, so generate it with the bundle generate genie-space command.

databricks bundle generate genie-space \ --existing-id <your-genie-space-id> \ --key inventory_genie

This writes the resource YAML and a src/*.geniespace.json into your bundle. If you prefer the REST route instead, call the Genie Space API with GET /api/2.0/genie/spaces/{space_id}?include_serialized_space=true and save the serialized_space payload.

Keep that .geniespace.json in your Azure DevOps repo alongside databricks.yml, not inside a Databricks workspace Git folder. Set engine: direct in the bundle, which the genie_spaces resource requires.

Deploy from the pipeline with the CLI, which reads the file from the agent filesystem and pushes it via the API. This slots straight into the standard Azure DevOps CI/CD flow for bundles.

databricks bundle validate --target $(BUNDLE_TARGET) databricks bundle deploy --target $(BUNDLE_TARGET)

A quick checklist before you retry.

Databricks CLI 1.3.0 or later, latest preferred, which you can confirm with databricks --version.
engine: direct set in databricks.yml, per the direct deployment engine docs.
The .geniespace.json lives in the external repo and is never synced through a Databricks Git folder.
The warehouse id and any catalog or schema the Genie references exist in the target workspace.

Once you move to CLI-driven deploys from the pipeline instead of Git folder sync, the Genie will land in QA and prod cleanly.

Re: Genie Higher Environment deployment using DAB

ivanvyd — Fri, 25 Sep 2026 22:08:47 GMT

@karuppusamy one practical addition to @Ashwin_DSA CLI steps: I'd explicitly separent_path on the genie_spaces resource to an existing workspace folder outside the Git folder, writable by your deployment identity.

These two paths serve different purposes: file_path points to the exported JSON definition in your Azure DevOps checkout; parent_path controls where the deployed Genie Agent is registered. Both are documented in the Genie bundle resource reference⁠.

Keep the YAML and JSON definition in source control, but keep the native Genie Agent out of the workspace Git folder. The Git-folder restriction⁠ concerns the native agent asset; exporting its definition and deploying it through the CLI is a separate operation.