Managing Multiple Agents Together: Omnigent's Meta-Harness, Policies, and Cross-Device Sessions

🌏 中文版

Running 4 or 5 agents at once is now normal: Claude Code editing code, Codex running tests, Cursor completing in the editor, plus a custom data-analysis agent. The pain is not whether the model is smart enough, but that every harness is an island — its own sessions, permissions and history. Switching tools means re-explaining context, resetting guardrails and copy-pasting again.

Omnigent (omnigent.ai) is the meta-harness Databricks open-sourced on 2026-06-13 at Data + AI Summit under Apache 2.0. As of 2026-08-26 it has ~9.3k stars / 1.4k forks / 2,838 commits at 0.11.0.dev0 (alpha). It does not replace your harness — it sits above them so sessions, policies and skills travel with you. Claude Code, Codex, Cursor, OpenCode, Hermes, Pi and your own YAML-defined agents can be swapped with one-line changes and live in the same shareable session.

This post covers the design rationale, architecture, hands-on usage and the GitHub landscape around it.

What Omnigent solves: harness fragmentation

Databricks puts it bluntly:

Each harness is its own silo, with its own context, its own controls, and its own way of running, and none of it carries over when you switch tools.

In practice that is three cross-harness problems:

1. Composition: one agent definition should run on Claude today and Codex tomorrow, or mix sub-agents from different harnesses without rewriting.
2. Control: guardrails like "can it git push?" or "stop after $X spent?" should be auditable and not live inside prompts.
3. Collaboration: a live agent session should be shareable via URL so teammates can watch, comment and even take over execution.

A single harness cannot solve all three, so the layer has to move up — the Kubernetes-for-containers analogy Databricks uses.

Architecture: Runner for execution, Server for governance

[You] ── terminal / browser / phone / desktop app / REST API
          │
     ┌────▼────┐
     │ Server  │  persisted session history (Postgres/SQLite), MCP proxy,
     │         │  policy enforcement, auth/OIDC, skill/agent registry, WebSocket sync
     └────┬────┘
          │ WebSocket
     ┌────▼────┐
     │ Runner  │  actually runs harnesses & tools (inside bwrap/seatbelt),
     │ (host)  │  inference & credentials stay on the host
     └─────────┘
  laptop / devbox / K8s Pod / Modal / Daytona / E2B / Blaxel / Databricks sandbox

The key decision is Runner / Server split without splitting brain and hands. The Server only coordinates; the Runner on your chosen host runs harnesses and shells. Inference and API keys never go to the Server. Two immediate payoffs:

• Resumable and shareable sessions: close the laptop, the session stays on the Server; open http://your-host on your phone and continue the same chat, sub-agents, terminals and files.
• Multi-surface sync: terminal, web and desktop app see the same session, with messages and files synced in real time and comments fed back to the agent.

The common API is intentionally small: messages/files in → text streams/tool calls out + cancel. It wraps both "terminal harnesses" (Claude Code, Codex, Pi) and "SDK harnesses" (Claude Agent SDK, OpenAI Agents SDK). New harnesses are plugins — Atlassian's Robo harness is an external example.

How to use it: an agent is a YAML file

Minimal custom agent (Agent YAML spec):

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

executor:
  harness: claude-sdk   # one-line switch: claude-native / codex / cursor-native / hermes / pi / opencode / openai-agents ...

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

  docs:
    type: mcp
    url: https://example.com/mcp

  researcher:
    type: agent
    prompt: Search for relevant information and summarize it.
    tools:
      word_count: inherit

Three takeaways:

• tools has three kinds: function (local Python, schema auto-generated), mcp (MCP server), agent (another full agent as a tool, even on a different harness).
• One-line harness switch: executor.harness or omnigent run path/to/agent.yaml --harness <harness>.
• Start: locally omnigent claude / omnigent codex / omnigent run examples/polly/, or omnigent start then open http://localhost:6767 and pick a host.

The three shipped examples — copy the third

• 🐙 Polly: multi-agent coding orchestrator that writes no code itself — it plans, delegates to Claude Code/Codex/Pi sub-agents in parallel git worktrees, then routes diffs to a reviewer from a different vendor than the author.
• 🟠🔵 Debby: two-headed debate — same question to Claude and GPT side by side, with /debate for cross-critique.
• 🔎 Deep Research: single agent + one MCP search server; plans sub-queries, fetches full pages and cross-checks claims. Simplest to copy.

Models and hosts

omnigent setup

Four credential kinds are first-class: API key, Claude Pro/Max or ChatGPT subscription (via official CLI login), Gateway (OpenRouter, LiteLLM, Ollama, vLLM, Azure), and Databricks workspace (databricks extra). Per-harness defaults coexist and /model switches mid-session.

Deploy via docker compose up or one-click to Render/Railway/Fly.io/Hugging Face Spaces/Modal/Cloudflare/Databricks Apps, or expose your laptop via Cloudflare Tunnel / Tailscale. The Server can also provision a cloud sandbox per session (managed hosts).

The real differentiator: Policies and Omnibox

Omnigent moves governance out of prompts and into server-side tool-hook interception. Policies are Python functions that see the whole session (what was already read + what is requested) and return allow / deny / ask.

policies:
  approve_shell:
    type: function
    handler: omnigent.policies.builtins.safety.ask_on_os_tools
  cap_calls:
    type: function
    handler: omnigent.policies.builtins.safety.max_tool_calls_per_session
    factory_params: { limit: 50 }
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params: { max_cost_usd: 5.00, ask_thresholds_usd: [3.00] }

