What is a meta-harness?
A meta-harness is a layer that coordinates multiple agent harnesses: the runtimes that connect models to tools and execute their interaction loops. Coordination means assigning tasks, tracking separate sessions, passing results between agents, and collecting their work. It preserves the underlying harnesses rather than replacing them with a single agent runtime.
Last checked against Omnigent v0.19.0 · 2026-10-23
What does a meta-harness coordinate?
A meta-harness coordinates tasks, progress, and results across agent sessions. A model generates responses; a harness manages the working loop around it, including tool calls, conversation history, and permissions. The meta-harness needs to identify each session, send it a task, expose its progress, and retrieve its result. Two agents in adjacent terminal panes do not coordinate themselves.
Using more than one harness can be useful when you want an implementation checked through a different toolchain, or when different tasks need different runtime capabilities. Choose by the capabilities each task needs. You can keep the harness that already suits an editing task while choosing another for an independent review. That does not guarantee a better review; the reviewer still needs a useful brief and evidence.
For example, assign a navigation change to one agent and an unrelated feed test to another. Give each its own Git worktree and file ownership. When the navigation implementation is ready, send its actual diff to a reviewer. The independent tasks can overlap; reviewing an unfinished implementation cannot. Coordination includes deciding when work must wait.
When should I use a meta-harness instead of a single harness?
Use a meta-harness when you need cross-harness coordination or shared session controls that a single harness does not provide. Separate terminals or tmux are enough when you are happy to assign tasks and copy the important context yourself. They add little machinery, but you remain responsible for progress tracking and handoffs. A shared terminal layout is a view of processes, not a task dependency system.
A harness’s native subagents are a closer fit when all delegated work can stay within that tool’s agent system. Claude Code and Codex document native delegation; those mechanisms do not by themselves establish a common supervisor spanning both products. Omnigent is an option when you need cross-harness task assignment, session sharing, or reusable controls across runtimes; separate terminals leave that coordination to you, while native subagents stay within their harness’s delegation system.
How does Omnigent work as a meta-harness?
Omnigent coordinates supported agent harnesses through shared sessions; you still manage task briefs, checkout separation, and integration-specific limits. You can direct those sessions yourself or let a supervisor create children with sys_session_create, send work with sys_session_send, and inspect progress with sys_session_get_history. The capability is a shared coordination interface; a supervisor agent is optional. Omnigent also adds session sharing, contextual policies, and guardrails above the harnesses, with enforcement at each integration’s supported gates.
Separate sessions do not automatically share everything they have read. Pass the goal, absolute checkout path, expected result, and relevant prior findings. Creating a child does not create a Git worktree. Omnigent coordinates the conversations; Git supplies checkout separation. The host is simply the machine or sandbox where execution occurs, regardless of which interface you use.
Integration capabilities still differ, including approval handling and fork-history support. A common interface does not erase those differences or create an OS sandbox. Omnigent fits when you need that shared coordination; check the selected integrations before relying on a particular operation.