Databricks Omnigent: Open-Source Meta-Harness for AI Agents

If you build with AI agents in 2026, your desk probably looks like this: Claude Code open in one terminal, Codex in another, maybe Cursor’s agent in the editor and a homegrown script wired to the OpenAI Agents SDK. Each is good at something. None of them know about each other. You copy-paste context between them, re-approve the same risky commands over and over, and have no clean way to let a teammate watch — let alone help.

On June 13, 2026, Databricks open-sourced its answer: Omnigent, a meta-harness for building and running AI agents. It’s Apache-2.0 licensed, currently in alpha, and built by the Databricks AI team together with Neon. The pitch is simple and a little audacious: stop picking a single agent harness, and put a thin, governed layer above all of them.

What is a “meta-harness”?

A harness is the program that wraps a model and turns it into an agent — it manages the conversation, exposes tools, runs commands, and streams results back. Claude Code is a harness. So are Codex, Cursor, and Pi.

A meta-harness sits one level up. Omnigent’s founding observation is that every harness, underneath the branding, speaks the same shape of language: messages and files go in; text streams and tool calls come out. Once you accept that uniformity, you can wrap any agent in a common interface and add capabilities that no single harness offers on its own.

Databricks frames it as an infrastructure shift, the way cloud platforms once abstracted away managing individual servers:

“The frontier of agent engineering is moving up a level. The best results no longer come from a single model in a single harness.”

“A meta-harness lifts your work above any single harness, so your sessions, policies, and skills stay with you no matter which agent or model is running.”

That portability is the whole point. Your guardrails, your shared sessions, and your custom skills stop being tied to whichever tool you happened to open.

Three pillars: composition, control, collaboration

Omnigent organizes its features around three words.

1. Composition — swap and combine harnesses without a rewrite

Agents in Omnigent are defined in short YAML files. Want to run the same agent on Claude’s SDK today and Codex tomorrow? Change one line:

name: data_analyst
prompt: You are a helpful data analyst.

executor:
  harness: claude-sdk   # swap to: codex, cursor, openai-agents, pi…

Because the harness is just a field, your prompt, tools, and skills travel unchanged when you switch models or vendors. You can also nest agents — give one agent a sub-agent as a tool — so “composition” isn’t only about swapping engines, it’s about wiring several together into one system.

2. Control — guardrails that actually understand the session

This is the part that should interest anyone who has nervously watched an agent run rm or git push. Most coding agents offer blunt “allow X / deny Y” rules baked into a prompt. Omnigent enforces stateful, data-centric policies at the meta-harness layer — outside the model, where the model can’t talk its way around them — and those policies can track what has happened earlier in the session.

The canonical example Databricks gives: require human approval to git push only after the agent has downloaded a new package from npm. The policy reasons about session history, not just the current command. Other built-ins cover the failure modes teams hit in practice:

• Cost budgets. Pause an agent and ask before it blows past a spend threshold — say, $5.00 with a check-in at $3.00.
• Tool-call caps. Stop a runaway loop after N tool calls per session.
• Shell approvals. Prompt a human before the agent touches OS-level tools.
• Write scoping. Restrict edits to documents the agent itself created.

Underneath sits Omnibox, an OS-level sandbox that controls filesystem and network access and can intercept and rewrite network requests. The clever bit: it can hide your GitHub security token from the agent entirely, then inject it only into approved, outbound proxy requests. The agent gets its job done without ever seeing the secret.

Policies stack in layers — server-wide (set by an admin), per-agent (set by a developer), and per-session — with the strictest rule checked first.

3. Collaboration — sessions you can share, watch, and steer

In Omnigent, a running agent session is a shareable object. Click Share and you get a URL with full history that a teammate can open to review what happened, comment on files in the agent’s workspace, and send commands to steer it — in real time. Two commands make this concrete:

omni attach <session_id>      # co-drive an existing session
omni run --fork <session_id>  # branch the conversation onto your own machine

The same session is reachable from the terminal, a browser, a phone, or a native macOS app. The session, not the laptop it started on, becomes the unit of collaboration.

Under the hood

The architecture is small enough to hold in your head:

• Runner — wraps any agent in a sandboxed session and exposes it through one uniform API.
• Server — applies policies, handles sharing, and exposes sessions to the outside world (it runs locally at http://localhost:6767 by default).
• Interface layer — surfaces those sessions over the terminal, a web app, and APIs.

Out of the box it ships two demo agents — Debby (a single helper) and Polly (a multi-agent orchestrator) — so there’s something to run on minute one. For execution, sessions can stay on your local machine or run in cloud sandboxes through providers like Modal, Daytona, and Islo.

Omnigent on Databricks: the managed version

Alongside the open-source project, Databricks offers a managed Omnigent on Databricks (in Beta). It’s a Databricks-operated server that plugs into your workspace’s identity provider, routes model access through Foundation Model APIs and the Unity AI Gateway, and can run agents inside Databricks Sandboxes for secure, collaborative coding (currently select AWS regions).

The trade-off for that turnkey governance is some flexibility: the managed tier supports only the built-in contextual policies (no custom YAML policy handlers), has no native Windows support (WSL2 required), and is incompatible with serverless egress control. For enterprises that want agents to act on governed data with centralized control, though, the integration with Unity Catalog and the AI Gateway is the real draw — the same governance you apply to tables and models now extends to what agents are allowed to do.

Why this matters

The interesting claim here isn’t “Omnigent is better than Claude Code.” It’s that the category — a portable layer above all the harnesses — is where serious agent engineering is heading. The push to standardize how agents discover tools across the enterprise is the same instinct applied to infrastructure. As models and tools keep churning, you don’t want your guardrails, audit trail, and team workflow to evaporate every time you switch vendors. A meta-harness is a bet that the durable assets are your policies, sessions, and skills, and that those should outlive any single agent.

It’s worth keeping expectations calibrated. This is alpha software moving fast — the CLI, APIs, and policy format will change, the desktop and mobile surfaces are young, and “governed multi-agent orchestration” is a hard problem that no one has fully solved. But the framing is sharp, the design is refreshingly small, and it’s open source under Apache 2.0, so you can read every line.

If you’re juggling more than one agent today, Omnigent is worth an afternoon. The companion piece — a hands-on Getting Started with Omnigent tutorial — walks through installing it, running your first agent, adding policies, and sharing a live session. You can read more on the Databricks blog, at omnigent.ai, or in the GitHub repository.