What Databricks Announced
Omnigent is an open-source meta-harness, released under Apache 2.0 with a managed beta on the Databricks platform. It sits above individual agent harnesses — Claude Code, Codex, Cursor, Pi, and custom agents — and treats each as an interchangeable worker under one orchestrator, exposing a common interface to combine, control, and share them.
Databricks frames the product around three capabilities. Composition lets teams combine models, harnesses, and techniques without rewriting, switching between agents with one-line changes. Control applies stateful, contextual policies that track agent actions and enforce guardrails such as cost budgets and permissions at the meta-harness layer rather than through prompts. Collaboration shares a live agent session by URL so teammates can review files, comment, and steer in real time. Underneath sits sandboxed execution with operating-system access controls. The thesis is stated plainly: to combine agents, govern them, and work on them with other people, you need a layer above the harness, and Omnigent is that layer.
Omnigent’s control plane is genuinely governance-flavored — budgets, permissions, action tracking. But it governs agent execution: which agent runs, what it may spend, what it may access. That is a different object from the architecture of the code those agents change.
Orchestration Governs Execution. It Doesn’t Govern Intent.
The questions a meta-harness answers are execution questions. Which agent should run this step? What is its budget? What can it touch? Can a human take the wheel mid-session? Those matter, and Omnigent answers them well. They are not the questions a codebase asks.
Multi-agent orchestration actually makes the architectural problem harder, not easier. When Omnigent composes a workflow — one agent plans, another implements, another reviews — every agent that does not know a given architectural decision re-decides it. The orchestration layer routes work between agents; it does not carry the architecture decision records, the service boundaries, and the engineering standards along with the work. More agents means more independent chances to drift from the intended design.
The Stack Databricks Just Validated
Omnigent’s real significance is that a company of Databricks’ weight is now teaching the market that the layer above the agent is a category. That makes the shape of the full stack easier to see — including the layer Omnigent does not occupy.
| Layer | Example | Question it answers |
|---|---|---|
| Models | Claude, GPT, Gemini | What can be generated? |
| Coding agents / harnesses | Claude Code, Codex, Cursor | How is a task executed? |
| Agent orchestration | Omnigent | Which agents run, with what budget and access? |
| Observability | Langfuse, Reflexes | What happened? |
| Engineering governance | The missing layer | Did the change respect architectural intent? |
| Source control & CI | Git, tests | Did it build? |
The Gap Omnigent Doesn’t Close
Across a multi-agent workflow, the questions that go unanswered are the ones that keep a system coherent. Why was this architectural decision made? Which ADR applies to this change? Which domain boundaries must hold? Which standards govern this repository? How does each agent in the chain inherit the same engineering intent? When Omnigent composes five agents to plan, implement, and review a change, the architecture gets five chances to drift unless intent is enforced at the point where each agent generates code.
Could Databricks extend Omnigent into this layer? Possibly; it has the resources. But the starting points differ. Databricks reasons from data to models to agents to orchestration. Engineering governance reasons from intent to architecture to code. The control plane that preserves architectural decisions is a different product from the one that routes and budgets agents, even when both wear the word “governance.”
What Engineering Leaders Should Do
Adopt orchestration for what it is good at — composing agents, controlling cost and access, collaborating on sessions — and add the layer it does not provide.
- Make architectural intent executable. ADRs, boundaries, and standards become machine-readable constraints that survive whichever agent the orchestrator selects.
- Enforce before generation, inside every step. Governance before generation means each agent in a composed workflow retrieves the same constraints before it writes code, so plan, implement, and review stages cannot independently diverge.
- Propagate intent across surfaces. Governance propagation carries the same decisions across agents, harnesses, and the orchestration layer, the way Omnigent already carries sessions and policies.
Databricks has validated that the layer above the agent matters. The layer above that — the one that keeps the architecture true as agents multiply — is the one engineering teams still have to build. We have mapped the emerging agent infrastructure stack in detail; Omnigent is the meta-harness slot filling in, and engineering governance is the slot above it. Orchestration coordinates agents. Governance preserves intent.