A meta-harness is coordination that lives outside the agents

I run several coding agents against the same change: one implements, two review it from different angles, and I carry the findings back. The agents are fine at their jobs. The coordination between them is done by hand, by me, and this post designs the layer that would do it instead. Everything here is a design; the build video is where it meets a real run.

There are reasons I split the work across sessions rather than asking one agent to do all of it. I don’t want the reviewer holding the entire implementation conversation, because an agent that watched the code get written is not an independent reader of it. I don’t want every reviewer on the same harness and the same model, since two instances of the same setup tend to miss the same things. And I don’t want a reviewer that is supposed to be read-only quietly editing the code it was asked to inspect.

So I decide which agent runs next. I copy artifacts from one session into another. I remember which commit the reviewer actually saw. When one of them fails I decide whether to retry it or keep the result from the other. I enforce the review order, the revision limit, and the final handoff to myself. That list is a job description for software I haven’t written, and at the moment I am the software.

One level above the harness

An agent harness coordinates the model, tools, context, memory, permissions, and execution environment for a single agent loop. That’s the layer this series mapped and then built, as Carbon, the from-scratch coding agent (renamed from Gemma since that post). A meta-harness sits one level above it and coordinates multiple harnessed agents as workers inside a larger system.

The claim I want to test across this design and the build that follows: moving coordination outside the agents means the system stops depending on one supervisor model behaving perfectly. It’s testable. If a worker goes off track, times out, ignores an instruction, or returns the wrong shape, the outer system should contain that and decide what happens next, without the worker having to notice its own failure.

The way I got to the architecture was to start with the smallest thing that could work and add a component only when the previous version stopped being able to answer a question. Eight of them ended up earning their place. I wanted none of them to be there as decoration.

The workflow I want to run without me

The meta-harness I’m building to explore this is called Bhai, short for Blueprint Harness for AI. The goal is one runtime that can operate many software lifecycle workflows, each with its own workers, permissions, control flow, state, and human gates: triage an issue, investigate a failure, produce a plan, implement a change, review it, verify, prepare a release, respond when production breaks. Rather than hard-coding each of those into the runtime, Bhai treats every workflow definition as a versioned blueprint. A source such as GitHub, Jira, CI, a schedule, or an API triggers a run, the trigger selects a blueprint, and the runtime coordinates the workers that blueprint names.

One implementation blueprint carries the whole design here. An architecture that only works for a single hard-coded path is an automation script; a reusable runtime has to take other blueprints without being rebuilt around each one.

At the top, it’s about ten lines:

candidate = await run(implementer, task)

reviews = await parallel(
    run(correctness_reviewer, candidate),
    run(security_reviewer, candidate),
)

findings = await run(consolidator, reviews)

if findings.blockers:
    candidate = await run(implementer, fix(findings.blockers))

return await human_handoff(candidate, reviews, findings)

That already beats opening four terminals by hand, and it’s nowhere near a system. Run it again next week and the questions start. Which model did the reviewer use, and which instructions? Did I change its system prompt since the last run? Codex wants a CLI invocation while Carbon is imported as a Python library, so where does that difference live? Where are the timeout and sandbox settings? Can another workflow reuse the same reviewer? The script has hidden the worker definitions inside functions and local assumptions.

Why a supervisor agent is not enough

The obvious multi-agent shape is a supervisor with sub-agents: the supervisor takes the goal, delegates the implementation, calls the reviewers, reads what comes back, asks for a revision, and decides when the work is done. It’s a legitimate pattern with prior art. Anthropic describes a lead agent for its research system that analyzes the query, develops a strategy, and “spawns subagents to explore different aspects simultaneously.” Databricks’ Omnigent ships Polly, documented as “a supervisor that never writes code itself,” decomposing a goal and giving each sub-task “its own harness and git worktree.” For open-ended work, a supervisor makes calls that would be awkward to encode ahead of time.

The cost is that the supervisor is now on the control path. It has to remember which branches finished, interpret every output, count revision rounds, preserve artifacts, handle a dead worker, and decide whether a human gate may be crossed. Some of that is judgment and some of it is bookkeeping. I’m comfortable asking a model whether two review findings describe the same underlying bug. I’m much less comfortable asking it to hold, correctly, across a long context, that the security reviewer timed out, the correctness review is still valid, the revision limit is one, and the final candidate must never be merged automatically. Those rules get easier to inspect and test the moment they live outside every model.

