The Manager Needs a Desk

The first time I had five agents running at once, I lost track of which was which. One was halfway through a refactor. One had finished and was waiting on me. Two were blocked on something I couldn't see from where I was sitting. The fifth — I genuinely could not have told you. I was the bottleneck, and not in the interesting way. I'd been promoted to manager, and I was managing from memory.

Last post I argued that the moment you hand an agent a real task and it runs its own loop, you've been quietly promoted. You're not the one doing the work anymore. You're the one deciding what work to do and whether it came back good. That's management — the actual craft of it, not the calendar kind. I also admitted the two manager's habits I wasn't yet doing myself, the ones that jumped off the page when I read Kun Chen's setup.

This is me fixing the first one. And building the desk I should have had from the start.

The habit I never built

Here was the gap. Ask any engineering manager if they read every line their team ships and they'll laugh — they can't, and they stopped trying years ago. What they insist on instead is two things: somebody other than the author reviews it, and there's evidence it actually runs before it merges.

I did the second one religiously. I make agents prove a change works end to end. The first one I just… didn't. If you ask the same session that wrote the code to review the code, you're asking it to grade its own homework — it assumes its own choices were right and waves them through. I had the pieces to fix this. Claude Code ships a /code-review that runs in a clean context. I just never reached for it by default.

The reason that matters more now than it did a year ago is a shift in where the work actually binds. When an agent can produce a correct-looking pull request in ten minutes, producing the change stops being the expensive part. Trusting it becomes the expensive part. I can now open more PRs in a morning than I can carefully read in a day.

When producing a change costs almost nothing, the only thing that still costs something is trusting it.

So discipline was never going to fix this. "Remember to run the reviewer" is a habit, and habits fail exactly when you're busy — which is precisely when five agents are running and you're managing from memory. The fix had to be structural: a system that reviews the work for me, before the work ever reaches my desk. So I built one. It's a small, local-first kanban called Agent Task Board, and the rest of this is what it does and why it's shaped the way it is.

The board is the desk

The board has four lanes, and they aren't decoration — they're the delegation lifecycle written down: Queued → Running → Review → Done. A prompt I've drafted but not handed off sits in Queued. The moment an agent picks it up it moves to Running with a live timer. When the agent's done, it lands in Review — the human gate. When it's shipped, Done.

That's the whole point of the thing. A manager with one report doesn't need a dashboard; they can hold it in their head. The leverage shows up when several things run at once, and the instant that happens you need to see, at a glance, which agent is working, which is done, and which is blocked waiting on you. That single glance is what I was missing when I lost track of agent number five. Kun solves the same problem with a terminal pane per task and the status in the tab title; I wanted a board, because a board is the surface I already think about work in.

It's local-first on purpose. The board lives in your browser's localStorage — no account, no backend, nothing leaves the machine. You can use it as a plain manual tracker for weeks before any agent ever touches it. That isn't a limitation I backed into; it's the first rung of an adoption ladder I'll come back to.

Deterministic handoff, isolated work

Delegating has to be frictionless or you won't do it, so the front door is a Telegram bot. I text it /myapp add a health-check endpoint — the leading /myapp is a slash command that picks which repo the task runs in, the rest is the work. I never have to remember the exact name: every folder under my code directory is registered as a Telegram command with autocomplete, so I just type / and tap one from the menu, and a repo I created this morning is already in the list. A manager checks in on the team from wherever they are; the work shouldn't pause because I stood up from the desk.

From there a dispatcher does the actual handoff, and three design choices in it matter more than the rest:

• One task, one agent. Claims go through a mutex, so a task is atomically pulled off the queue and assigned. Two agents can never grab the same card and clobber each other.
• Every task in its own git worktree. Each task runs in an isolated checkout of the repo on its own branch. Your main working tree is never touched, and concurrent tasks — even two on the same repo — don't collide. This is Kun's treehouse instinct, except the dispatcher manages the worktree itself so I never think about where to put a task.
• The dispatcher drives git, not the model. For code tasks the agent is told to only edit files — don't touch git. The dispatcher commits, pushes, and opens the PR. That's deliberate: git is too important to leave to whether the model remembered to stage the right files. It's deterministic because a script does it the same way every time.

And it's dry-run by default. Out of the box the dispatcher prints the command it would run and touches nothing; you pass --execute when you're actually ready for agents to run commands on your machine. Delegating real authority should be a thing you opt into, not a thing that happens because you cloned a repo.

The output of all this is the choice that took me the longest to settle on: a finished task arrives in Review as a real pull request, not a wall of agent output. Passing tests is a claim. A PR is the artifact you can actually review — a diff, a branch, a thing you can check out and run. If the work is going to face a reviewer, give the reviewer something reviewable.

Don't let an agent grade its own homework

This is the part I built the whole thing for.

Before a PR ever opens, the dispatcher can run an independent review-and-fix loop inside that same worktree. A fresh claude process reviews the diff — and "fresh" is the entire trick. Every claude -p is one-shot, so the reviewer has genuinely no memory of having written the code. It's not the author grading its own homework; it's a different person walking in cold, which is exactly the constraint a real second reviewer brings, and here it costs almost nothing to spin up. Alongside the review, the loop runs the repo's own checks — it auto-detects the project's lint, typecheck, and test scripts and actually runs them. A fixer process then iterates on whatever comes back, until the change clears the gate or hits a cap.

The gate is the part I'm most opinionated about. It passes only when all three of these hold:

• the repo's checks are green, and
• the reviewer reports zero blocking findings, and
• the reviewer's confidence clears a threshold (default 95%).

