Stop Managing Agents. Manage Work.

Overview

I've been orchestrating multiple Codex and Claude sessions by hand for about six months. Not vibe coding — strict, my skills, my workflows. And what I kept running into was the context switching: jumping project to project, trying to manage multiple boards at once. It's virtually impossible. The kicker is it was never an AI problem. I had tons of AI credits sitting there unused. The bottleneck was me. So I built Detent — a system, not an agent — that runs my board, my workflow, and my merge train. This post is the deep-dive version of the video.

The bottleneck is you, not the AI

Everybody has a coding agent now. Maybe you're running three of them, maybe ten, in separate terminal tabs. And if you're being real about it, you're babysitting every one. Write a prompt, wait, read what it did, nudge it, copy the result, jump to the next one — and you've already lost the thread on the first.

That context switching is a tax. You stop being the engineer and become a message bus. And after all of it, a good chunk of what comes back is slop. It's tempting to blame the model, but the model is great. It just doesn't know your tests, your review gates, or your definition of done. So it improvises. That's where slop comes from.

What Detent is

A detent is the little catch in a mechanism that holds a moving part in place until you deliberately release it. Think of a camera dial clicking into each setting. That's the whole philosophy: Detent holds each piece of work at a stage and only lets it advance when a gate passes.

It's board-driven work orchestration, shipped as a single Go binary. The most important part: it's a system, not an agent. You don't chat with it. You give it work, and it runs that work through a disciplined pipeline. The work lives where it already lives — issues on a GitHub Projects board — and the board itself is the state machine: To Do → In Progress → Human Review → Merging → Done.

Manage work, not agents

This is the mindset shift. When you manage agents, your whole day is prompts and patience. When you manage work, your job is the spec. A good issue is a real spec — the scope, the acceptance criteria, the tests, the review gates, the merge rules. You write that once, mark it ready, and walk away. Detent claims the issue, sets up an isolated workspace, dispatches an agent, runs your validation gate, opens a pull request, and moves the card across the board.

And how hands-on you are is up to you, per project. Some projects, I let the work move on its own — the gates I set up decide when something advances. Others, I keep a tight grip on: nothing leaves Human Review until I move it to Merging myself, after I either approve it or send it back for rework.

# Default: command gate — move on its own once these pass
gate:
  mode: command
  require_automated_review: true   # linked PR + green CI + no P1 findings + quiet period

# Or: nothing leaves Human Review until I move it myself
gate:
  mode: human_review
  approval_label: human-approved

That phrase — manage work, not agents — isn't mine. It comes from OpenAI's Symphony. Which brings up the obvious question.

Why not Hermes, OpenClaw, or Symphony?

There are two completely different things being called an "agent" right now, and conflating them is the whole confusion.

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. OpenClaw (whose creator recently joined OpenAI and set up a foundation around it) is a harness you talk to through Signal or Telegram. Hermes Agent from Nous Research — the harness, not their language models — is a self-improving personal agent on your server. Both make one agent more capable while you babysit it.

An orchestrator manages the board, dispatches agents on its own, and keeps work moving until it's done. That's OpenAI's Symphony (as a spec), and Detent (as a shipped system).

Symphony is where I got the idea — it mirrored almost exactly what I was already doing by hand. So why didn't I just use it? A few reasons: it's written in Elixir and the project is closed (no PRs, and they've said they won't maintain it); I write everything in Go; and it's wired to Linear, where I'd rather be on GitHub. Detent can run on Linear too — I'm just not dogfooding it that way. So I took the idea and shipped my own system, with the disciplined parts built in.

How it actually works

Every issue gets its own isolated git worktree — Detent creates it, derives a branch, runs your hooks, and cleans it up natively, no bash glue. Whether each worktree also runs on its own ports and database is your project's setup, not something Detent enforces — but that combination is what lets dozens of issues run at once without stepping on each other's tests or data.

When an agent finishes, it hits the validation gate, which looks at the whole picture — the issue, the comments, the PR, and the code, not just the diff. Then comes the part that makes parallelism safe: the 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. Each one rebases onto a fresh main, runs a focused smoke gate, watches CI, and merges.

# The Merging lane is serialized — exactly one at a time
agent:
  max_concurrent_agents_by_state:
    Merging: 1

The single most important file is your WORKFLOW.md — the board binding, the agent prompt, the validation gate, the merge rules, all in one contract. As the docs put it: the intelligence stays in your spec, and the runtime supplies the discipline. Detent's orchestration is intentionally kind of dumb. The smarts are in the workflow you give it, so it works exactly like you would.

Set up by your agent

Now the part I have a strong feeling about. I won't pretend AI-driven setup is brand new — OpenClaw walks you through a setup too. But having the AI set you up is just better: it can adapt to your system, to the things you could never predict and bake into an install script. I want AI-first for everything now. We should not be the ones reading install directions and running setups. That's the AI's job. Our job is to give the AI everything it needs to work the way we work, and let it ask us the questions as it goes.

Detent is built for exactly that. The prerequisites are small — the Codex CLI and the GitHub CLI with the right scopes — and Detent itself is one self-contained binary.

# Detent is one self-contained binary — pick one
brew install digitaldrywood/tap/detent
# or:
curl -fsSL https://raw.githubusercontent.com/digitaldrywood/detent/main/install.sh | sh

$ detent doctor
Detent Doctor
STATUS  CHECK
OK     GitHub token scopes
OK     codex binary
OK     SQLite database
Summary: 10 OK, 0 WARN, 0 FAIL
Result: OK

Then you hand it to your agent: "read the Detent repo and onboard this project." It follows an agent-executable runbook — figures out the mode, runs through phases zero to seven, discovers your stack, interviews you for the real decisions, creates the board, writes your WORKFLOW.md, registers the project, and smoke-tests a single issue end to end before you trust it with more.

What's next

I'm building a native Kanban board into Detent. By the time you read this, it's probably already shipped — and it means you can run Detent without GitHub Projects or Linear at all. It just reads your GitHub issue statuses and drives the lanes right on the Detent dashboard. The whole board, the whole flow, with nothing but your repo.

The other thing: Claude just walked back a change, so you can use the CLI with your subscription again. Which means I'll probably be adding Claude support back into Detent, alongside Codex. The Fable model is genuinely amazing — it can run on its own for days, it checks its own work, and right now it's the top model on the frontier coding evals. Running a model like that inside Detent's discipline is exactly where I want to take this.

The takeaway

AI slop isn't a feature of the tools. It's a choice. I write detailed issues, I encode my engineering process in a workflow, and I let a system run that process with isolation, gates, and a serialized merge train. The agents do the work. I manage the work. And there's very little rework compared to what it used to be.

The repo, the docs, and the orchestration template are all on GitHub. Go point your agent at it and let it onboard itself.