# Databricks Omnigent: A Meta-Harness for Combining, Controlling, and Sharing AI Agents

Three teams at a client of mine standardized on three different coding agents in the same quarter, for reasons that all made sense locally: one team wanted Claude Code's editing model, one was already deep in the OpenAI ecosystem and picked Codex, one had a compliance reason to run something self-hosted. Nobody made a mistake. But by month two, nobody could tell you how much the org was spending on agent tokens in total, whether any team's agent had write access somewhere it shouldn't, or which of a dozen long-running agent sessions across three tools were still active. Every tool had its own dashboard, its own permission model, its own idea of what "done" looks like. That's the gap Databricks is aiming at with **Omnigent**, a meta-harness it open-sourced under Apache 2.0 in mid-June 2026, right before Data + AI Summit.

I wrote about [what a harness actually is](agent-harness-design) a couple of weeks before this landed — the loop, the tool schema, the permission gate, the verification step, context compaction, sub-agent orchestration, all the machinery that turns a model into a working agent inside a single tool. Omnigent is the same question asked one level up: once you have several of those harnesses running across an org, what governs all of them together?

## What problem does a meta-harness actually solve?

A **meta-harness** is a layer that sits above one or more existing agent harnesses — CLIs like Claude Code, Codex, or other coding-agent tools — and provides orchestration, policy, and visibility that spans whichever one of them happens to be running a given session. It doesn't replace the harness inside any of those tools. It wraps them.

The problem it's aimed at is not hypothetical for anyone running agents at scale in mid-2026: heterogeneous agent tooling inside one org is already the default, not the exception. Different teams pick different CLI agents for defensible reasons — model preference, existing IDE integration, a workflow that happens to fit one tool's conventions better than another's — and forcing everyone onto a single harness to get unified governance is usually not a fight worth having. What you lose by not fighting it is cost visibility (spend is scattered across whatever billing surface each vendor exposes), policy consistency (what an agent is allowed to touch is defined per-tool, if it's defined at all), and basic awareness of what's running (a long agent session in one CLI is invisible to everyone not looking at that specific terminal or dashboard). Omnigent's pitch is that you can keep the tool diversity and still get one place that sees all of it.

```mermaid
graph TD
    subgraph META["Omnigent meta-harness layer"]
        POLICY["Stateful policy enginecost budgets, permission rules"]
        SHARE["Session sharinglive URL, full history"]
        API["Common runner APIuniform session wrapper"]
    end
    subgraph HARNESSES["Underlying agent harnesses (unchanged internals)"]
        CC["Claude Codeown loop, tool schema, permission gate"]
        CX["Codexown loop, tool schema, permission gate"]
        OTHER["Other CLI / SDK agentown loop, tool schema, permission gate"]
    end
    API --> CC
    API --> CX
    API --> OTHER
    POLICY -.->|"enforced across all sessions"| CC
    POLICY -.->|"enforced across all sessions"| CX
    POLICY -.->|"enforced across all sessions"| OTHER
    SHARE -.->|"any session, any tool"| CC
    SHARE -.->|"any session, any tool"| CX
    SHARE -.->|"any session, any tool"| OTHER
```

*Omnigent doesn't touch the loop, tool schema, or permission gate inside Claude Code or Codex — that machinery is exactly what I covered as harness internals in the sibling article. It wraps each tool in a sandboxed runner behind one API, then layers cost/policy enforcement and URL-based session sharing on top, cutting across whichever harness happens to be running underneath.*

## What does "meta-harness" mean architecturally, and how is it different from a harness?

The distinction is worth being precise about, because it's easy to read "meta-harness" as marketing for "yet another agent framework." It isn't quite that. A harness like Claude Code owns the agentic loop for a single session: it decides how the model's tool-call requests get executed, what gets appended to context, when compaction kicks in, what the permission gate allows. Omnigent, by Databricks's own description, is built around a runner that wraps any of those agents in a sandboxed session with a uniform API, plus a server that provides policy enforcement and sharing on top, exposing every session over the terminal, a web app, and an API. It's tracking and gating what a session does from the outside — reading tool-call events, applying budget and permission rules against them, making the session visible and shareable — rather than reimplementing the inner loop of any given tool.

That outside-in design is the whole point, and also the whole risk. It means Omnigent's policy layer is only as good as the events the underlying harness actually surfaces to it. A harness that logs every tool call cleanly is easy to govern from above. A harness that does something opaque internally — batches several tool calls before reporting, or handles a sub-agent spawn as an implementation detail it doesn't expose — is a harder target for a layer sitting outside it to see clearly, let alone gate in real time.

### Composition, control, and collaboration — the three claimed capabilities

