Harness vs Orchestrator

Overview

Everyone is racing to build a smarter AI agent. OpenClaw, Hermes, Copilot, Cursor — they all want to hand you one agent that can do more. I went down that road too, and it never fixed my actual problem. There are two completely different things being called an "agent" right now, and mixing them up is the whole confusion. One is a harness. The other is an orchestrator. Only one of them stops you from babysitting.

Two things called "agent"

When people say "agent," they usually mean one of two very different things.

A harness wraps a model with tools, memory, and skills so one agent can do more. But a human still drives every task. The unit of work is a chat. You talk to it, it acts, you read the result, you steer it again.

An orchestrator is a different thing entirely. It manages the board, dispatches agents on its own, and keeps the work moving until it's done. The unit of work is an issue, not a chat. You don't talk to it. You give it work.

That distinction sounds small. It's actually everything.

What a harness is

OpenClaw is a harness you talk to through Signal or Telegram. Its creator recently joined OpenAI and set up a foundation around it. Hermes Agent, from Nous Research — the harness, not their language models — is a self-improving personal agent that runs on your own server. Both are genuinely good at what they do.

But notice what they have in common: they make one agent more capable, while you stay in the loop on every task. A better harness gives you a smarter assistant. It does not give you fewer things to drive.

Why a smarter harness doesn't fix babysitting

Here's the part nobody says out loud. Even with the best harness in the world, you are still the one driving every single task. You write a prompt, you wait, you read what it did, you nudge it, and then you jump to the next one. Across a handful of projects, that context switching becomes a tax. You stop being the engineer and become a message bus.

A smarter agent just gives you a smarter thing to babysit. The bottleneck was never the AI — I had plenty of unused credits sitting there. The bottleneck was me. I didn't want a smarter agent. I wanted to stop being the bottleneck.

Loops are the new meta — and they still don't solve it

Right now the hottest thing in AI is loops. Loop engineering, /goal and /loop commands, run-until-done. And loops are genuinely good: a single agent can keep going on its own — write a feature, run the tests, fix its own failures, and iterate until it's green.

But a loop is still one agent, on one task, in one tab. Run five of them and you're right back where you started — babysitting five sessions, switching from tab to tab, with no single view of where any of it stands. To check progress, you open each tab, one at a time. A loop goes deep on one task; it doesn't give you the board. In Detent, the loop runs inside the orchestration — each issue's agent loops through your workflow and gates — while the whole fleet stays on one board.

Chat is the wrong place to manage work

There's another reason the harness style isn't for me, and it's about where the work happens. Everybody is rushing to let you run your agents from Slack, Telegram, or Signal — right on your phone. I get the appeal: it's mobile, it's always with you, and it feels easy to keep things moving.

For me, that's the last place I'd ever want to manage my work. I have no interest in running real projects from a chat thread, and the last thing I need is one more place to chat with an AI and untangle threads. A wall of threads is a nightmare to follow.

I work in GitHub. I work on Kanban boards. That's where I can see everything at a glance and move across it without losing the thread. Scanning a board is far easier than digging back through chat history to remember what each agent was doing. The interface is the work — and a board beats a thread. That's a big reason I went with an orchestrator instead of a chat-driven agent.

What an orchestrator does

So I stopped managing agents, and I started managing the work. That's what Detent does.

A good issue is a real spec: the scope, the tests, the review gates, the merge rules. You write it once, mark it ready, and walk away. The work lives on a board, and the board is the state machine: To Do, In Progress, Human Review, Merging, Done. That board is Detent's own — a live Kanban dashboard with a web and terminal UI. You can back it with GitHub Projects, or run it boardless, straight from your repo's issue statuses, with no GitHub Projects or Linear required.

Detent claims the issue, spins up an isolated git worktree, and runs an agent through your workflow. When the agent finishes, it hits a validation gate that looks at the whole picture — the issue, the comments, the pull request, and the code, not just the diff. Then comes the part that makes parallelism safe: a serialized merge train. The Merging lane is locked to exactly one at a time, so ten agents finishing at once can't invalidate each other's CI.

The orchestrator itself is dumb on purpose. All the intelligence lives in your WORKFLOW.md — the board binding, the agent prompt, the gate, the merge rules. Its only job is to keep every issue moving forward by the rules you set. That is the part that babysits the agents, so you don't have to. And it scales sideways: for a big job, you run a fleet across multiple machines and accounts, each with its own budget. You watch all of it from a real operator surface — a live dashboard with charts, trends, timelines, and budget and rate-limit state — not a chat log.

Why not Symphony?

That phrase — manage work, not agents — isn't even mine. It comes from OpenAI's Symphony, and Symphony is where I got the idea. It mirrored almost exactly what I'd been doing by hand. So why didn't I just use it?

It's written in Elixir and the project is closed — no pull requests, and they've said they won't maintain it. I write everything in Go. And it's wired to Linear, when I'd rather be on GitHub. So I took the idea and shipped my own system, with the disciplined parts built in.

The honest comparison

Here's how Detent stacks up against the tools around it.

Detent owns the orchestration loop: GitHub-native status, deterministic gates, a serialized merge train, budget caps, fleet governance, and a single static binary you set up in minutes. Credit where it's due — Copilot and Cursor have closed a lot of the "runs near my code" gap, and they win zero-install inside their own platforms. But they don't give you a board-native release runtime that you control.

Set up by your agent

One more thing I feel strongly about: we shouldn't be the ones reading install docs and running setups anymore. That's the AI's job. Detent is built to be installed by your agent. The prerequisites are small — the Codex CLI and the GitHub CLI with the right scopes — and Detent itself is one self-contained binary. You point your agent at the repo and tell it to onboard the project. It runs a runbook through phases zero to seven: it discovers your stack, asks you the real decisions, writes your WORKFLOW.md, registers the project, and smoke-tests a single issue end to end before you trust it with more.

Where it's going

A lot of this already shipped — the native Kanban dashboard and boardless mode are live today, so you can run the whole flow from your repo alone. Where it's headed is the same orchestration shape beyond code: the validation gates are pluggable now, so the next domain is work that ends in a deliverable, not only a pull request. And the agent backend is a config seam. Codex runs it today, because that's the economics that work for running agents around the clock, and the door is open for other models as their automation terms allow.

The takeaway

This was never about burning the most tokens or writing the most code. It's about real engineering, done efficiently and at scale. I encode my process in a workflow, and a system runs it with isolation, gates, and a serialized merge train. The agents do the work, I manage the work, and there's very little rework.

So here's the bottom line. If you want a smarter assistant, use a harness. If you want to stop babysitting, you need an orchestrator. The repo, the docs, and the orchestration template are all on GitHub. Point your agent at it and let it onboard itself.