Databricks manages Omnigent’s server—not the machine where its agents act

Azure Databricks has documented a managed beta of Omnigent, a meta-harness that can place Claude Code, Codex, Cursor, Pi and custom agents behind a common configuration layer. The promise is portability: teams can change a model or harness while retaining prompts, tools, skills and policies. The operational catch is just as important: Databricks manages the coordinating server, while the customer still supplies the machine on which the agent executes. (Omnigent overview; quickstart)

Draw the host boundary first

The quickstart says a laptop or VM must run the Omnigent CLI and register as a host. That host determines which local files, tools and networks the agent can reach, and it is available only while the machine and the omni host process are running. Sessions are coordinated by the Azure Databricks-operated server and appear in the workspace UI, but the execution environment remains customer-controlled. (quickstart)

That split should shape deployment. A general-purpose developer laptop gives an agent the developer’s ambient access; a dedicated VM can offer a narrower toolchain, filesystem and network route. Teams should therefore choose hosts by task and data boundary rather than treating the managed server as a managed runtime.

Treat Edit as execution authority

Omnigent uses Azure Databricks workspace identity and attributes sessions and actions to that identity. Sessions are private until shared, and sharing offers Read or Edit access. Databricks warns that an editor can send messages, run shell commands, modify files on the host, invoke actions available through the Omnigent MCP server and view the owner’s other session chats. Workspace administrators do not automatically have blanket visibility into every session. (identity and access)

The practical rule is simple: Read is collaboration; Edit is delegated execution. An approval process for Edit access should look more like privileged host access than document sharing. Teams also need a separate retention and review policy for session content because administrator visibility is not automatic.

Test the beta’s governance limits

The managed beta requires the Omnigent workspace preview and a region that supports Unity Gateway. It supports built-in contextual policies but does not support custom policy functions that execute arbitrary code. Native Windows is also unavailable; Windows users must run it through WSL2. (Omnigent overview)

Databricks’ separate Smart Routing beta can select both a model and a coding harness for Omnigent tasks, including subagents. But it routes only among system.ai model services, requires the user to have access to every candidate model, and fails if any required permission is missing. Cross-harness routing requires Omnigent 0.8.0 or later. (Smart Routing)

Before rollout, test four things explicitly: a dedicated host profile, the exact capabilities granted to editors, the behavior when custom policy logic is unavailable, and routing under least-privilege model permissions. Omnigent can centralize coordination and identity; it does not erase the trust boundary around the machine that actually runs the agent.