| Capability | What Databricks claims | What's actually new |
| --- | --- | --- |
| Composition | Combine models, harnesses, and agentic techniques without rewriting code; switch underlying agent with a one-line change | A common API surface across CLIs — genuinely useful for orchestration code, but the underlying tools still differ in permission models and context strategy underneath it |
| Control | Stateful, contextual policies enforcing cost budgets and permissions at the meta-harness layer, not via prompts | Real and previously missing: cross-tool budget enforcement without hand-aggregating spend from separate vendor dashboards |
| Collaboration | Share a live agent session via URL with full history; review and steer together | Real: a bare CLI agent has no equivalent primitive, this is a genuine UX addition |

Control is the capability I'd bet on being solid in production, because it's the narrowest claim. Enforcing a cost budget doesn't require Omnigent to understand what Claude Code and Codex are doing internally — it just needs to see token usage and tool-call events per session and cut a session off, or flag it, when it crosses a threshold. That's a metering and policy problem, not a semantic one, and it's the kind of thing a wrapper layer is well-suited to do reliably. The same logic applies to permission rules stated at the meta-harness level — "no session may write outside this directory tree regardless of which underlying tool is running it" is enforceable from outside as long as the wrapper can intercept the action before it executes, which the sandboxed-runner design suggests it can.

Collaboration is the other capability I'd trust without much hedging. Sharing a live session via URL, with full history, so a teammate can watch or take over an in-progress agent run, is a UX primitive that doesn't exist in a standalone CLI tool at all — you'd otherwise be screen-sharing a terminal or copy-pasting transcripts. That's a straightforward product feature built on top of the fact that Omnigent already owns a server-side view of every session it's running.

**Be skeptical of the composition claim specifically.** "Combine models, harnesses, and techniques without rewriting code" is the part of the pitch that's easier to market than to deliver in practice. Claude Code, Codex, and other coding-agent CLIs have genuinely different permission models, different context-compaction strategies, and different tool schemas under the hood — exactly the internals I went deep on in the harness piece. A meta-harness that wraps them behind one API has to paper over those differences somewhere, and at alpha stage, "paper over" often means "works for the common case and leaks abstraction the moment you hit a tool-specific edge case." I'd pilot this on a narrow, well-understood workflow before trusting it to swap harnesses under a production agent without anyone noticing a behavior change.

## Why open source the core and sell a managed beta?

Databricks released Omnigent's core under Apache 2.0 and is offering a managed beta on its platform for customers who want a hosted version with enterprise support. That split is a familiar shape — permissive open core, paid managed layer — and it does meaningfully lower the adoption-risk bar compared to a fully closed product: if Databricks deprioritizes it, the code doesn't disappear, and a team with the appetite could fork and maintain it themselves.

What that split doesn't answer yet is whether the open-source core stays genuinely competitive with the managed offering over time, or whether the interesting policy and collaboration features quietly migrate to the paid tier while the open core stagnates into a thin wrapper. That's not a criticism specific to Databricks — it's the standard tension in every open-core business model — but it's worth naming as an open question rather than assuming either outcome. This is alpha-stage software as of this writing; I'd revisit that judgment in six months once there's a real changelog to look at, not a launch post.

## Where this fits next to the rest of the agent-technique stack

Omnigent isn't solving the same problem as [MCP or Agent Skills](mcp-vs-agent-skills) — those are about how a single agent gets tools and capabilities, while Omnigent operates above the agent entirely, treating each agent session as the unit it governs. It's also a different animal from the loop-design evolution I covered in [the piece on AutoGPT-to-harness architectures](agent-architectures-autogpt-to-harness), which is about what happens inside one agent's reasoning loop. And it's a different kind of "run agents for a long time" problem than the [Ralph Wiggum loop](ralph-wiggum-loop-agentic-coding) pattern, which is about structuring a single agent's repeated attempts at a task rather than governing a fleet of different agents across an org.

Omnigent shipped in the same announcement window as [LTAP and Lakebase](databricks-ltap-lakebase) at Data + AI Summit 2026 — a data-platform announcement and an agent-governance announcement from the same event, aimed at different parts of the same audience. Worth knowing they're related by timing, not by architecture; there's no direct technical dependency between the two.

## What to carry away

Omnigent is a real answer to a real, increasingly common problem: heterogeneous agent tooling inside one org needs governance that doesn't force everyone onto one tool. The control and collaboration pieces — cross-tool cost budgets and policy enforcement, URL-based session sharing — are genuinely new capabilities that a standalone CLI agent doesn't provide, and they're the parts I'd expect to hold up as the project matures past alpha. The composition claim, "swap agents without rewriting code," is the one to pilot carefully rather than take at face value, because the differences between harnesses that make each one good at what it does are exactly the differences a layer sitting above all of them has to reconcile. Apache 2.0 licensing lowers the lock-in risk of adopting it early; it doesn't answer whether the open core stays the interesting half of the product once the managed beta matures. Watch that split, not the launch post.