Databricks open-sources Omnigent meta-agent harness

Omnigent's central move is deceptively simple. Every coding agent today bundles a model with a particular interface, but underneath they all do the same thing: messages and files go in, text streams and tool calls come out. Omnigent standardizes that interface so harnesses become swappable ^[3]. The payoff is that you can combine multiple models, harnesses, and techniques without rewriting code, and switch between Claude Code, Codex, Pi, and your own agents with one-line changes ^[1]. The harness — historically the thing that locks you into a vendor — is demoted to a component you can hot-swap.

This is why observers reached for the Kubernetes analogy: just as Kubernetes abstracted away the underlying servers, the meta-harness layer is framed as the next evolutionary step for working with agents, eliminating the silos that today's agent harnesses create ^[4]. The strategic consequence for developers is reduced lock-in — if every harness is interchangeable, the question shifts from 'which agent do I commit to?' to 'which agent is best for this specific subtask, right now?' That reframing is the whole point, and it is what separates Omnigent from being just another IDE or coding assistant: it is an orchestration layer that sits across agents rather than a competitor to any one of them ^[1].

The most enterprise-relevant idea in Omnigent is that guardrails live at the orchestration layer, not in a prompt. Omnigent enforces stateful, contextual policies that track agent actions and enforce guardrails like cost budgets and permissions at the meta-harness layer, not via prompts ^[1]. Concretely, a team can pause an agent after every $100 of LLM spend, or require human approval before an agent runs git push once it has installed a new npm package ^[1]. Because these policies are stateful and sit outside the model, they cannot be jailbroken away by clever input the way a prompt-based rule can.

Security is handled at the same layer. Omnigent ships an OS sandbox called Omnibox that can lock down OS access and intercept or transform network requests, so a secret like a GitHub token never has to be exposed to the agent itself ^[3]. For organizations, this maps cleanly onto existing compliance instincts — community discussion framed the policy model as a separation-of-duties or SOC 2 analog and as an antidote to shadow AI inside enterprises. Pairing observable cost budgets with hard permission gates and secret-hiding sandboxes is what could make multi-agent workflows palatable to a security review, which is arguably the real unlock here rather than the raw capability.

Omnigent treats an agent session as a shared, multi-surface object rather than something trapped in one terminal. The same session is reachable from terminal, browser, and phone ^[2], and a live session can be shared by URL so teammates can review files, comment, and steer the agent together in real time ^[1]. This collapses the copy-paste workflow that developers currently use to move plans and output between, say, Codex and Claude Code — relief at exactly that pain point was a dominant theme in community reception.

The more novel consequence is structured disagreement between models. Because harnesses are interchangeable, Omnigent ships example agents that exploit it: Polly delegates work to coding sub-agents running in parallel git worktrees and routes each diff to a reviewer drawn from a different vendor than the one that wrote it, while Debby sends every question to both Claude and GPT and lets them debate. The underlying thesis — that once agents are interoperable, the obvious thing is to let them collaborate, debate, and converge on something better ^[4]— turns model diversity from a procurement headache into a quality mechanism. The open questions the community raised are real, though: cross-agent state and memory management, and how context degrades as multiple agents pass work between each other over a long session, remain unproven in an alpha release.