The system can still use supervisor agents wherever judgment helps. What it avoids is making one supervisor responsible for the integrity of the whole workflow.

What can run, and how to invoke it

The first thing the script can’t answer is what it is actually running. So every reusable worker gets an inspectable package, and a folder is a practical format: the harness, the default model, base instructions, tools and skills, expected input and output, environment requirements, resource limits. The agent package registry gives that package an identity and a version, so a workflow can ask for [email protected] instead of depending on whichever prompt happened to be inside run_carbon_review() that day. Omnigent’s custom agents are the same boundary in a shipped product: an agent lives in its own directory and declares its prompt, its executor harness, and its tools in YAML. The format matters less than the boundary, which answers what worker exists and whether its configuration can be reproduced.

That settles identity and packaging, and leaves execution wide open. Carbon exposes a Python SDK, Codex is a CLI, another harness might be an HTTP API or a streaming protocol with its own session semantics. If every workflow has to understand all of that, the glue code has only moved into a new folder. The harness adapter layer puts one contract in front of them: start, events, cancel, result. Under it, the Carbon adapter constructs an agent through the SDK, the Codex adapter launches a headless process and collects a structured result, and an adapter for the Agent Client Protocol could talk to any agent that implements it.

The contract shouldn’t pretend the harnesses are equivalent, because they aren’t. One supports session resume and another doesn’t. One emits tool-call events, another returns text. One cancels cleanly, another can only have its process killed. So each adapter carries a capability description alongside the contract, something as plain as {"streaming": true, "cancel": false, "resume": true}, which stops a workflow from assuming a feature the selected worker cannot provide. Omnigent’s harness interface is the strongest existing demonstration of this layer, wrapping Claude Code, Codex, Cursor, OpenCode, Hermes, and Pi behind a shared runner while keeping their differences underneath.

What it is allowed to do

A package still doesn’t know why it’s in this workflow. The same Carbon coding package can be an implementer in one step, a read-only reviewer in another, and a consolidator that never touches the repository in a third. Those are different authorities, so the stable makeup stays in the package and the role and policy binder attaches it to a workflow role at runtime. The effective worker is the package defaults plus the workflow role, plus the task artifacts, plus the runtime policy, under the organization’s policy ceiling.

Authority narrows on the way down that stack and never widens. If the package asks for repository write access and the role is read-only, the answer is read-only. If the workflow allows network access and the organization denies it for this repository, the answer is no network.

A role that says repo:read is still only a sentence until something enforces it, which is the execution environment manager: workspace or Git worktree, writable and read-only paths, network rules, secret delivery, sandbox selection, CPU and memory and disk limits, local or remote placement. For the running example that means the implementer gets a writable checkout, both reviewers get clean read-only views of the same candidate commit, the consolidator gets review artifacts and no repository at all, and none of them get merge or deployment credentials. It also fixes a quiet problem with running agents on a developer laptop, where a planning agent inherits my ability to push and a security reviewer inherits whatever production credentials happen to be in the shell. Which mechanism actually enforces that boundary, and how much it contains when it fails, is the blast radius question from earlier in the series, now applied per worker rather than per agent. Omnigent goes further than a static flag here: its contextual policies track session state, so you can say that after an agent downloads a new npm package it needs human approval to git push. Authority that changes with what already happened is more useful than a boolean set at startup.

How work moves, and who owns a worker’s life

Four configured workers sitting in a registry are still four configured workers. The workflow engine defines how work moves: sequence, fan-out, joins, conditions, bounded loops, failure paths, human gates.

I’d write that in code. Static worker makeup sits fine in YAML, but once the YAML acquires parallel, map, reduce, retry, and a gate expression, it’s a programming language with worse debugging. Workflows have real behavior, so ordinary Python is a reasonable representation, versioned as a blueprint, with the same engine executing different blueprints for planning, implementation, review, testing, or release:

@workflow("implementation")
async def implementation(ctx, task):
    candidate = await ctx.run("implementer", task)

    reviews = await ctx.parallel(
        ctx.run("correctness_reviewer", candidate),
        ctx.run("security_reviewer", candidate),
    )

    consolidated = await ctx.run("consolidator", reviews)

    if consolidated.blocking_findings:
        candidate = await ctx.run(
            "implementer",
            FixRequest(candidate, consolidated.blocking_findings),
        )

    return await ctx.human_handoff(
        CandidatePackage(candidate, reviews, consolidated)
    )