The third condition is soft, and I don't trust it on its own — an LLM's self-reported confidence number isn't calibrated; it'll tell you it's 97% sure of something broken. So I anchored it to the two signals that are trustworthy: the hard one (real test runs either pass or they don't) and the concrete one (a blocking finding points at a specific line). The confidence score only gets to matter once the checks are green and nothing's flagged. A soft signal is useful exactly when it's pinned to hard ones.

And it fails open, not closed. If the loop burns through its fix rounds without clearing the gate, the PR still opens — but flagged, with the unresolved findings folded into the card and a ⚠ Flagged on the Telegram message. A gate that silently blocks work trains you to route around it. A gate that says "this one's through, but look here" keeps you in the loop without becoming the bottleneck you built it to remove. The whole point was to stop being the thing every change waits on.

So the PRs that reach my Review lane have already been read by something other than their author, and run against the project's real checks. That's the manager's habit I never built, turned into a property of the system instead of a thing I have to remember.

Why I didn't just install Kun's

Kun built this exact reflex into a tool he calls no-mistakes — fresh-context peer review, end-to-end evidence, CI babysitting, the works. The stat that stuck with me from his writeup: 68% of the changes he pushed through it had bugs the pipeline caught. More than two in three. That number is the entire argument for why the author can't be the reviewer.

I looked hard at adopting it directly. I didn't. It's a heavyweight push-proxy daemon, and most of what it does overlapped with the board I already had — I'd have been bolting a second control plane onto the side of mine to get a feature I could express as one loop inside the dispatcher. So I built the lighter, board-shaped version: same principle, fewer moving parts, living where my work already lives.

That's the real lesson from the last post, and it's worth saying plainly because it's easy to read "Kun built X" as "go install X." The win was never his specific tools — most are built for his own friction, on his own machine. The win is the reflex that produced them: notice the thing slowing you down, then either find the tool that kills it or build the small one that does. Mine came out shaped like a kanban because that's how I already picture a team of agents. Yours might be a different shape. The shape isn't the point. Refusing to keep paying the same friction is.

Merging is the approval

A manager doesn't hover over the last mile, so the board doesn't make me either. A merge-watcher polls every PR sitting in the Review lane, and the moment one gets merged it moves that card to Done on its own and pings me that it shipped.

That collapses the final step. Merging the PR is the approval — I review and merge on GitHub the way I would any PR, and the board keeps itself in sync without me dragging cards around. The loop closes whether or not I'm looking at it.

Putting one on your own desk

The thing I'd most want you to take from this is the adoption path, because it's the part that's easy to get wrong. You don't flip on a swarm of autonomous agents on day one. You climb:

1. Track by hand. Run the board local-first and just use it as a tracker for the work you're already delegating. No agents, no server, nothing leaves your machine. You learn whether the four lanes match how you actually work before you automate anything.
2. Go live, still dry. Switch the board to its server-backed mode and bring up the agent layer with one command. The dispatcher claims and routes tasks but runs nothing — it shows you what it would do. You watch the routing without granting it any authority.
3. Grant execution. Add --execute when you trust the routing. Now agents actually run, open PRs, and fill the Review lane. You're managing a real team.
4. Turn on the gate. Switch on the independent review loop, per-route or globally. From here on, the cards that reach you have already been reviewed and checked.

One architectural decision is what makes that ladder possible: the browser board and the server-backed board run the same core logic underneath — one pure reducer, two engines plugged into it. The manual board and the live board behave identically because they are identical where it counts. That's why step 1 isn't a throwaway demo you abandon at step 2; it's the same board, with more of it switched on.

What it can't do yet

I'd rather be honest about the edges than oversell the thing.

It doesn't orchestrate through context limits. Every task assumes it fits in a single agent run. The genuinely big jobs — the ones that need to be broken into steps, each in a fresh context seeded by what the last one learned — are exactly Kun's gnhf, the second habit I admitted I was missing and still am. The board manages a team; it doesn't yet manage a project that outlasts one context window. That's the next thing I want.

The review is one reviewer, not a panel. A single fresh agent catches a lot, but real review benefits from diverse angles — one pass for correctness, one for security, one that just tries to make it break. Fanning the gate out into a small panel of perspective-specialized reviewers is a clear upgrade I haven't built.

It reviews, but it doesn't plan. The board picks up at "here's a task" and carries it to "here's a merged PR." The highest-leverage artifact in the whole loop — the plan you argue with before a line gets written — lives entirely outside it. Kun's lavish-axi renders a plan as an interactive page you click through before approving. A planning lane is the obvious missing front of the board.

And it flags, but it doesn't escalate. When the gate can't clear a change it marks it for me; it doesn't yet do what no-mistakes does and kick the genuinely ambiguous product call — the "should this even behave this way" question — back up to me as a decision rather than a flag. Some calls aren't the reviewer's to make, and the system should know the difference.

The desk is the point

Step back from the parts and the pattern is the same one from the last post, just hardened into wood and screws. The unit of engineering work used to be the file. For a while it was the prompt. It's becoming the review verdict — the judgment about whether a change you didn't write is good enough to ship.

Everyone has the same models. That stopped being the edge a while ago. The people who pull ahead over the next year won't be the ones generating the most code — that's nearly free now, and a free thing is a bad thing to compete on. They'll be the ones who built a system that can trust the output at the rate they can produce it. Generation got cheap. Verification didn't. The whole game is closing that gap without putting yourself back in the middle of it.

The last post ended on a question — not whether you're a manager, but whether you're a good one. Here's the answer I've landed on. A good manager isn't the one who reviews everything. It's the one who built a team that's safe not to watch. The desk is how you get there.