Databricks open-sources Omnigent, a meta-harness for AI coding agents

Most AI agent stories focus on which model is best. The one Databricks published on June 13 focuses on the layer above the model: Omnigent, an open source meta-harness that wraps Claude Code, Codex, Pi, and custom coding agents, exposing the combined session to your terminal, browser, desktop, and phone with one policy set, one cost meter, and one shared URL.

If you have not had to coordinate four coding agents at once, that may sound like a niche problem. If you have, you already know why this is the right next layer to build.

The blog post, co-authored by Databricks chief architect and Apache Spark creator Matei Zaharia, with Kasey Uhlenhuth, makes the case in plain language. Agent harnesses made models swappable, the authors write. The next layer of abstraction is the meta-harness, the layer above every harness where composition, control, and collaboration live. Omnigent is their open source answer to that problem, released under Apache 2.0.

This is not a niche project. The repository shipped with 781 stars in its first weekend, 97 forks, and 25 commits. The TypeScript codebase is mostly server and web app glue around a Python 3.12+ runtime, and Databricks' official announcement positions the project as the first serious attempt to standardize the layer between a developer and the dozens of agent harnesses that have shipped in the last eighteen months.

Why a meta-harness like Omnigent matters now

To understand what Omnigent is solving, it helps to be clear about what an agent harness already is. When you run Claude Code in a terminal, you are using a harness, a thin program that talks to a model, manages tool calls, tracks files, and presents a chat-style interface. Codex from OpenAI is a different harness. Pi, from the open source community, is a third. Each has its own command set, its own way of handling long sessions, its own rules for tool use, and its own way of showing the user what is happening.

That worked fine when most developers used one agent at a time. It stopped working once teams started stacking agents the way they stack tabs in a browser. A typical engineering team in mid-2026 has Claude Code open in one terminal, Codex in another, a Gemini search agent in a third, and a custom internal agent running on a sidecar process for incident response. The user is the integration layer, copy-pasting snippets of output between windows, re-typing context into each one, and losing hours of working memory to tab switching.

Databricks says its 5,000-person engineering team hit this wall early and built thousands of customer agents that hit the same wall. The team concluded that the frontier of agent engineering is moving up a level. The best results no longer come from a single model in a single harness. They come from patterns that span harnesses.

Databricks cites three examples. Harvey, the legal AI company, beat a frontier model on both quality and cost by giving an open source worker model a frontier advisor model that it can call on demand. Anthropic built its research product as a lead agent that orchestrates parallel subagents. Databricks' own Genie product uses different LLMs for planning, search, and code generation in the same workflow.

These patterns all span multiple harnesses, models, and people. Each individual harness only understands its own sessions. To compose, govern, and collaborate across them, you need a layer above the harness. That is what Omnigent aims to be.

Inside the open source Omnigent feature set

Omnigent introduces a common interface above command-line coding agents and agent SDKs, then focuses on the problems that fall between harnesses. The team's key insight is that however each harness calls into its LLM internally, the interface to users is the same: messages and files in, text streams and tool calls out. Once you accept that, you can wrap each harness in a uniform API and start composing them.

The current version of Omnigent adds several features that come from this insight.

Real-time collaboration. You can invite other people to view your agent session, comment on files in the agent's workspace, or send commands. The session and its working directory become the main place you collaborate, instead of a Slack thread that is already out of date.

Multiple interfaces to the same session. Once you connect an agent like Claude Code to the Omnigent server, you can access the same session on the web, in a mobile interface, in a native Mac OS app, and through APIs. Messages, subagents, terminals, and files stay in sync.

Cloud execution. You can launch an agent on your own machine or on a hosted sandbox provider like Modal or Daytona, for safe collaboration in a hermetic environment. The README calls these managed hosts and lists more providers as coming soon.

Contextual security policies. Omnigent's policies go beyond the simple allow or deny lists of coding agents. They track dynamic state about each session and make decisions based on that state. The example Databricks gives in the blog is the rule "after an agent downloads a new package from npm, it should require human approval to git push." Another is "an agent can only write to docs it created, not to any doc." These are policies that respond to the runtime, not to a static prompt.

Cost policies. Omnigent tracks each session's LLM cost dynamically. You can ask it to pause an agent and request human approval to continue after every $100 it spends. This is the kind of guardrail that most teams want but few harnesses expose cleanly.

Strong OS sandbox. Omnigent includes a flexible OS sandbox from Databricks' security team that can lock down OS access and intercept and transform network requests. The example is letting an agent never see your GitHub security token, then injecting the token only in the egress proxy on approved requests.

Multi-harness authoring. You can specify a custom agent as a YAML file and port it across harnesses with a one-line change, or combine subagents using different harnesses in the same agent. The dream of write-once-run-anywhere for agents is closer to real in this design.

The roadmap section of the announcement lists more ideas, including automatic prompt optimization at the meta-harness level using GEPA, code-based introspection inside agents similar to MemEx and RLM, and an Omnigent Server MCP so agents can work across your sessions. Databricks is also making Omnigent easy to deploy on Fly.io, Railway, Modal, and Daytona sandboxes, and welcomes patches for more integrations.

Beyond the feature list, the repository ships with two example agents that show what the layer is good for in practice.

The repository ships with two example agents that show what the layer is good for.

Polly is a multi-agent coding orchestrator. It writes no code itself. It plans, then delegates work to coding subagents running in parallel git worktrees. Each diff is routed to a reviewer from a different vendor than the one that wrote the change. A human merges the result. The pattern generalizes: a frontier advisor model can guide a cheaper open source worker, a lead agent can orchestrate parallel subagents, and different LLMs can handle planning, search, and code generation in one flow.