The agents still make every judgment call inside the steps. What the code owns is the transitions around them: both reviews finish before consolidation, the revision loop runs at most once, the terminal state is awaiting_human rather than merged. None of those guarantees depend on a model remembering them.

That ctx.run() looks simpler than it is. Starting a worker is easy; controlling its life afterwards is a separate job, and the worker lifecycle manager owns it: worker and session IDs, heartbeats, timeouts, cancellation, retries, pause and resume where the adapter supports them. Capability differences turn operational right here. A worker that supports resume can continue its session; one that doesn’t may need a replacement started from a checkpoint artifact, and the system should record which of those two things happened. This is also where the bounds live that don’t belong in a prompt: maximum duration, attempts, cost, revision rounds. Asking a model to stop after ten minutes is not a timeout.

What survives, and who can watch

If the process dies after the first reviewer finishes, every useful thing may exist only in memory. The state and artifact store keeps two related records apart. Workflow state is where the process is: the run, the worker runs, attempts, current states, completed transitions, pending gates, human decisions. Artifacts are what the workers produced: the task, candidate commits, diffs, test output, reviews, consolidated findings, the final package.

Artifacts need lineage:

task
  → candidate@commit-A
      → correctness-review@commit-A
      → security-review@commit-A
          → consolidated-findings
              → candidate@commit-B

A transcript answers none of those questions cleanly. Which commit did each reviewer inspect? Did both reviews use the same acceptance criteria? Was the revised candidate reviewed again? Which findings caused the revision, and what can be reused after a failure?

That last one opens durable execution, and it’s the place I’d expect a thin prototype to be weakest. If a completed step has a valid stored result, rerunning should return it instead of repeating the work, which sounds simple until side effects show up. If the implementer created a commit before the runtime lost contact, did the step finish? If a worker opened a pull request but the completion event never arrived, should a retry open a second one? Idempotency, checkpoints, and clear ownership of side effects are what make that safe, and a JSON file provides none of them. Recording progress and being able to resume arbitrary workflows safely are two different claims, and I want to keep them separated by name.

Progress can now survive, and the workflow is still hard to watch while it runs. The event and control plane is what makes it observable: workers and the workflow emit worker.started, tool.called, artifact.created, policy.denied, approval.requested, worker.timed_out, and the rest, feeding traces, cost accounting, a UI, policy evaluation, and eventually observer agents. Carbon already has the seam on its side: an agent exposes subscribe(callback) so a driver reads its events mid-run instead of parsing messages afterwards.

Observation and control are separate capabilities. Seeing a worker call the wrong tool doesn’t let the outer system pause it, inject guidance, and resume safely; that needs an explicit control path through the adapter and the lifecycle manager. Cancel this worker, approve or deny this action, pause the workflow, record a human decision, inspect an artifact, and later steer or replace a worker. This is also where a meta-harness becomes usable by something other than the Python process that started it. Omnigent is strong here, exposing sessions through web, mobile, a macOS app, Slack, and APIs, with live shared sessions.

The architecture, and where the seams overlap

The components overlap at their seams, which I’d expect. A timeout starts as a lifecycle rule, becomes a worker.timed_out event, updates durable state, and makes the workflow engine pick a failure path. The separation that stays useful is ownership: for any decision, being able to say which component owns it and which ones merely record or enforce its effect.

Walking the running example through the whole thing: a source event arrives carrying a target repository, a base commit, the requested behavior, acceptance criteria, and the verification commands that are permitted. Intake validates it, selects the versioned implementation blueprint, and creates a run. The engine selects the implementer role, the binder resolves it against the carbon-implementer package and applies the writable-repository policy, the environment manager creates an isolated checkout, and the lifecycle manager asks the Carbon adapter to start the worker and begins recording state and events.

