Three layers above your coding agents
A map of the layer forming on top of Claude Code and Codex (single harnesses, parallel-run UIs, and the meta-harness), and why governance, not orchestration, is the part that decides whether a company can adopt any of it.
TL;DR. A new layer is forming on top of coding agents like Claude Code and Codex: the meta-harness. What gets called “agent orchestration” is really three buckets: single harnesses (Claude Code, Codex, Pi), parallel-run UIs that run a fleet of agents in isolation (Conductor, Sculptor, Vibe Kanban), and true meta-harnesses that wrap many harnesses behind one interface and govern them. As of June 2026 only Databricks’ Omnigent does both, and it covers the sandbox-and-policy half of governance, not identity or audit. Those two are the half the academic frameworks point to, and the half we build at Highflame: ZeroID for per-agent identity, Overwatch for tool scanning. The measured reason it matters: open-source agent runtimes hand a “summarize a file” task the same access as “deploy to production,” a 15× overprovision (arXiv 2604.11839).
An AI coding agent can use your GitHub token without ever seeing it. A proxy holds the token and injects it only on the calls a policy has already approved, so an injected instruction that tells the agent to leak the key finds nothing to take. That capability shipped in Omnigent, the meta-harness Databricks open-sourced on June 13 under Apache 2.0.
It is a small feature with a large implication. A layer is assembling on top of the coding agents themselves, and the token trick is the kind of thing only that layer can do. Most of what gets filed under “agent orchestration” is three different things stacked together, and they get conflated constantly. What follows is a map of the layer, and an argument about which part of it will matter.
The harness, and the layer above it
The harness is everything in an agent except the model. The model supplies the reasoning; the harness supplies the tools it can call, the permissions it runs under, the memory it carries between turns, and the loop that ties them together. Claude Code, Codex, Gemini CLI, Cursor, and Pi are harnesses. When people say a model “is good at agentic coding,” much of what they are praising is the harness around it.
Above the harness, a second layer is forming to do the things a single harness cannot: run many of them at once, move work between them, and govern what they are allowed to do. That layer sorts into three buckets, and telling them apart is most of the work.
The map, in three buckets
1. Single harnesses
The base layer is the harness itself: Claude Code, Codex, Gemini CLI, Cursor, Pi.
Pi is worth pausing on, because it gets miscounted as an orchestrator. It is a single harness that abstracts over model providers rather than over other harnesses: one terminal agent loop you can point at Claude, GPT, Gemini, or a local model, extended through a TypeScript SDK. It deliberately ships no governance and no sub-agent orchestration, on the view that those belong in the layers around it, not inside the harness. Running one harness against many models is a different axis entirely from running one interface over many harnesses.
2. Parallel-run UIs
The crowded middle runs a fleet of agents at once, each isolated so they do not overwrite each other. Conductor is a Mac app that drives Claude Code, Codex, and Cursor in separate git worktrees against the same repository. Sculptor, from Imbue, puts each agent in its own Docker container instead of a worktree. Crystal did the worktree version as an open-source desktop app and has since been folded into a successor called Nimbalyst. Vibe Kanban runs more than ten different agent types from a kanban board, though its company shut down and the project is now community-maintained. Omnara is a command center that watches agents across terminal, web, and phone.
They all optimize for parallelism and isolation. Governance is simply not in their scope. A worktree keeps two agents from colliding; it does nothing to stop either one from reading a secret it should not, or running a command it should not. This list also churns monthly, which is itself a fact about how young the layer is.
3. The meta-harness
The third bucket is the one that is actually new: a single interface that wraps several different harnesses and governs them. As of mid-2026, Omnigent is the only tool that does both. It puts Claude Code, Codex, Pi, and the OpenAI and Claude Agents SDKs behind one API, so switching the harness underneath an agent is a one-line change rather than a rewrite. Then it enforces policy from above the agent: pause after every hundred dollars of spend, intercept and rewrite outbound network calls, hold secrets so the agent never sees the raw value.
Plenty of community tools span multiple harnesses without the governance half. ivy-tendril, jean, and ORCH each drive several harnesses behind one runtime, but they stop at orchestration. ruflo, formerly Claude Flow, calls itself a meta-harness, but everything executes through Claude Code underneath. Goose, now stewarded by the Linux Foundation, is an extensible single-agent framework rather than a layer over other harnesses. The combination that defines the bucket, many harnesses plus enforced governance, is so far a category of one.
Governance is the bucket that decides adoption
Running ten agents in parallel is the part that demos well. Whether a company can put any of them near a production repository is decided by the governance bucket.
The need is measurable, not hypothetical. In a study of open-source agent runtimes, researchers found that a task as harmless as summarizing a file was handed the same shell access, credential access, and authority to spawn sub-agents as a task to deploy to production. They put it at a 15× overprovision, fifteen times the capability the work required (Beyond Static Sandboxing, arXiv 2604.11839). An agent that only needed to read a file was holding the keys to ship code.
You cannot close that gap by writing a better system prompt, because the model is the part of the system you do not fully trust. The fix has to sit somewhere the agent cannot argue with, which means one layer up. That is the structural reason the meta-harness exists: it is the first place in the stack where a policy can hold regardless of what the agent decides to do.
Academic work points past where Omnigent stops. A recent governance architecture proposes four layers: an execution sandbox, a check on each tool call before it runs, zero-trust identity between agents, and an immutable audit log (Governance Architecture for Autonomous Agent Systems, arXiv 2603.07191). Omnigent does the first two convincingly. It sandboxes the agent and gates what its tool calls may do, down to spend caps and per-session limits. It does not do the other two. There is no per-agent cryptographic identity and no immutable audit trail of who did what. Identity and audit are the half of governance this layer has not built yet.
How a policy holds one layer up
The mechanics are worth seeing concretely, because “governance” is a word that usually resolves to a dashboard. Here it means something an attacker runs into.
Take the secret again. In Omnigent’s sandbox the agent process never holds your GitHub token. The token lives in an egress proxy that the agent’s network traffic passes through. When the agent makes a request to an approved host, the proxy injects the credential on the way out. A prompt injection that convinces the agent to print its environment, or to POST its secrets to an attacker’s server, gets nothing, because there is nothing in the agent’s reach to print or POST. The control is not advice to the model; it is a property of where the secret physically sits.
The same principle covers spend and actions. A stateful policy can pause the session after a spend threshold and ask a human whether to continue. A network policy can let the agent read from a package registry but refuse a POST to an unknown host. You do not ask the model to respect these. They are enforced outside it, by the layer that wraps it.
A builder’s read
I work on exactly this gap, which is part of why I read it the way I do. The orchestration is not the hard part; running several sessions at once is a weekend of plumbing. The hard parts, the ones that decide whether you can trust the result, are identity and audit. At Highflame we built ZeroID, which gives every agent and sub-agent a verifiable cryptographic identity, with delegation and real-time revocation, so an action traces to a specific actor instead of a shared service account. And Overwatch, which scans what an agent’s tools can reach before it runs. Those are the two pillars Omnigent does not have yet, arrived at from the opposite direction, by needing them.
What’s still unsettled
Three honest caveats, because the layer is new.
Omnigent is alpha. It was open-sourced in June 2026, and its governance is, for now, vendor-described rather than independently audited. The architecture is in the open and readable, but “the sandbox is strong” is Databricks’ claim until someone tries to break it.
The landscape churns monthly. In the months before this was written, Crystal was renamed, Vibe Kanban’s company shut down, and Omnara archived its original repo and pivoted. Any specific tool named here may have moved by the time you read it. The buckets are more durable than the logos in them.
And the boundary is not fixed. The community tools that span harnesses without governance, ivy-tendril, jean, ORCH, are one release away from adding a policy layer and joining the third bucket. If they do, the category of one becomes a category, and the interesting question shifts from who has governance to whose governance you would actually trust.
For now the question to carry back to your own stack is a simple one. If you are running more than one coding agent at work, where do the guardrails live: inside each agent’s prompt, or in a layer that sits above all of them?
Status and further reading
The meta-harness is new and the landscape around it changes monthly. Treat tool specifics as a moving target and the three buckets as the durable part.
- Omnigent (Databricks, Apache 2.0, 2026) — the meta-harness this post is built around. Launch post.
- Beyond Static Sandboxing: Learned Capability Governance for Autonomous AI Agents (Sidik and Rokach, 2026) — measures capability overprovisioning in open-source agent runtimes; the source of the 15× figure.
- Governance Architecture for Autonomous Agent Systems (Ge, 2026) — the four-layer governance model: sandbox, intent check, zero-trust identity, immutable audit.
- ZeroID (Apache 2.0) — verifiable per-agent identity with delegation and real-time revocation; the identity half. (Disclosure: built at Highflame, where I work.)
- Overwatch — scans what an agent’s tools can reach before it runs; published on npm. (Also Highflame.)