Critical Genie Agents Issue – Catalog Rename Causes Tables and Joins Loss

[harisrinivasay]

I have identified a serious issue in Genie Agents that requires attention from the Databricks Product Team.

When a catalog is renamed, the tables that were previously configured and used within the Genie Agent disappear unexpectedly. After manually re-adding the missing tables, the issue reoccurs when the Genie Agent is cloned and additional tables are added. As a result, previously configured tables are lost again.

This issue has already occurred twice and required significant effort and time to correct, impacting productivity and maintenance of Genie Spaces.

Request to Databricks Product Team:

• Please investigate and fix this behavior so that catalog renames and Genie Space cloning operations preserve existing table configurations.
• Ensure that table references are automatically updated when catalog names change, rather than removing them from the Genie configuration.
• Consider providing a feature that allows users to easily replace an existing table with an alternative table without losing associated configurations, instructions, and metadata.
• Add validation and warning mechanisms before any operation that could result in table removal from a Genie Space.

This enhancement would significantly improve Genie Agent stability, maintainability, and overall user experience.

[ThomazNeto · Accepted solution]

Hey harisrinivasay,

I've hit the same class of pain, and your report lines up with how Genie stores its config — so a quick note on the likely mechanism plus what's actually worked as a workaround, since a forum post alone probably won't get this fixed.

Likely mechanism: Genie Agents (the July 2026 rename of Genie Spaces) reference their tables by fully-qualified name — catalog.schema.table — not by an immutable catalog ID. This is the same behavior seen across the Genie/dashboard family, where FQNs are effectively hardcoded. So when you rename the catalog, the old names stop resolving and the configured tables (and any join relationships in the knowledge store keyed to those names) get dropped rather than rewritten. The clone-then-add-tables path re-triggers that reconciliation, which is why it recurs. That matches everything you described.

What's actually reduced the pain for me in the meantime:

1. Treat catalog names as immutable once a Genie Agent depends on them. If renames are driven by env promotion (dev/stg/prod), a stable serving layer beats renaming.

2. Point Genie at a stable set of views in a dedicated serving schema/catalog whose names never change. The views repoint to the underlying tables, so a rename underneath doesn't touch the names Genie has stored. (Architectural workaround, not an official recommendation — but it removes the trigger.)

[harisrinivasay]

Make sense, Thank you.