The implementer returns a candidate artifact naming the base commit, the candidate commit, the changed files, and the verification it ran. Before another agent ever sees it, code checks the deterministic parts: the commit exists, it descends from the expected base, the changed-file list matches the diff, the test artifact is there. Then the workflow fans out. Correctness resolves to a Carbon reviewer package, security to a Codex one. Both get read-only views of the same commit and the same task contract, and neither gets the implementer’s conversation, which is context isolation used as a review property rather than a window-size trick. Their adapters differ; their result contract doesn’t. The workflow waits for both valid artifacts, hands them to a consolidator that groups overlapping findings and keeps the source lineage, and code verifies that every consolidated finding points back to real review evidence. If blockers remain, findings and candidate go back to the implementer once, and then the run produces a handoff package for me.

If the revised commit was never reviewed again, that package says so. Provenance earns its keep partly by exposing the uncomfortable gaps a polished final answer would smooth over. At no point does any single agent have to hold the whole process; each worker gets a bounded job, and the outer system owns movement, authority, evidence, and stopping.

The timeout

Now put weight on it. Suppose the correctness review finishes, writes a valid artifact, and marks its worker completed. The security reviewer then times out.

What should happen is that the lifecycle manager records the timeout and cancels or terminates the worker through its adapter, the state store keeps the completed correctness review, and the workflow engine follows whatever failure policy the blueprint configured for that branch: retry the same worker once, replace it with a compatible reviewer package, wait for a human decision, or fail the run. What must not happen is one review quietly counting as two. And if the retry runs against the same candidate while the completed artifact is still valid, the correctness reviewer should not run a second time.

That’s the durable-execution target. A thin prototype may only manage to record the completed artifact and stop, needing a human to start a fresh run, which is partial recovery. I’m writing down both versions now, before the build, so that the difference between “we kept the file” and “the workflow resumed safely from the checkpoint” is a distinction I have to defend rather than one I can blur later.

Where this sits

Omnigent is worth mapping onto this because it’s the clearest shipped product using the term meta-harness, open-sourced by Databricks in June 2026 under the framing of composition, control, and collaboration. Its custom agent directories are package definitions. Its harness interface is the adapter layer. YAML binds model, prompt, tools, policies, and OS environment. Runner and sessions give lifecycle control. Omnibox and cloud sandbox hosts are execution environments. Contextual policies are state-aware authority. The server, interfaces, and collaboration features cover much of the event and control plane. Polly, on top of all that, is agent-led composition: a supervisor decomposing work across heterogeneous harnesses and worktrees, with cross-vendor review as the point and merging left to the human.

This design makes a different orchestration choice for repeatable engineering workflows, putting the primary control flow in external Python: which reviews run, which joins are required, how many revisions are allowed, what survives a failure, where the human gate sits. Both patterns have a place. A supervisor helps when the decomposition itself needs open-ended reasoning, and an external workflow helps when transitions, limits, evidence, and recovery have to be deterministic and testable. My guess is that a mature system uses both, with code defining the outer lifecycle and policy boundaries while supervisor agents make bounded decisions inside selected steps.

What the build has to answer

Everything above is a diagram. The prototype in the next video is a thin vertical slice through it, and the map has the intake layer, general pause and resume, complete network policy, secret delivery, remote execution, and live steering drawn dashed, because the design is currently ahead of the implementation. Cancellation is already adapter-dependent by design: a subprocess worker can be terminated, an in-process one has to be waited out.

The questions I can’t settle with a drawing:

• Can external orchestration contain a weak worker’s mistakes without depending on that worker to notice its own failure?
• Does cross-harness review surface issues that same-harness review misses?
• What actually survives when one review branch times out?
• How much recovery does a thin local runtime give before it needs a real durable-execution engine?
• Do folder-defined packages and adapters make workers meaningfully interchangeable, or do harness-specific differences leak through immediately?
• Which controls belong in deterministic code, and which decisions are still better made by an agent?

The build deliberately uses a weaker local model as one of the workers, because the interesting evidence arrives when a worker behaves badly and the system has to respond. The components here show up in the Bhai codebase as primitives, which is the vocabulary bridge between the two: components describe why the architecture needs a capability, primitives are the reusable code boundaries that implement it.

When I started moving work between several agents it felt like a prompt and delegation problem. What kept hurting was outside the prompts: worker identity, harness differences, permissions, workflow state, failures, artifacts, and human control. Eight components appeared because eight separate responsibilities appeared as I put pressure on a ten-line script. Once the same runtime can select and operate several versioned lifecycle blueprints, this stops being one multi-agent workflow and starts being the machinery underneath a team’s own software factory. Next is building the thin version and finding out where the boundaries hold.