https://community.databricks.com/t5/technical-blog/managing-databricks-genie-agents-as-code-with-databricks/ba-p/164697 <P class="code-line" data-line="18">Databricks Genie Agents (formerly Genie Spaces) are domain-specific, no-code chat interfaces that let business users ask natural-language questions about their data and get back SQL queries, result tables, and visualizations. As a Genie Agent grows more sophisticated, with carefully crafted instructions, SQL filter snippets, example queries, and evaluation benchmarks, a new problem emerges: how do you manage all of that configuration reliably across environments?</P> <P class="code-line" data-line="20">If your team is editing agent instructions directly in the Genie UI, you have no version history, no code review, and no reliable path to promote changes from dev to production. One wrong update and there's no rollback.</P> <P class="code-line" data-line="22">In this post I'll show how to solve that using<SPAN>&nbsp;</SPAN><STRONG><A href="https://docs.databricks.com/aws/en/dev-tools/bundles/resources#genie_space" target="_blank" rel="noopener" data-href="https://docs.databricks.com/aws/en/dev-tools/bundles/resources#genie_space">Declarative Automation Bundles (DABs)</A></STRONG><SPAN>&nbsp;</SPAN>to manage a Genie Agent and its underlying Unity Catalog metric view entirely as code.</P> <H2 id="the-problem-with-ui-only-genie-agent-management" class="code-line" dir="auto" data-line="24">The problem with UI-only Genie Agent management</H2> <P class="code-line" data-line="25">A production-ready Genie Agent carries a surprising amount of configuration:</P> <UL class="code-line" dir="auto" data-line="26"> <LI class="code-line" dir="auto" data-line="26"><STRONG>Text instructions</STRONG>: rules governing how the agent interprets questions, resolves ambiguity, and formats responses</LI> <LI class="code-line" dir="auto" data-line="27"><STRONG>SQL filter snippets</STRONG>: pre-built filters users can reference naturally ("show me US revenue")</LI> <LI class="code-line" dir="auto" data-line="28"><STRONG>Example queries</STRONG>: Q&amp;A pairs that teach the agent how to respond to common questions</LI> <LI class="code-line" dir="auto" data-line="29"><STRONG>Benchmark questions</STRONG>: ground truth SQL used to evaluate answer quality</LI> <LI class="code-line" dir="auto" data-line="30"><STRONG>Column configs</STRONG>: controls format assistance (how values are displayed) and entity matching (so "germany" resolves to<SPAN>&nbsp;</SPAN><CODE>Germany</CODE><SPAN>&nbsp;</SPAN>in the Country dimension); entity matching requires format assistance to be enabled on the column</LI> </UL> <P class="code-line" data-line="32">When all of this lives only in the UI, you get:</P> <UL class="code-line" dir="auto" data-line="33"> <LI class="code-line" dir="auto" data-line="33">No audit trail for who changed what and when</LI> <LI class="code-line" dir="auto" data-line="34">No peer review before changes hit production</LI> <LI class="code-line" dir="auto" data-line="35">No reliable way to promote the exact same configuration from dev to prod</LI> <LI class="code-line" dir="auto" data-line="36">No rollback if a bad instruction update breaks query behavior</LI> </UL> <P class="code-line" data-line="38">The fix: treat the Genie Agent like any other piece of software: version-controlled, reviewed, and deployed through a pipeline.</P> <H2 id="solution-overview-declarative-automation-bundles" class="code-line" dir="auto" data-line="40">Solution overview: Declarative Automation Bundles</H2> <P class="code-line" data-line="41">Declarative Automation Bundles (DABs) is Databricks' infrastructure-as-code framework. It supports jobs, pipelines, dashboards, and as of CLI v1.10,<SPAN>&nbsp;</SPAN><STRONG>Genie Agents</STRONG><SPAN>&nbsp;</SPAN>as first-class resources.</P> <P class="code-line" data-line="43">The approach has two key pieces:</P> <UL class="code-line" dir="auto" data-line="44"> <LI class="code-line" dir="auto" data-line="44"><STRONG>UC Metric View</STRONG>: the semantic layer that backs the Genie Agent, defined in YAML</LI> <LI class="code-line" dir="auto" data-line="45"><STRONG>Genie Agent</STRONG>: the agent configuration (instructions, snippets, benchmarks), exported from the workspace and committed as JSON Both are versioned in git and deployed via<SPAN>&nbsp;</SPAN><CODE>databricks bundle deploy</CODE>.</LI> </UL> <H2 id="repository-structure" class="code-line" dir="auto" data-line="48">Repository structure</H2> <P class="code-line" data-line="49">The full example is on GitHub:<SPAN>&nbsp;</SPAN><A href="https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-08-genie-agent-cicd" target="_blank" rel="noopener" data-href="https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-08-genie-agent-cicd">https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-08-genie-agent-cicd</A></P> <LI-CODE lang="markup">genie-agent-cicd/ ├── databricks.yml # bundle config, targets (dev/prod) ├── prebuild_notebook.py # substitutes {schema} into Genie Agent JSON — runs locally OR in Databricks │ ├── resources/ │ ├── metric_view.job.yml # job: CREATE OR REPLACE metric view │ └── tpcds_retail.genie_space.yml # Genie Agent resource definition │ ├── src/ # source of truth — uses {schema} placeholders │ ├── metric-view.yaml # metric view dimensions and measures (edit this; substitution handled by DABs at run time) │ ├── create_metric_view.py # notebook that runs CREATE OR REPLACE; receives catalog/schema as job parameters │ └── tpcds_retail.geniespace.json # Genie Agent content (edit this; substitution handled by prebuild_notebook.py) │ └── build/ # generated by prebuild_notebook.py — gitignored └── tpcds_retail.geniespace.json</LI-CODE> <P class="code-line" data-line="67">Two files are the source of truth:<SPAN>&nbsp;</SPAN><CODE>src/metric-view.yaml</CODE><SPAN>&nbsp;</SPAN>defines the semantic layer (dimensions, measures, synonyms), and<SPAN>&nbsp;</SPAN><CODE>src/tpcds_retail.geniespace.json</CODE><SPAN>&nbsp;</SPAN>holds the agent configuration (instructions, SQL snippets, benchmarks).</P> <P class="code-line" data-line="69">A small Python script (prebuild_notebook.py) substitutes<SPAN>&nbsp;</SPAN><CODE>${catalog}</CODE><SPAN>&nbsp;</SPAN>and<SPAN>&nbsp;</SPAN><CODE>${schema}</CODE><SPAN>&nbsp;</SPAN>placeholders into the Genie Agent JSON before deployment.</P> <P class="code-line" data-line="71">A separate notebook (src/create_metric_view.py) handles the metric view: it reads<SPAN>&nbsp;</SPAN><CODE>src/metric-view.yaml</CODE><SPAN>&nbsp;</SPAN>at runtime and substitutes catalog/schema from job parameters before running the DDL.</P> <P class="code-line" data-line="73">The Genie Agent and metric view are both deployed via<SPAN>&nbsp;</SPAN><CODE>databricks bundle deploy</CODE>, with the metric view applied by running the bundle job.</P> <H2 id="why-this-pattern-works" class="code-line" dir="auto" data-line="75">Why this pattern works</H2> <P class="code-line" data-line="76"><STRONG>The metric view YAML is human-friendly.</STRONG><SPAN>&nbsp;</SPAN>The inline source query, joins, dimensions, and measures are all readable and diff well in pull requests. A reviewer can see exactly which UNION ALL branch changed, which join was added, or which synonym was modified.</P> <P class="code-line" data-line="78"><STRONG>The<SPAN>&nbsp;</SPAN><CODE>.geniespace.json</CODE><SPAN>&nbsp;</SPAN>is structured JSON, not a blob.</STRONG><SPAN>&nbsp;</SPAN>When DABs introduced the<SPAN>&nbsp;</SPAN><CODE>genie-space</CODE><SPAN>&nbsp;</SPAN>resource type, it made the agent config a proper file rather than a stringified JSON-inside-JSON. Every section (instructions, snippets, benchmarks, column configs) is a first-class JSON object you can edit and review.</P> <P class="code-line" data-line="80"><STRONG><CODE>databricks.yml</CODE><SPAN>&nbsp;</SPAN>is the single source of environment config.</STRONG><SPAN>&nbsp;</SPAN>Catalog and schema are declared once per target. prebuild_notebook.py reads them and stamps the Genie Agent JSON into build/ before each deploy. For the metric view, catalog and schema are injected at runtime as job parameters — no hardcoded values in committed files, no manual reset when switching between dev and prod.</P> <P class="code-line" data-line="82"><STRONG>The separation is clean.</STRONG><SPAN>&nbsp;</SPAN>The metric view (semantic layer) and the agent config (behavior layer) are in separate files with separate edit workflows. Changing a synonym does not require touching the agent instructions. Adding a benchmark question does not require regenerating SQL.</P> <H2 id="example-dataset" class="code-line" dir="auto" data-line="84">Example dataset</H2> <P class="code-line" data-line="85">The walkthrough below uses<SPAN>&nbsp;</SPAN><STRONG><CODE>samples.tpcds_sf1</CODE></STRONG>, a TPC-DS retail benchmark dataset that comes pre-loaded in every Databricks workspace. It contains three sales fact tables (<CODE>store_sales</CODE>,<SPAN>&nbsp;</SPAN><CODE>catalog_sales</CODE>,<SPAN>&nbsp;</SPAN><CODE>web_sales</CODE>) plus standard dimension tables (<CODE>date_dim</CODE>,<SPAN>&nbsp;</SPAN><CODE>item</CODE>,<SPAN>&nbsp;</SPAN><CODE>customer</CODE>). No data setup is required. You can follow every step using this dataset as-is.</P> <P class="code-line" data-line="87">The same pattern applies to your own data: replace<SPAN>&nbsp;</SPAN><CODE>samples.tpcds_sf1</CODE><SPAN>&nbsp;</SPAN>with your source tables, and replace<SPAN>&nbsp;</SPAN><CODE>&lt;your_catalog&gt;.&lt;your_schema&gt;</CODE><SPAN>&nbsp;</SPAN>with the catalog and schema where you want the base view and metric view to live.</P> <H2 id="prerequisites" class="code-line" dir="auto" data-line="89">Prerequisites</H2> <H3 id="1-clone-the-repo" class="code-line" dir="auto" data-line="91">1. Clone the repo</H3> <LI-CODE lang="markup">git clone https://github.com/databricks-solutions/databricks-blogposts.git cd 2026-08-genie-agent-cicd</LI-CODE> <H3 id="2-install-the-databricks-cli" class="code-line" dir="auto" data-line="97">2. Install the Databricks CLI</H3> <P class="code-line" data-line="98">The bundle commands require Databricks CLI v1.10 or later.<SPAN>&nbsp;</SPAN><STRONG>macOS:</STRONG></P> <LI-CODE lang="markup">brew tap databricks/tap brew install databricks</LI-CODE> <P class="code-line" data-line="104"><STRONG>Linux / macOS (curl):</STRONG></P> <LI-CODE lang="markup">curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh</LI-CODE> <P class="code-line" data-line="108"><STRONG>Windows:</STRONG></P> <LI-CODE lang="markup">winget install Databricks.DatabricksCLI</LI-CODE> <P class="code-line" data-line="112">Verify the installation:</P> <LI-CODE lang="markup">databricks --version</LI-CODE> <H3 id="3-configure-workspace-profiles" class="code-line" dir="auto" data-line="117">3. Configure workspace profiles</H3> <P class="code-line" data-line="118">Each target in<SPAN>&nbsp;</SPAN><CODE>databricks.yml</CODE><SPAN>&nbsp;</SPAN>maps to a named profile in<SPAN>&nbsp;</SPAN><CODE>~/.databrickscfg</CODE>. Set up one profile per workspace using OAuth (recommended):</P> <LI-CODE lang="markup"># Dev workspace databricks auth login --host https://&lt;dev-workspace&gt;.cloud.databricks.com --profile DEFAULT # Prod workspace databricks auth login --host https://&lt;prod-workspace&gt;.cloud.databricks.com --profile PROD</LI-CODE> <P class="code-line" data-line="125">Both commands open a browser for OAuth login and write the credentials to<SPAN>&nbsp;</SPAN><CODE>~/.databrickscfg</CODE></P> <LI-CODE lang="markup">[DEFAULT] host = https://&lt;dev-workspace&gt;.cloud.databricks.com [PROD] host = https://&lt;prod-workspace&gt;.cloud.databricks.com</LI-CODE> <P class="code-line" data-line="132">Then update<SPAN>&nbsp;</SPAN><CODE>databricks.yml</CODE><SPAN>&nbsp;</SPAN>to reference the correct profile per target:</P> <LI-CODE lang="markup">targets: dev: workspace: profile: DEFAULT variables: catalog: dev_catalog schema: genie prod: workspace: profile: PROD variables: catalog: prod_catalog schema: genie</LI-CODE> <H2 id="step-1-define-your-uc-metric-view-in-yaml" class="code-line" dir="auto" data-line="150">Step 1: Define your UC metric view in YAML</H2> <P class="code-line" data-line="151">A Unity Catalog metric view is a governed semantic layer — a special view type that separates how metrics are defined from how they're queried. Unlike a regular view that pre-aggregates at a fixed grain, a metric view lets callers choose which dimensions to group by at query time while guaranteeing the aggregation math is always correct. This makes it the ideal backing store for a Genie Agent: the agent uses your pre-vetted measure expressions, and the synonyms you define map natural-language terms like “revenue” or “sales” to the right SQL.</P> <P class="code-line" data-line="153">You create a metric view with the<SPAN>&nbsp;</SPAN><STRONG>WITH METRICS LANGUAGE YAML</STRONG><SPAN>&nbsp;</SPAN>DDL — the YAML spec is embedded inline between $$ markers. The<SPAN>&nbsp;</SPAN><STRONG>metric view YAML</STRONG><SPAN>&nbsp;</SPAN>defines dimensions, measures, and their configurations (synonyms, etc.). See the<SPAN>&nbsp;</SPAN><CODE>src/metric-view.yaml</CODE><SPAN>&nbsp;</SPAN>for detail.</P> <LI-CODE lang="markup">CREATE OR REPLACE VIEW &lt;your_catalog&gt;.&lt;your_schema&gt;.tpcds_retail_sales_metrics WITH METRICS LANGUAGE YAML AS $$ version: 1.1 source: | -- inline UNION ALL of store_sales, catalog_sales, web_sales SELECT ... FROM samples.tpcds_sf1.store_sales UNION ALL ... dimensions: - name: Channel expr: source.channel synonyms: [sales channel, division] measures: - name: Total Sales expr: SUM(source.net_paid) synonyms: [revenue, net sales, sales] $$</LI-CODE> <P class="code-line" data-line="172">Querying a metric view requires wrapping every measure in MEASURE():</P> <LI-CODE lang="markup">SELECT Channel, MEASURE(`Total Sales`) AS revenue FROM &lt;your_catalog&gt;.&lt;your_schema&gt;.tpcds_retail_metrics GROUP BY ALL</LI-CODE> <P class="code-line" data-line="179">Source files use<SPAN>&nbsp;</SPAN><CODE>${catalog}</CODE><SPAN>&nbsp;</SPAN>and<SPAN>&nbsp;</SPAN><CODE>${schema}</CODE><SPAN>&nbsp;</SPAN>as placeholders, no environment-specific values are hardcoded. Then<SPAN>&nbsp;</SPAN><CODE>metric_view.job.yml</CODE><SPAN>&nbsp;</SPAN>injects<SPAN>&nbsp;</SPAN><CODE>catalog</CODE><SPAN>&nbsp;</SPAN>and<SPAN>&nbsp;</SPAN><CODE>schema</CODE><SPAN>&nbsp;</SPAN>as job parameters at run time via DABs variable substitution.</P> <H3 id="note-understand-the-multi-fact-pattern" class="code-line" dir="auto" data-line="181">Note: Understand the multi-fact pattern</H3> <P class="code-line" data-line="182">TPC-DS contains three sales fact tables — store_sales, catalog_sales, and web_sales — all representing the same business event: a sale line. When the analysis treats them as one unified sales process, normalize them with UNION ALL.</P> <P class="code-line" data-line="184">The metric view's source: field accepts an inline SQL query, so the UNION ALL lives directly in the YAML — no pre-built base view needed. Each branch is explicitly enumerated (no SELECT *), date roles and customer roles are declared once, and a channel column is added to preserve provenance.</P> <P class="code-line" data-line="186">Key design decisions in the union:</P> <UL class="code-line" dir="auto" data-line="187"> <LI class="code-line" dir="auto" data-line="187">Use UNION ALL, not UNION — two identical-looking lines can be separate real events.</LI> <LI class="code-line" dir="auto" data-line="188">Enumerate every column explicitly — union alignment is positional; implicit projections hide semantic mapping errors.</LI> <LI class="code-line" dir="auto" data-line="189">Date role: sold date, not ship date — ss_sold_date_sk / cs_sold_date_sk / ws_sold_date_sk consistently; ws_ship_date_sk is excluded.</LI> <LI class="code-line" dir="auto" data-line="190">Customer role: billing customer — catalog and web use the billing customer FK, not shipping. The dimension tables (date_dim, item) join many-to-one to the normalized union source, declared in the metric view's joins: block with rely.at_most_one_match: true. Databricks evaluates only the joins a query actually needs — no pre-flattening required.</LI> </UL> <H2 id="step-2-export-your-genie-agent-from-the-workspace" class="code-line" dir="auto" data-line="193">Step 2: Export your Genie Agent from the workspace</H2> <P class="code-line" data-line="194">If you already have a Genie Agent configured in the UI, the CLI can export it directly into your bundle. First, find the space ID in the browser URL:</P> <LI-CODE lang="markup">https://&lt;workspace&gt;.cloud.databricks.com/genie/spaces/&lt;SPACE_ID&gt;</LI-CODE> <P class="code-line" data-line="198">Then run:</P> <LI-CODE lang="markup">databricks bundle generate genie-space \ --existing-id &lt;SPACE_ID&gt; \ --key tpcds_retail</LI-CODE> <P class="code-line" data-line="204">The<SPAN>&nbsp;</SPAN><CODE>--key</CODE><SPAN>&nbsp;</SPAN>value (<CODE>tpcds_retail</CODE>) becomes the resource key in the generated YAML and the identifier used when re-exporting or referencing the resource later.</P> <P class="code-line" data-line="206">This generates two files:</P> <UL class="code-line" dir="auto" data-line="207"> <LI class="code-line" dir="auto" data-line="207"><CODE>src/tpcds_retail.geniespace.json</CODE><SPAN>&nbsp;</SPAN>— the full agent configuration</LI> <LI class="code-line" dir="auto" data-line="208"><CODE>resources/tpcds_retail.genie_space.yml</CODE><SPAN>&nbsp;</SPAN>— the DABs resource definition After the initial export,<SPAN>&nbsp;</SPAN><CODE>src/tpcds_retail.geniespace.json</CODE><SPAN>&nbsp;</SPAN>becomes your source of truth — edit it directly for subsequent changes rather than re-running generate.</LI> </UL> <P class="code-line" data-line="211">The<SPAN>&nbsp;</SPAN><CODE>.geniespace.json</CODE><SPAN>&nbsp;</SPAN>file is structured JSON, not a raw blob, so every section is directly editable:</P> <LI-CODE lang="markup">{ "version": 2, "instructions": { "text_instructions": [ { "id": "...", "content": ["# Agent Instructions\r\n", "..."] } ], "sql_snippets": { "filters": [...], "measures": [...], "expressions": [...] }, "example_question_sqls": [...] }, "benchmarks": { "questions": [...] }, "data_sources": { "tables": [ { "identifier": "...", "column_configs": [...] } ] } } </LI-CODE> <H3 id="managing-multiple-genie-agents" class="code-line" dir="auto" data-line="244">Managing multiple Genie Agents</H3> <P class="code-line" data-line="245">Each agent uses its own<SPAN>&nbsp;</SPAN><CODE>--key</CODE>, so multiple agents coexist in the same bundle without conflict:</P> <LI-CODE lang="markup">databricks bundle generate genie-space \ --existing-id &lt;SPACE_ID_B&gt; \ --key finance_agent</LI-CODE> <P class="code-line" data-line="251">Add the new resource to<SPAN>&nbsp;</SPAN><CODE>databricks.yml</CODE>:</P> <LI-CODE lang="markup">include: - resources/metric_view.job.yml - resources/tpcds_retail.genie_space.yml - resources/finance_agent.genie_space.yml</LI-CODE> <P class="code-line" data-line="258">Each agent's files are completely independent —<SPAN>&nbsp;</SPAN><CODE>src/finance_agent.geniespace.json</CODE><SPAN>&nbsp;</SPAN>and<SPAN>&nbsp;</SPAN><CODE>resources/finance_agent.genie_space.yml</CODE>.</P> <H2 id="step-3-configure-the-bundle-for-multiple-environments" class="code-line" dir="auto" data-line="260">Step 3: Configure the bundle for multiple environments</H2> <P class="code-line" data-line="261"><CODE>databricks.yml</CODE><SPAN>&nbsp;</SPAN>defines targets for each environment. A single<SPAN>&nbsp;</SPAN><CODE>--target</CODE><SPAN>&nbsp;</SPAN>flag promotes the exact same configuration to a different workspace with a different catalog.</P> <P class="code-line" data-line="263">The<SPAN>&nbsp;</SPAN><CODE>warehouse_id</CODE><SPAN>&nbsp;</SPAN>variable is declared at the top level with no default — each target sets its own lookup by warehouse name, which resolves against that target's workspace at deploy time:</P> <LI-CODE lang="markup">bundle: name: genie_agent_cicd engine: direct # required for genie_spaces variables: warehouse_id: description: SQL warehouse used to create the metric view and Genie Agent. targets: dev: default: true mode: development workspace: profile: DEFAULT variables: catalog: dev_catalog schema: genie warehouse_id: lookup: warehouse: Serverless Starter Warehouse prod: mode: production workspace: profile: PROD root_path: /Workspace/Users/&lt;user&gt;@databricks.com/.bundle/${bundle.name}/${bundle.target} variables: catalog: prod_catalog schema: genie warehouse_id: lookup: warehouse: &lt;prod_warehouse_name&gt;</LI-CODE> <H2 id="step-4-deploy" class="code-line" dir="auto" data-line="297">Step 4: Deploy</H2> <H3 id="option-a--local-cli-laptop" class="code-line" dir="auto" data-line="299">Option A — Local CLI (laptop):</H3> <P class="code-line" data-line="300">Generate build/ for dev and deploy</P> <LI-CODE lang="markup"># The prebuild step substitutes ${catalog}/${schema} into the Genie Agent JSON. It must run before bundle deploy. python3 prebuild_notebook.py --target dev databricks bundle deploy --target dev databricks bundle run metric_view --target dev # Promote to prod — prebuild stamps prod catalog/schema into build/ first python3 prebuild_notebook.py --target prod python3 prebuild_notebook.py --verify prod # CI guard: exits non-zero on mismatch databricks bundle deploy --target prod databricks bundle run metric_view --target prod </LI-CODE> <H3 id="option-b--deploying-from-the-databricks-workspace-ui" class="code-line" dir="auto" data-line="315">Option B — Deploying from the Databricks workspace UI</H3> <P class="code-line" data-line="316">If you don't want to install the CLI locally, Databricks supports deploying bundles directly from the workspace. This is especially useful for team members who prefer a UI-driven workflow or don't have a local development environment set up.</P> <P class="code-line" data-line="318"><STRONG>Prerequisites:</STRONG></P> <UL class="code-line" dir="auto" data-line="319"> <LI class="code-line" dir="auto" data-line="319">Workspace files must be enabled</LI> <LI class="code-line" dir="auto" data-line="320">The bundle must be cloned as a Git folder in the workspace (via Workspace &gt; Git folders &gt; Clone)</LI> <LI class="code-line" dir="auto" data-line="321">Serverless compute must be enabled</LI> </UL> <P class="code-line" data-line="323"><STRONG>Workflow:</STRONG></P> <OL class="code-line" dir="auto" data-line="324"> <LI class="code-line" dir="auto" data-line="324">Clone the repo into your workspace as a Git folder</LI> <LI class="code-line" dir="auto" data-line="325">Open the bundle's Git folder — Databricks automatically detects databricks.yml and shows a bundle management UI</LI> <LI class="code-line" dir="auto" data-line="326">Select the target (dev or prod) from the dropdown</LI> <LI class="code-line" dir="auto" data-line="327">Run prebuild_notebook as a notebook in the workspace (set the target widget and run all cells) to generate<SPAN>&nbsp;</SPAN><CODE>build/</CODE>. It resolves paths from the notebook's workspace location. That's it. The Genie Agent and metric view now live in the target workspace. Because<SPAN>&nbsp;</SPAN><CODE>prebuild_notebook.py</CODE><SPAN>&nbsp;</SPAN>writes to<SPAN>&nbsp;</SPAN><CODE>build/</CODE><SPAN>&nbsp;</SPAN>each time, there's no risk of committing environment-specific values or having to manually reset between targets.</LI> <LI class="code-line" dir="auto" data-line="328">Click Deploy to deploy the bundle to the selected target. Click Run next to metric_view to apply the metric view DDL</LI> </OL> <P><span class="lia-inline-image-display-wrapper lia-image-align-center" image-alt="dab-from-workspace.png" style="width: 999px;"><img src="https://community.databricks.com/t5/image/serverpage/image-id/30234i9135DA173197F75B/image-size/large?v=v2&amp;px=999" role="button" title="dab-from-workspace.png" alt="dab-from-workspace.png" /></span></P> <P class="code-line" data-line="332"><STRONG>Limitations:</STRONG></P> <UL class="code-line" dir="auto" data-line="333"> <LI class="code-line" dir="auto" data-line="333">Cross-workspace deployment (e.g., promoting from dev to prod in a different workspace) is not available from the UI editor — use the CLI or a CI/CD pipeline for cross-workspace promotion</LI> <LI class="code-line" dir="auto" data-line="334">Python for DABs is not supported in workspace mode</LI> <LI class="code-line" dir="auto" data-line="335">Bundles inherit permissions from their parent Git folder.</LI> </UL> <P class="code-line" data-line="337">The workspace UI is a good fit for day-to-day iteration within a single environment. For multi-environment promotion and CI/CD pipelines, the CLI path remains the recommended approach.</P> <H2 id="iterating-on-your-genie-agent" class="code-line" dir="auto" data-line="339">Iterating on Your Genie Agent</H2> <H3 id="updating-the-genie-agent-instructions" class="code-line" dir="auto" data-line="341">Updating the Genie Agent instructions</H3> <P class="code-line" data-line="342">Edit<SPAN>&nbsp;</SPAN><CODE>src/tpcds_retail.geniespace.json</CODE><SPAN>&nbsp;</SPAN>— for example, to add a new SQL filter snippet (use<SPAN>&nbsp;</SPAN><CODE>${catalog}.${schema}</CODE><SPAN>&nbsp;</SPAN>for any table references):</P> <LI-CODE lang="markup">"sql_snippets": { "filters": [ { "id": "...", "display_name": "Store channel only", "sql": ["`channel` = 'Store'"], "synonyms": ["in-store", "brick and mortar"] } ] }</LI-CODE> <P class="code-line" data-line="355">Then:</P> <LI-CODE lang="markup">python3 prebuild_notebook.py --target dev databricks bundle deploy</LI-CODE> <H3 id="updating-a-dimension-or-measure-in-metric-view" class="code-line" dir="auto" data-line="362">Updating a dimension or measure in metric view</H3> <P class="code-line" data-line="363">Edit src/metric-view.yaml, then deploy and re-run the job to apply the DDL:</P> <LI-CODE lang="markup">databricks bundle deploy databricks bundle run metric_view</LI-CODE> <H3 id="pulling-ui-changes-back-into-source-control" class="code-line" dir="auto" data-line="370">Pulling UI changes back into source control</H3> <P class="code-line" data-line="371">If someone made changes directly in the Genie UI (it happens), re-export:</P> <LI-CODE lang="markup">databricks bundle generate genie-space \ --existing-id &lt;SPACE_ID&gt; \ --key tpcds_retail</LI-CODE> <H2 id="getting-started" class="code-line" dir="auto" data-line="379">Getting started</H2> <P class="code-line" data-line="380">The full working example is available on GitHub:</P> <P class="code-line" data-line="382"><A href="https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-08-genie-agent-cicd" target="_blank" rel="noopener" data-href="https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-08-genie-agent-cicd">https://github.com/databricks-solutions/databricks-blogposts/tree/main/2026-08-genie-agent-cicd</A></P> <P class="code-line" data-line="384">It includes the TPC-DS retail sales Genie Agent and metric view as a ready-to-deploy example. Clone it, swap in your workspace and catalog, import your own Genie Agent with bundle generate genie-space, and you have a CI/CD-ready Genie Agent in minutes.</P> <P class="code-line" data-line="384">This post is also published on:&nbsp;<A href="https://anhcodes.dev/blog/genie-agent-cicd/" target="_blank" rel="noopener">https://anhcodes.dev/blog/genie-agent-cicd/</A></P> Tue, 01 Sep 2026 11:04:37 GMT anhhchu 2026-09-01T11:04:37Z https://community.databricks.com/t5/technical-blog/managing-databricks-genie-agents-as-code-with-databricks/ba-p/164697 <DIV> <DIV><SPAN>If your team is editing agent instructions directly in the Genie UI, you have no version history, no code review, and no reliable path to promote changes from dev to production. One wrong update and there's no rollback.</SPAN></DIV> <DIV><SPAN>In this post I'll show how to solve that using </SPAN><SPAN><STRONG>Declarative Automation Bundles (DAB)</STRONG></SPAN><SPAN>&nbsp;to manage a Genie Agent and its underlying Unity Catalog metric view entirely as code.</SPAN></DIV> </DIV> Tue, 01 Sep 2026 11:04:37 GMT https://community.databricks.com/t5/technical-blog/managing-databricks-genie-agents-as-code-with-databricks/ba-p/164697 anhhchu 2026-09-01T11:04:37Z