1. Home
  3. AI
  5. Databricks
  7. Omnigent, Explained Simply: The One Layer That Finally Tames Your AI Agents

Omnigent, Explained Simply: The One Layer That Finally Tames Your AI Agents

0

You’ve got Claude Code in one window, Codex in another, and a custom agent your team wrote. None of them know the others exist. Omnigent fixes exactly that, and it’s open source. Here’s everything, in plain English, with the code to try it in five minutes.

Repo: https://github.com/omnigent-ai/omnigent · Site: omnigent.ai · License: Apache 2.0 (alpha)

Not long ago, I sat in on a peer review where we cut a banking client’s agent design from eight agents to three, plus eleven deterministic MCP tools. The lesson stuck with me: most “agent problems” aren’t about smarter agents. They’re about governing what the agents you already have are allowed to do, and getting them to work together without chaos. When I saw what Databricks just open-sourced, it landed on exactly that nerve. Here’s the breakdown.

Why it’s needed

In 2025, everyone shipped an AI agent. In 2026, the problem isn’t building one agent — it’s running five of them at once without losing your mind, your budget, or your security boundary.

Picture a normal week right now:

  • Claude Code open in one terminal, Codex in another, Pi in a third.
  • You copy and paste context between them by hand because none of them share state.
  • Each one has its own config, its own way of requesting permission, and its own credentials.
  • Your “guardrails” are sentences inside a prompt, the exact layer a prompt injection attack can talk its way past.
  • You find out about a runaway token bill after it happens.

This isn’t a fringe worry. Industry surveys this year suggest the large majority of AI agents reach production without a full security and IT review; one widely cited figure put the share that ship with proper sign-off in the mid-teens. Multiply that across a team running several agents, and you have quiet chaos.

The agent count was never the hard part. The control plane is.

What it is

Omnigent is a “meta-harness” — a single layer that sits above all your AI agents, making them work as one system.

Quick vocabulary, because the whole thing hinges on one word:

  • A model is the brain (e.g., Claude, GPT).
  • A harness is the body wrapped around that brain so it can actually do work — read files, run commands, call tools. Claude Code is a harness. Codex is a harness. Your custom agent is a harness.
  • A meta-harness is the layer above the harnesses. It treats each one as an interchangeable worker under one orchestrator.

The cleanest way to picture it: Omnigent is to agent harnesses what Kubernetes is to servers. You stop managing each one by hand and start managing them through one consistent control layer. Databricks open-sourced it (built with Neon), released it under Apache 2.0, and it runs on your models and your infrastructure.

What problem it solves

Three problems a single harness can’t solve on its own:

  1. Composition — combining different agents in one workflow. Today, asking Codex to review what Claude Code wrote means copying text between windows. The best real-world results already span harnesses: a cheap, open-source worker model paired with an expensive frontier “advisor” gets you frontier-quality without the frontier bill at every step.
  2. Control — governing what agents can do. Cost, security, and tool access are set per-agent today, inconsistently, in the wrong layer.
  3. Collaboration — sharing a live agent session with a teammate, or picking it up on your phone. A harness only understands its own local session.

How it solves that problem

1. Install and run in two commands

One line installs everything:

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh<br>

Prefer a package manager?

uv tool install omnigent        # or: pip install "omnigent"<br>brew install omnigent-ai/tap/omnigent<br>

(You’ll need Python 3.12+, Node.js 22 LTS, and tmux; the installer offers to set up what’s missing.)

Then start an agent:

omnigent          # picks a model with you, starts a session<br>

That one command starts a session in your terminal and launches a web UI at http://localhost:6767. The same session shows up in your browser — or on your phone on the same network. The CLI also installs as omni (shorter alias).

Launch a specific harness, or your own agent:

omnigent claude # Claude Code, in a session your team can join 
omnigent codex # Codex
omnigent run path/to/agent.yaml # your own agent

Two example agents ship in the repo and make great first runs: Polly (a tech-lead orchestrator who plans, delegates coding to sub-agents in parallel git worktrees, then routes each diff to a reviewer from a different vendor than the one that wrote it) and Debby (a brainstorm partner with two heads, one Claude and one GPT, that you can make /debate each other):

omnigent run examples/polly/ 
omnigent run examples/debby/

2. Use any model — and switch mid-session

Omnigent accepts four credential types: a first-party API key, a subscription you already pay for (Claude Pro/Max or ChatGPT), any compatible gateway (OpenRouter, LiteLLM, Ollama, vLLM, Azure), or a Databricks workspace. Defaults are per-agent, and you can swap models in the middle of a conversation:

/model

3. Write your own agent in a few lines of YAML

An agent is just a short YAML file, a prompt, tools, and optional sub-agents a supervisor can delegate to. (You can even describe the agent you want in chat and have Omnigent write the file for you.)

4. Govern agents with real policies — below the prompt

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

executor:
  harness: claude-sdk          # or: codex, codex-native, claude-native, openai-agents, pi

tools:
  # A local Python function (schema auto-generated from the signature)
  word_count:
    type: function
    callable: mypackage.mymodule.word_count

  # A sub-agent the supervisor can delegate to
  researcher:
    type: agent
    prompt: Search for relevant information and summarize it.
    tools:
      word_count: inherit