Three levels stack: server-wide (admin) / per-agent (developer) / per-session (you), strictest wins. Cost budgets (soft warning + hard cap), tool-call caps and sandbox enforcement share the same path. Toggle in the web UI or just ask in chat: "add a policy that asks before shell commands."

Sandboxing is two-layered:

• Omnibox OS layer: Linux bubblewrap (bwrap), macOS seatbelt, with write_paths/read_paths, allow_network, env_passthrough, HTTP egress_rules and credential proxy that hides GitHub tokens and only injects them at the egress proxy for allowed requests.
• Cloud sandbox layer: Modal, Daytona, Blaxel, Islo, E2B, CoreWeave, Kubernetes, OpenShell, Boxlite, Databricks — one isolated env per session, stays alive after you close the laptop.

Windows is degraded (Job Objects for process-tree isolation only, no FS/network isolation — use WSL).

Who Omnigent governs: a harness panorama

Omnigent governs single harnesses. A representative sample — shown together to avoid singling one out:

• Block/Goose (51k, Rust, AAIF) — most neutral, 40+ providers, ideal to illustrate why neutral governance matters.
• OpenCode — natively supported as opencode in Omnigent, lightweight BYOK, ideal for "one-line switch".
• Pi (badlogic/pi-mono) — minimal harness and the base of Cloudflare Flue, showing how a small harness is amplified.
• DeepSeek Harness (dsh, preview 2026-08-25, MIT, 165k) — Everything is a Plugin (Cordis), even UI is a plugin, the extreme of single-harness plasticity.

All are peers to Claude Code / Codex (model + harness = agent); Omnigent is the meta-harness above. Their models already work via Omnigent Gateways and they can be wrapped as harness: goose/opencode/pi/deepseek.

ADE (Agentic Development Environment): control plane vs workspace

ADE is now a category, not a single product. The most representative is arul28/ADE (Your workspace for every AI coding agent — macOS, Windows, iOS, and CLI all synced), with siblings Kadro ADE, Orca, per-simmons/damon-ade and DCENT_ADE.

One-liner: Omnigent = control plane, Runner + Server + Omnibox + Policy turning many harnesses into swappable, governable services; ADE = workspace, Brain + Desktop/Web/Mobile + Lane/worktree + PR turning many agents into a parallel, viewable development environment.

They stack: run Omnigent Runners on the same machine that hosts ADE's Brain, or treat ADE as one host UI for Omnigent.

GitHub landscape: scanning three Topics

We scanned agent-orchestration (2,895 repos), agent-governance (677 repos) and agent-framework (2,408 repos) cross-checked with agent-harness. The control-plane peers worth comparing:

Control plane / governance (direct peers)

Protocol / SDK (complementary)

Zed ACP (LSP for agents), Vercel HarnessAgent (swap harnesses in code) and Cloudflare Flue (durable execution at scale) solve "access", "SDK switch" and "cloud scale" respectively — all stackable under Omnigent.

Often mistaken for the same layer

HKUDS/nanobot (47.4k), deepset-ai/haystack (26.3k), microsoft/agent-framework (13.1k, AutoGen successor) and strands-agents/harness-sdk (7k) are frameworks being orchestrated, not governance layers.

Three same-named metaharness projects (ruvnet/metaharness, stanford-iris-lab/meta-harness, SuperagenticAI/metaharness) mean "outer-loop optimizer that rewrites harness code" (arXiv:2603.28052) — same name, different meaning.

When to use Omnigent

Good fit:

• Teams already using multiple harnesses/models and wanting one-line swaps.
• Sharing a live session with teammates (comment, co-drive with omnigent attach <session_id>, fork with omnigent run --fork <session_id>).
• Cloud sandboxes that keep running after you close the laptop.
• Auditable cost and safety guardrails beyond prompt allowlists.

Not a good fit:

• Single-harness, single-machine personal use — native harness is lighter (Omnigent adds a server + tmux/bwrap deps).
• Windows-native with strong FS/network isolation needs — degraded mode.
• Low tolerance for alpha — 0.11.0.dev0 APIs still move (omni upgrade).

Overall

Omnigent lifts "agent portability" one level up, trading a self-hosted Server for cross-harness reuse, stateful governance and real-time collaboration. If your pain is "too many tools, hard to collaborate, governance stuck in prompts", it is the most complete open-source answer today; if you live in one harness on one machine, the value is indirect.

Next steps worth exploring: a head-to-head on the same task across loopx / loushang / mission-control vs Omnigent (tokens / latency / governance granularity), or a deep dive into Omnibox egress policies and secretless credentials for enterprise deployment.

References

• Omnigent — a meta-harness for building and running AI agents
• omnigent-ai/omnigent
• Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents — Databricks Blog
• Omnibox (OS Sandbox) / Shared Server / Agent YAML Spec
• What Is a Meta-Harness? A 2026 Buyer's Guide — codepick.dev
• DeepSeek Harness / DeepSeek Harness website / Block/Goose / OpenCode / Pi
• herdrdev/herdr / superset-sh/superset / builderz-labs/mission-control
• huangruiteng/loopx / zhnt/loushang / holaboss-ai/holaOS
• FailproofAI/failproofai / first-fluke/oh-my-agent / microsoft/agent-governance-toolkit
• arul28/ADE / ade-app.dev
• Meta-Harness: End-to-End Optimization of Model Harnesses — arXiv:2603.28052