What is an agent meta-harness?

Summary

• A harness is the runtime that executes an agent loop, such as Claude Code or Codex. An agent meta-harness is a layer above harnesses, so your tools, prompts, skills and policies stay the same when you change the agent or the model underneath.
• Omnigent is an open-source meta-harness (Apache 2.0, status alpha) that Databricks introduced in June 2026. It works over Claude Code, Codex, Cursor, OpenCode, Hermes, Pi and custom agents you define in YAML.
• Policies are the control layer. Each policy returns ALLOW, ASK or DENY for an action, and you can set policies for a whole server, for one agent or for a single session.
• One session stays in sync across the terminal, browser, phone and desktop app, and teammates can watch it, co-drive it or fork it.
• On Databricks, Omnigent is in Beta as a managed service that uses your workspace identity, Foundation Model APIs and Unity Gateway.

What is an agent meta-harness?

An agent meta-harness is a layer that sits above the harnesses that run your agents. A harness is the runtime that executes an agent loop, and Claude Code and Codex are two examples. Databricks, which introduced Omnigent in June 2026, describes each harness as "its own silo, with its own context, its own controls, and its own way of running." A meta-harness gives you one interface, one set of policies and one shareable session across them, so "your sessions, policies, and skills stay with you no matter which agent or model is running."

How is a meta-harness different from a harness?

Layer	What it is	Why it matters
Harness	The runtime that executes the agent loop, such as Claude Code, Codex or Pi	Each has its own interface, controls and sessions
Meta-harness	A layer above harnesses for combining, controlling and sharing them	Tools, policies and sessions survive a change of harness

What should you look for in a meta-harness?

Capability	What to look for	What Omnigent documents
Harness swap	A one-line change that keeps tools and policies	executor.harness in the agent YAML
Mixed agents	Several agents in one session	Claude Code, Codex, Cursor, OpenCode, Hermes, Pi and custom agents together
Governance	Rules enforced outside the prompt	ALLOW, ASK or DENY policies at server, agent and session level
Shared sessions	Teammates in the live session	Share with Read or Edit access, co-drive, fork
Isolation	Limits on what an agent can touch	An OS sandbox, cloud sandbox hosts, Kubernetes
Interfaces	The same session on every screen	Terminal, web UI, iOS and Android apps, desktop app, Slack

How does Omnigent work?

Omnigent has three components. A runner wraps an agent in a sandboxed session with a uniform API and executes on a host, which is a machine you register with the server or a cloud sandbox. A server provides policies and sharing. The terminal, web and mobile interfaces talk to the server and never to the runner.

What does an Omnigent agent definition look like?

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

executor:
  harness: claude-sdk   # swap this line to change harness

tools:
  word_count:
    type: function
    callable: mypackage.mymodule.word_count

policies:
  approve_shell:
    type: function
    handler: omnigent.policies.builtins.safety.ask_on_os_tools
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00          # hard spend cap...
      ask_thresholds_usd: [3.00]  # ...with a soft warning on the way

Run it with omnigent run path/to/my_agent.yaml. Swap claude-sdk for codex, cursor, hermes, opencode or pi, and the tools and policies stay put. Tools can be local Python functions, MCP servers or sub-agents, and each sub-agent can pick its own harness and model.

How do policies govern an agent?

Every policy returns ALLOW (the action proceeds), ASK (it pauses until you approve or reject it) or DENY (it is blocked with an error). Policies are stateful, so a decision can depend on what already happened, such as cumulative spend. The session level is checked first, then the agent, then the server. Builtins cover approval gates, tool-call limits, cost budgets, GitHub access and PII blocking. For custom rules, cel_policy takes a CEL (Common Expression Language) expression, and a self-hosted server can also register Python policies.

How does Databricks approach the meta-harness?

On Databricks, Omnigent is in Beta. Databricks runs the Omnigent server and connects it to your workspace identity provider. Models come through Foundation Model APIs and Unity Gateway, and Databricks Sandboxes (available in select regions on AWS) can host the agent. An admin must enable the Omnigent preview. The managed service supports the built-in contextual policies and custom CEL policies, not custom Python policies, and a Databricks Sandbox host can't use your own model API keys. The open-source docs describe a self-managed deployment on Databricks Apps for cases the managed service doesn't cover.

FAQs

Do I need a meta-harness to run more than one coding agent?

No. Each agent runs on its own. A meta-harness pays off when you want the same tools, policies and sessions across agents or across people.

Can I keep the same model when I swap harnesses?

Not always. The cursor harness talks only to Cursor's own backend, so it takes a Cursor model id instead of a databricks-* id.

Can I use my own models?

Yes. Omnigent accepts a first-party API key, a Claude or ChatGPT subscription, any OpenAI- or Anthropic-compatible gateway (including a local model server), or a Databricks workspace profile.

What happens when a policy blocks an action?

A DENY stops the action and the agent receives an error. An ASK pauses it until you approve or reject. Approval becomes ALLOW, and a refusal becomes DENY.

What is Omnigent's release stage?

The open-source repository lists "Status: alpha". On Databricks, "Omnigent is in Beta".