What's the difference between open source Omnigent and managed Omnigent on Databricks?

Summary

• Omnigent is an open-source meta-harness: a layer that sits above coding agents such as Claude Code and Codex, plus agents you write yourself, and makes them work together. The open-source project is Apache 2.0 licensed, and its README lists "Status: alpha".
• With open-source Omnigent you run the server yourself, choose how users sign in (built-in accounts, OIDC single sign-on or header-based auth), and configure your own model credentials.
• Databricks provides "a fully managed version of Omnigent": a Databricks-operated server that integrates with your workspace's identity provider, model access through the Foundation Model APIs and Unity Gateway, and Databricks Sandboxes. Omnigent on Databricks is in Beta.
• Policy support differs. Omnigent on Databricks supports built-in contextual policies and custom policies written in CEL, but not custom Python policies. The open-source docs show custom policy functions written in Python.

What's the difference between open source Omnigent and managed Omnigent on Databricks?

Open-source Omnigent is a project you self-host. Omnigent on Databricks is a managed version: Databricks operates the server, you sign in with your workspace identity, and model access and sandboxes come from Databricks. Choose by whether you want to operate the server yourself or use one that Databricks runs.

What is Omnigent?

The Databricks launch blog describes Omnigent as "a meta-harness that sits above the agents you already use (Claude Code, Codex, Pi, or custom agents) and makes them interoperable parts of a richer system". You define an agent in a short YAML file, then swap one line to change its harness or model while your tools, prompts, skills and policies stay the same. It focuses on three things:

• Composition: combine multiple models, harnesses and techniques without rewriting code.
• Control: stateful, contextual policies that track agent actions and enforce guardrails like cost budgets and permissions at the meta-harness layer, not via prompts.
• Collaboration: share live agent sessions by URL with full history, so teammates can review, comment and steer together in real time.

How do open source Omnigent and Omnigent on Databricks differ?

Dimension	Open-source Omnigent	Omnigent on Databricks
Stage	README: "Status: alpha"	"Omnigent is in Beta"
License and source	Apache 2.0, source on GitHub	A fully managed version of Omnigent, with a Databricks-operated server
Who runs the server	You deploy it, for example with the Docker setup that starts the Omnigent server and Postgres	Databricks
Sign-in	Built-in accounts, OIDC single sign-on, or header-based auth behind an SSO proxy	Your Databricks workspace identity
Model access	API keys, subscriptions, gateways, or a Databricks workspace's Foundation Model API	Sandbox host: models route through your workspace's Foundation Model APIs over Unity Gateway, with no API keys to manage. Your own machine: choose Databricks, or provide your own API key, subscription or gateway
Execution host	Your machine, or a cloud sandbox host from a supported provider	A Databricks Sandbox (Beta), or your own laptop or VM registered as a host
Custom policies	Policy functions written in Python	Policies written in CEL. Custom Python policies are not supported
Requirements	A server you deploy	The Omnigent preview enabled for your workspace, in a region that supports Unity Gateway

How does Databricks approach managed Omnigent?

Databricks provides "a fully managed version of Omnigent", including a Databricks-operated Omnigent server that integrates with your workspace's identity provider, model access through the Foundation Model APIs and Unity Gateway, and Databricks Sandboxes. You sign in with your Databricks workspace identity either way, because both hosts run through the same managed server.
When you start a session you choose a host. A Databricks Sandbox, which is in Beta, is provisioned and run by Databricks in the cloud. It keeps running when your laptop is off, and your credentials never leave Databricks. Or you install the Omnigent CLI and register your laptop or a VM as a host, which is only available while that machine is powered on. Sessions appear in the <workspace-url>/omnigent UI and can be shared with other workspace users regardless of which host runs them.
Omnigent on Databricks requires the Omnigent preview enabled for your workspace and a workspace in a region that supports Unity Gateway. Sandbox sessions also need a region that supports Databricks Sandbox and the Sandbox preview. See the Omnigent on Databricks docs, the quickstart and the open-source Omnigent documentation.

FAQs

Is managed Omnigent a different product from open-source Omnigent?

Databricks describes it as "a fully managed version of Omnigent" and says "Omnigent is an open source project", pointing to the open-source documentation for concepts, harnesses, custom agents, interfaces, policies and sandboxes. What Databricks adds is the operated server, workspace sign-in, Foundation Model APIs through Unity Gateway and Databricks Sandboxes.

Can I still use my own machine with managed Omnigent?

Yes. You install the Omnigent CLI and register your laptop or a VM as a host, and you still sign in with your workspace identity. The host is only available while the machine is powered on.

Do I need to manage model API keys on Databricks?

Not on a Databricks Sandbox host, where models route through your workspace's Foundation Model APIs over Unity Gateway automatically. On your own machine you can choose Databricks or provide your own API key, subscription or gateway. With open-source Omnigent you configure credentials yourself: API keys, subscriptions, gateways, or a Databricks workspace.

What are the main limits of managed Omnigent today?

It's in Beta, and it needs the Omnigent preview plus a Unity Gateway region. Custom Python policies aren't supported. A Databricks Sandbox host routes model access through Unity Gateway, so you can't bring your own model API keys for it. Databricks Sandbox is also in Beta and does not integrate with serverless egress controls. The CLI install script supports only macOS and Linux, so on Windows use the uv install.