Debby is a brainstorming partner with two heads. One head is Claude, the other is a GPT-class model. Every question goes to both, with answers shown side by side. Typing a /debate command makes the two heads critique each other before converging. The point is not that two heads are better than one. The point is that the harness layer no longer needs to know which head is which.

These two examples are useful because they make the meta-harness concept concrete. Without Omnigent, you would write a Polly-shaped workflow by gluing Claude Code, Codex, and Pi into a Python script. With Omnigent, you describe the workflow in YAML and let the server handle the orchestration, the policies, the cost tracking, and the live sharing URL.

For engineering organizations that have already adopted coding agents, the value proposition is operational. The cost of running an agent fleet has been hard to control because the controls live inside each harness. A meta-harness pulls the controls up a layer and gives you a single place to set policies. The cost of a runaway agent no longer depends on which harness it ran in. The audit trail for a code change no longer depends on which tab the change came from.

For teams that have not yet adopted coding agents at scale, the value proposition is more subtle. Omnigent is, in effect, a bet that the future of AI assisted software development is multi-agent and multi-harness, not single-agent. The team's argument is that the best results come from composing strengths, and the layer where you compose should be separate from the layer where you prompt a single model. If that bet is right, then the next two years of tooling will see most of the value move up from the harness to the meta-harness, the same way most of the value in cloud moved from a single server to a fleet manager like Kubernetes or Terraform.

The signal from the broader market is consistent with that bet. Anthropic's research product, Harvey's worker-plus-advisor pattern, and Databricks' own Genie all point in the same direction. Multi-agent orchestration is already where the strongest results come from. Omnigent is the first open source attempt to put that orchestration behind a single API.

Where the open meta-harness has to prove itself

Omnigent is in alpha. The README badge is orange. There is no version 1.0 promise here, and there should not be. The interesting questions at this stage are about what is not yet in the box.

The first is policy expressiveness. The current policy language is intentionally narrow, with a few example rules. The real test will be whether teams can express the policies they actually want, such as "an agent can edit a file in src/ but only after a reviewer in the same session has approved the change," in a way that survives a production environment.

The second is the model provider matrix. Omnigent supports first-party API keys, ChatGPT and Claude subscriptions, and any compatible gateway. The list of supported harnesses is small today: Claude Code, Codex, Pi, and custom agents defined in YAML. Adding more harnesses is one of the easier parts of the project, since the wrapper interface is uniform, but it is still real work.

The third is governance. A meta-harness makes governance easier in some ways and harder in others. It is easier because the policy layer is unified. It is harder because now there is one more piece of infrastructure that holds the keys to every model credential, every git token, and every shared session. The Omnibox sandbox and the egress proxy design show the team is aware of this, but the security review for a meta-harness in a regulated environment will be substantial.

The fourth is what happens if a single vendor captures the meta-harness layer. If one company's meta-harness becomes the default way developers talk to multiple coding agents, that company ends up with a lot of control over how agents are composed, governed, and paid for. The Apache 2.0 license is the right defense against that scenario, but it is not a complete one. Governance of an open source meta-harness project is a question the community will have to answer over the next year.

A reasonable first question is how this relates to the resource pages on AI coding agents we maintain. The short answer is that Omnigent does not replace Claude Code, Codex, or Pi. It sits above them. If you want to pick the right primary coding agent for your team, our comparison of the best AI coding agents in 2026 is still the right starting point. Omnigent enters the picture once you have more than one of them running, and once you want to control them as a fleet rather than a collection of windows.

It also fits into a broader story we have been tracking about coding agents moving off the laptop and into managed environments. The shift from running a coding agent in a local terminal to running it in a cloud sandbox is the same shift Omnigent is making for the multi-agent case, and the patterns line up. If you are evaluating where coding work should run, our earlier coverage of Mistral moving coding agents to the cloud is a useful counterpoint, since it shows what a single-vendor approach to the same problem looks like.

For developers who want to try Omnigent, the project README on GitHub walks through a one-line install with `uv`, sets up `tmux` if needed, and registers the CLI under two interchangeable names, `omnigent` and `omni`. A native macOS app wraps the same web UI with OS notifications and a dock badge, and a Discord is open for early users.

Three signals will tell us whether Omnigent is becoming a real standard or an interesting experiment.

The first is whether other vendors start shipping their own meta-harness, or whether Omnigent becomes the de facto one. If the major coding agent vendors start treating the meta-harness as a category and writing to Omnigent's interface, the project is on its way. If everyone ships their own private meta-harness, the open source one is in a tougher spot.

The second is whether the policy language gets traction. The first time a major enterprise publishes a real-world policy set written in Omnigent's policy format, the meta-harness idea has a concrete shape that other teams can copy. Until then, the policy story is more architectural than operational.

The third is what shows up in the GitHub issue tracker. The current open issues are about packaging, deployment, and small feature requests. If the issues shift to production-grade concerns like multi-tenant isolation, audit logging, and key management, then real teams are running it. The shift from a research project to a production project is visible in the issue tracker before it shows up in the marketing.

Omnigent is a clear bet that the next layer of value in AI development tooling is the meta-harness. Whether that bet pays off depends on whether the rest of the industry agrees that composition, control, and collaboration belong above the harness, not inside it. The Apache 2.0 release, the early repo momentum, and the Databricks engineering bench behind it give the project a real chance to set the standard. For engineering organizations that already run more than one coding agent, the project is worth a serious look this quarter.