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

Contents

Databricks has introduced Omnigent, a new open-source tool that acts as a meta-harness over existing AI agents such as Claude Code, Codex, or custom agents defined in YAML. Released under the Apache 2.0 license, the project aims to provide a unified layer for composition, governance, and collaboration in multi-agent workflows. Omnigent is thus aimed at engineering teams that want to centrally control heterogeneous agent setups instead of maintaining separate integration and security solutions for each provider.

As the company explains in its blog post introducing Omnigent, the motivation stems from its practical experience working with agents in an engineering team of about 5000 people, as well as from thousands of agent projects for customers. The realization: the crucial progress in agent engineering is shifting from individual models to teams of specialized agents. For example, Anthropic uses a lead agent with parallel sub-agents for its research product. The application Harvey, tailored for AI in the legal industry, combines an open-source worker model with a frontier advisor, enabling it to outperform a single frontier model in terms of quality and cost. Databricks itself uses its product Genie to utilize different LLMs for planning, search, and code generation.

data2day 2026: Conference for Data Scientists, Data Engineers, and Data Teams

From October 7 to 8, 2026, data2day in Cologne will offer a comprehensive program on Data Science, Data Engineering, and Data Analytics. A special focus will be on Agentic AI and Analytics, modern data architectures, legal aspects, and insights into corporate practice.

Tickets are now available at the early bird price.

Architecture: Runner, Server, and Unified API

Omnigent encapsulates any agent – whether terminal-based coding harnesses like Claude Code, Codex, Pi, and Cursor, or SDK-based ones like OpenAI Agents and Claude SDK – in a so-called runner with sandbox session and a unified API. Data exchange follows a simple principle: messages and files flow in, text streams and tool calls flow out. A central server additionally provides policies, session management, and sharing functions. Sessions can be used in parallel via the terminal, local web UI (defaulting to http://localhost:6767), a macOS desktop app, mobile browsers, and APIs.

According to Databricks, the advantage over established orchestration tools lies in the strict separation of business logic and governance. Traditional agent platforms typically couple security logic closely to prompts or the code of a specific framework. Omnigent moves policies to the meta-level – they apply consistently across all connected harnesses and models, regardless of whether a team is currently using Claude Code, Codex, or its own runtime agent. Agents are defined declaratively in YAML files, and changing a harness or model requires only a single line modification. The Omnigent GitHub repository contains example agents for typical coding workflows in addition to the source code.

Fine-grained Policies for Regulated Environments

Databricks documents the Built-in Policies for Security and Cost Control in particular detail. Unlike simple allow/deny mechanisms, these dynamically track the session state and make context-dependent decisions. For example, a policy can enforce that after downloading a new npm package, an agent must obtain human confirmation before a git push.

For use in regulated industries, the policies are granularly configurable: the enforce_sandbox policy allows different sandbox configurations with specific file paths, network rules, and write permissions to be enforced for development, testing, and production environments. Dedicated policies for GitHub, Google Drive, Gmail, and Google Calendar define in detail which repositories, branches, files, or email operations an agent can use – for example, read-only access in prod repos or email drafts without sending permission. The deny_pii_in_llm_request policy scans outgoing messages for personal data and blocks or flags them before the LLM call – a building block for GDPR-compliant setups. Additionally, risk scores are built up based on tool calls and sensitivity labels, creating a cumulative value that mandates human approval above a configurable threshold.

Cost Control and Provider Independence

On the documentation page for Cost Control Policies, you will find mechanisms that track cumulative LLM costs per session or per user across all sessions. At a soft threshold, the cost_budget policy prompts for confirmation and blocks expensive models when a hard limit is exceeded. For instance, an agent can be paused after every $100 in accrued LLM costs. The deny_trivial_to_expensive_model policy automatically classifies requests as trivial versus complex and routes simple tasks away from expensive models.

This routing mechanism also supports a multi-provider strategy. Omnigent does not come with its own LLMs but works with existing credentials – from direct API keys and cloud gateways to on-premises clusters. In the documentation for Custom Agents, it is shown that changing a model in the YAML configuration only affects a single line. For companies currently heavily dependent on a single LLM provider, this reduces lock-in: sessions, policies, and skills are tied to the meta-harness layer, not to a specific model. Investments in governance and security policies are retained when switching providers.

From Individual Developer to Corporation

Installation methods range from shell scripts and pip install 'omnigent' to Homebrew and Git installation. Prerequisites include Python 3.12 or newer, Node.js 22 LTS, git, and tmux; on Linux, additionally bubblewrap for OS sandboxing; macOS uses seatbelt. For small teams, a local installation with own API keys and an optional cloud sandbox via Modal or Daytona is sufficient, according to Databricks. Medium-sized engineering teams can run a centrally deployed Omnigent server on Fly.io or Railway, connected to SSO and internal LLM gateways, with differentiated policies depending on the project and environment.

For larger enterprise setups with potentially hundreds of agents, the architecture provides multi-tenant server instances. Standardized YAML agent definitions can be rolled out versioned via Git, while central security teams define policies such as PII filters, sandbox enforcement, and risk scores. Collaboration features – sharing live sessions via URL, shared file system workspace, real-time comments – are integrated from the start rather than being retrofitted. However, Databricks has not yet documented specific reference deployments of this scale.

Omnigent is in its early stages. Companies should initially test its use in less critical environments and plan for their code audits and integration into existing monitoring.

(map)