Databricks’ agent stack now has a migration map—and Genie is the low-code destination
Knowledge Assistant, Supervisor Agent and the older agent-server path are now legacy; the replacement depends on whether a team wants low-code analytics or code-first orchestration.
Databricks has marked a broad set of earlier agent products as legacy and published an explicit replacement map. Knowledge Assistant and Supervisor Agent now point low-code builders toward Genie Agents, while code-first and multi-agent projects point toward the Agent Bricks CLI. The same page also moves developers away from the legacy agent server, custom agents on Model Serving, managed memory stores and AI Playground for new builds.[^1]
That distinction matters for data teams because this is not one product rename. It is a split between two operating models.
Low-code analytics moves toward Genie
For document-and-data assistants built without code, Databricks says to use Genie Agents. It gives the same recommendation for low-code replacements of Supervisor Agent. Teams that used a supervisor to coordinate multiple agents in code, however, are told to use Agent Bricks CLI instead.[^1]
The practical reading is that Genie becomes the managed analytics-agent surface, while custom orchestration becomes an application-development responsibility. Existing deployments are not described as immediately shut down: Databricks says legacy offerings remain documented so customers can maintain and migrate them, but explicitly says not to use them for new agents.[^1]
Code-first migration changes the deployment contract
Agent Bricks CLI is currently beta. It scaffolds LangGraph or OpenAI Agents SDK projects, runs them locally, and deploys them to Databricks Agent Runtime. A declarative agent.toml file becomes the source of truth for tool bindings, memory, sessions and tracing; deployment provisions those resources and grants the agent service principal access.[^2]
For existing projects, the CLI can prepare migration instructions without rewriting application code or creating workspace resources. Databricks also warns that switching to managed session storage does not move existing conversation history, so teams must make an explicit retention or migration decision.[^2]
The newer path also changes how analytics tools are attached. Agent Bricks can bind managed MCP services for Genie One or DBSQL, and the default authorization model runs tools with the permissions of the requesting user; builders can instead choose the application service principal.[^2] That is a meaningful review point for NL2SQL deployments because a migration can alter not only hosting but also whose identity reaches the warehouse.
Treat “legacy” as a planning trigger, not an outage notice
Databricks’ October release notes date the Knowledge Assistant and Supervisor Agent status change to October 12 and direct new no-code projects to Genie Agents and new coded projects to Agent Bricks CLI.[^3] The vendor has not attached a shutdown date on the legacy-offerings page.[^1]
Teams should therefore inventory which legacy surface they use, select the corresponding replacement, test identity and tool permissions, and decide what happens to historical sessions before treating the migration as complete. The immediate risk is not that an old agent stops today; it is that a new project starts on a path Databricks already says is no longer best practice.
[^1]: Databricks — Legacy agent offerings [^2]: Databricks — Agent Bricks CLI [^3]: Databricks — October 2026 product release notes
sources
- Databricks — Legacy agent offeringsdocs.databricks.com
- Databricks — Agent Bricks CLIdocs.databricks.com
- Databricks — October 2026 product release notesdocs.databricks.com
comments · 0