Omnigent: Databricks' Meta-Harness for Claude Code and Codex

Every team that adopts coding agents ends up with several of them, each with its own interface, its own permission model and its own way of spending money. Swapping one for another means rewiring the controls around it, so the controls tend to stay thin: an allow list, a deny list and a hope that the prompt is followed.

At NexOps, we build AI harnesses for clients and apply the same standards to every agent: least privilege, a scoped identity and a test environment before production. Databricks has now open-sourced Omnigent, a layer that sits above the agents and carry those controls for all of them. In this post, we cover what changed, who is affected and what to do this week; sharing features and agent benchmarks are topics for a later post.

Treat Omnigent as a governed layer above your coding agents, enforce permission and cost policies outside the prompt, and pilot it in a test environment until it is generally available.

What Changed

Before you start: Omnigent is open source in alpha, the managed version in Databricks is in Beta, it needs the Omnigent preview enabled for your workspace and a workspace in a region that supports Unity Gateway. Last verified: 11 November 2026.

Databricks announced Omnigent on 13 June 2026 and describes it as "a meta-harness that sits above the agents you already use (Claude Code, Codex, Pi, or custom agents)". The launch post says it is open sourced under Apache 2.0. The documentation lists Claude Code, Codex, Cursor, Pi and agents you write yourself as supported.

The idea is a common interface above command-line agents and agent SDKs. Databricks states that you can switch between agents with one-line changes, and that live sessions can be shared through a URL so teammates can review and steer an agent together.

The part that matters for platform teams is the policy engine. Omnigent's policies go beyond the simple allow and deny rules of a coding agent. The launch post describes stateful, contextual policies that track agent actions and enforce guardrails such as cost budgets.

On 7 July 2026, Databricks described contextual policies in detail. A policy is a function that takes its old state and the new event the agent is attempting, and returns state updates and a decision. The decision can allow, deny, transform the messages or ask the user for permission.

Session state is private to each policy. The post gives tool usage counts, documents read and money spent so far as examples of what a policy can track. Enforcement works because you launch the agents through Omnigent, and the Omnigent server then intercepts their tool calls.

The documentation names two policy types for the managed version: built-in contextual policies and custom policies written in Common Expression Language (CEL). Custom Python policies are not supported.

Who Is Affected

Three groups need to pay attention this week.

Platform and security teams that run coding agents for developers. If your controls today are per-agent settings files, Omnigent offers one place to express permissions and spend limits for every agent behind it. That is a governance change, so it belongs with the people who own the Unity Catalog and gateway configuration.

Teams that already route model traffic through Unity Gateway. The documentation describes model access through Unity Gateway, so the work you did on approved models and budgets carries over. Our earlier post on governing coding agents with Unity Gateway covers that groundwork, and the same ownership model applies here.

Engineering leads who let each developer choose an agent. A layer above the agents makes the choice of agent less sticky, because the policies stay in place when the agent changes. That is useful, and it also means one policy mistake now applies to every agent.

Teams outside Databricks, or in a region without Unity Gateway, can still read the open-source project, but the managed route is not open to them yet. Teams that need Databricks Sandbox as a host should read the documented limits first: you cannot bring your own model API keys for a Databricks Sandbox host, and the documentation advises against using it in a workspace with serverless egress control enabled.

What To Do This Week

Our position follows from our delivery standards: a preview feature earns a place in production only after it has passed in a test environment, under a scoped identity, with its configuration reviewed like code. Here is the sequence we would follow.

1. Check eligibility. Confirm that your workspace region supports Unity Gateway and ask a workspace admin to enable the Omnigent preview in a test workspace only. If the answer is no, stop there and note the date for a re-check.
2. Run one agent through Omnigent in the test environment. Pick the coding agent your developers already use, launch it through Omnigent with a service identity that has no access to production data, and compare its behaviour with the same task run directly.
3. Write one permission policy and one cost policy. Start with the smallest useful rules: a restriction on where the agent may write, and a pause that asks a person to continue once a session has spent a set amount. Express them as built-in policies or CEL, and keep the definitions in version control with a reviewed pull request.
4. Test the policy by trying to break it. A policy that has only been shown to allow things is untested. Ask the agent to do something the policy must stop and confirm that it does.
5. Agree the owner and the exit. Name who approves policy changes and what happens if the preview changes or ends. Because the agent underneath stays swappable, the exit is to launch the agent directly again.

The expected result of step 4 is a refused action, a logged decision and a person asked for permission. That is the behaviour the documentation describes for policies, and your pilot confirms it in your own workspace before anything else depends on it.

A small set of suggested measures keeps the pilot honest. These are suggestions, not results.

Pitfalls

The status differs per layer. The open-source project is in alpha and the managed version is in Beta. Present it to your security team as preview technology and keep production workloads on generally available components until that changes.

Cost budgets are an example in the launch posts, not a documented built-in. The documentation page names built-in contextual policies without listing them. Check which policies your managed version ships before you plan around a spend limit, and be ready to express it in CEL.

A policy engine is not a sandbox. Omnigent applies policies by intercepting the tool calls of agents launched through it. An agent started outside it gets none of that protection, so the approved launch path still has to be enforced on developer machines.

One layer means one point of failure for your rules. A wrong policy now applies to every agent behind Omnigent. That is the reason to keep policies in version control and to test the refusal cases, not only the allowed ones.

Preview scope can change. The documentation points to the Databricks release types for what Beta means. Re-read it before each stage of the rollout and record the date you last verified it.

Key Takeaways

1. Pilot Omnigent in a test workspace, behind a service identity without production access, until the managed version is generally available.
2. Place permission and cost policies in version control and review every change like code.
3. Test each policy with an action it must refuse, and keep the logged decision as evidence.
4. Route model access through Unity Gateway, so the layer above the agents and the approved models share one owner.
5. Record the status and the date you last verified it, and re-check both before every stage of the rollout.

Our wider approach to agents, models and spend is described on our AI agents and cost and token optimisation pages.