omnigent run path/to/my_agent.yaml

This is the part that matters most. Policies check every action an agent takes and either allow it, block it, or pause to ask you first. They’re enforced at the harness layer, not via instructions the agent could ignore:

policies:
  approve_shell:
    type: function
    handler: omnigent.policies.builtins.safety.ask_on_os_tools   # ask before shell/file writes
  cap_calls:
    type: function
    handler: omnigent.policies.builtins.safety.max_tool_calls_per_session
    factory_params:
      limit: 50                    # cap how many tools one session can call
  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

Policies stack across three levels, server-wide (admin), per-agent (developer), and per-session (you) — with the stricter session rules checked first.

The security piece is genuinely different from “please don’t leak my keys.” Omnigent ships with an OS-level sandbox (reported to use kernel-level enforcement, bubblewrap and seccomp on Linux, Seatbelt on macOS). The practical effect: an agent can be allowed to push to a repo without ever holding the GitHub token. The token is injected into the egress proxy only on approved outbound requests, so the agent can’t exfiltrate it. That’s enforcement at the operating-system level, not a sentence in a prompt.

5. Collaborate and run anywhere

Share a live session by link so a teammate can watch and chat with your agent. Hand them the keyboard mid-task:

omnigent attach <session_id>      # co-drive: their messages run on YOUR machine
omnigent run --fork <session_id>  # fork: clone the conversation, continue on their own

Turn on multi-user accounts with one env var (OMNIGENT_AUTH_ENABLED=1), wire up Google/GitHub/Okta/Microsoft login via OIDC, and run sessions in disposable Modal or Daytona cloud sandboxes, no laptop required. Deploy targets include Docker Compose, Render (one click), Fly.io, Railway, and Hugging Face Spaces.

The pros and cons (the honest version)

Pros

  • Vendor-neutral by design. Works across Claude Code, Codex, Pi, OpenAI Agents SDK, Claude Agents SDK, and custom agents. The whole point is not getting locked into one harness.
  • Security that’s real, not aspirational. OS-level sandboxing and credential brokering close the exact gap that most teams can’t currently address.
  • Cost governance is built in. Hard spend caps and soft warnings ship as defaults.
  • Uses what you already pay for. Subscriptions, local models via Ollama, gateways — all first-class.
  • Low barrier to custom agents. With a few lines of YAML, agents can author agents.
  • Free and open (Apache 2.0), useful on day one, self-hostable end-to-end.

Cons

  • It’s alpha. Brand-new repo, small star count, fast-moving. Not something to rebuild production on yet.
  • No prebuilt production agents. It ships reference orchestrators (Polly, Debby) and the framework — the enterprise-specific agents are still on you.
  • Headline roadmap items aren’t shipped. Auto-optimization (GEPA), code-based introspection (MemEx, RLM), and the cross-session Omnigent Server MCP are promised, not available.
  • You own the infrastructure. “You provide the models and the infra” means real ops overhead — servers, sandboxes, credentials, upgrades.
  • Another abstraction layer is another place to debug when something breaks.
  • Toolchain setup (Python 3.12+, Node 22, tmux) is a small but real hurdle for non-engineers.
  • Databricks gravity. It’s genuinely open, but the smoothest path still tilts toward the Databricks ecosystem.

Where this lands by industry (beyond the vendor demos)

The official examples are all coding workflows. The more interesting fit is in regulated and cost-sensitive shops:

  • Pharma/life sciences: In GxP and data-residency-bound environments, the value isn’t speed — it’s the sandbox keeping agents from ever touching PHI/PII directly, plus an audit-friendly approval gate on anything that writes.
  • Banking/financial services: Spend caps and human-in-the-loop approval before an agent touches a system-of-record map cleanly onto model-risk governance (think SR 11-7-style oversight). Every action checked and logged is the part risk teams actually want.
  • Healthcare: Egress control that prevents an agent from exfiltrating data is a concrete HIPAA story, not a checkbox.
  • Consultancies and distributed teams: Live session sharing and co-drive turn “send me your context” into “join my session,” which is a real productivity unlock for pairing across time zones.
  • Cost-sensitive startups: The cheap-worker-plus-frontier-advisor pattern lets you buy frontier quality only where it counts.

The common thread: the teams that couldn’t let agents run free are exactly the ones a governed meta-harness unlocks.

The bottom line

2025 was the year everyone built an agent. 2026 is the year someone has to run twenty of them written by different teams, on different models, in different harnesses, and without losing the budget, the security boundary, or their sanity.

Omnigent is a bet that the next layer of the agent stack isn’t a smarter agent. It’s the harness above the harnesses.

It’s free, it’s open, and it runs today. Star the repo, clone it, and run omnigent then decide for yourself.

👉 https://github.com/omnigent-ai/omnigent

Omnigent is open source (Apache 2.0) and in alpha. Announced ahead of Databricks Data + AI Summit 2026 (June 15–18). Verify commands against the repo’s quickstart, since an alpha project moves fast.

+ There are no comments

Add yours

Leave a Reply