Set up your own multi-agent orchestration system on a kanban board

This is a guide to setting up your own multi-agent orchestration system, complete with a graph engineering layer and self-improving loops to further refine your agentic operating system.

In an effort to visualize my agent teams and build a single surface area to orchestrate my sessions, I came up with the idea of consolidating all of my projects into a single kanban board. Every project is a card. Agents work the cards on a schedule, hand off to each other through the card itself, and a separate agent verifies the result, and its verdict is what counts, not the builder’s. What reaches me is an inbox of the decisions that need a human.

This guide covers how the board is built, how the cards are written, how the agents hand off and get checked, and what I learned building it. If you’re already running agents and want a system instead of a pile of sessions, start here.

Master graph engineering with multi-agent orchestration

Taking a nod from one of the oldest project management tools out there, the kanban board, you can create a visual surface area to view your agent orchestration. The board becomes the interface between you and your agents. You stop reading transcripts and start reading cards.

Here’s what’s on my board:

Columns from To Do to Done, plus a Human Gate column for anything waiting on me
A card per project. The card is the brief: a goal, a plan link, and a success test written as a command and the output it must print. If I skip the test, an agent writes one for me and marks it as its own guess
A plan file behind every card that needs one, holding the steps, the decisions I locked, and a resume point so any agent can pick it up cold
A schedule that fires whether I’m at the desk or not
An inbox on my dashboard that shows me only the cards that need a human answer

Two ideas make it more than a to-do list.

Graph engineering. A graph is a set of things connected to other things. Graph engineering is what you do when one agent loop is not enough: you wire separate loops together, and the wiring itself, what runs next and what it gets handed, becomes the thing you design. On the board, a card can depend on another card. A card can spawn child cards and wait for them. Before any agent starts, a check reads those links and only hands out work whose prerequisites are finished and checked.

Dependencies live on the card, not in my head
A goal card can hold a whole project while its children carry the steps
Blocked work stays visible instead of quietly stalling in a session

Multi-agent orchestration. More than one agent works the same job in turns, and the card is the shared memory between them.

An agent claims a card, does one pass, writes what it did and what comes next, and exits
The next agent reads that note and continues from there
Every card has a hard cap on passes, so nothing loops forever
A separate agent that never saw the work runs the card’s end-state check and gives the verdict

Self-improving loops. The system keeps score on itself. When the same failure reason shows up on more than one card, the system raises it as its own card, and an agent drafts the exact rule change that would have prevented it. A second agent tries to refute the change. If it survives that attack, I get one plain question. The first one never reached me. The second agent killed it first, which is exactly what I built it to do. Nothing rewrites the rules without a recorded yes from me. The result is an agentic operating system that gets tighter with use.

What I was trying to do

I’m a visual person. Working across multiple agent sessions, I couldn’t see what any of them were doing or whether the thing I’d asked for had actually happened. I wanted to practice multi-agent orchestration, and it turned out I was already doing it. I just couldn’t see it well enough to believe it.

I also wanted a real project tracker. Those felt like two problems until I realized they were one screen: the graph, the loops, the agents, and my own to-do list, all on the dashboard I already open every morning.

The rules that came out of building it:

A card is a whole project, and the steps live in a plan file the card points at
Whoever builds the thing doesn’t get to say it worked
Five kinds of decisions reach me: security, anything I can’t undo, anything going out under my name, anything expensive, and a change of goal
An agent can plan work for other agents, but it can never run its own plan, and anything it merely stumbled on waits for my yes

What shaped it

Tonbi’s AI Garage, “I Built the Ultimate Multi-Agent Workflow w/ Hermes Agent Kanban Board.” The board and the inbox screen came from here, down to a card opening into its own full page.
Nate Herk’s Claude agent-team walkthrough. He warns against a team of agents all writing into one document. I split every plan into its own file the day I watched it.
Grok Bot. A fleet of always-on teammates that never sleep. That was the shape I wanted, but they live on someone else’s computer, so they can never touch my files. I built my own.
Buzz, my own agent crew. It taught me the lesson that made the board click: agents only hand work to each other when they’re in the same room. The board is that room.

What’s in the rest of this guide

How to write a card an agent can run and a stranger can check
The handoff pattern, and why one pass per agent beats one agent per project
The independent check, and what happens when it fails
The five decisions I kept, and the written profile that lets agents decide the rest
The self-improvement loop, step by step
What others are doing with boards, and the two things I haven’t seen anywhere else

This is the way I do it. There’s no right way. Let me show you the cards.

Put the whole job on the card, then let the worker die

Four columns. To Do, Doing, Human Gate, Done. Work lands in Done when a worker believes it is finished, and a separate check decides whether it stays. The furniture is the boring part.

Here is a whole card, the way I write one:

Rebuild the footer on the guides pages

Done = every page under /guides carries the new footer, and
       `npm run build` finishes with no ERROR line in build.log
Role: builder

--- handoff, written before the worker quits ---
Leg done: rewrote the footer component, updated every guide layout
Do not redo: the CDN purge. It was never the cause.
Next leg: run the build, then hand to verifier

That Done = line is the whole trick. “Improve the footer” is a wish. “Every page under /guides carries the new footer” is a finish line, and so is “the build finishes with no ERROR line.” A goal a machine can argue with.

Then the handoff. Before a worker quits it writes those three lines, then dies. The next worker opens the card cold and picks the job up where the last one dropped it.

They never speak to each other, and they do not need to. A job too big for one sitting stays one card, and each worker adds a paragraph before it goes.

Write down what survives a dead worker. That is most of the system.

Split the work, and never let one hand grade the other

The Role: line names the worker the card wants. There are five: a researcher who finds out what we already know, a planner who writes the brief, a builder, a verifier, and a router who files things.

Two rules hold it together, and I would put both on a wall.

Whoever writes the plan never builds it. And whoever builds it never decides whether it worked.

That second one is the whole game. A worker asked to mark its own output will pass itself every time, in a confident paragraph you have no reason to doubt. So the last word goes to something that was never in the room. The verifier opens the finished card with no memory of how it got made, runs that Done = line itself, and reads what the command printed instead of the builder’s summary. Then it says one of three things. Accept. Accept, with something still unproven. Send it back.

Mine has sent back work already recorded as finished. One card asked for six repos pinned on a GitHub profile. The card said done. The stranger ran the check against the live profile, counted five, and sent it back.

An exit code cannot be flattered. That is why the judge has to be a stranger.

Write down how you decide, or you are the bottleneck forever

This is the part that gave me my nights back.

Agents interrupt you because they do not know what you would say. So I stopped answering the same questions and wrote the answers down instead: which tool to reach for, where a file goes, what to call it, when to retry and when to quit trying. All calls I had already made a hundred times.

Now the board settles those alone and never mentions it.

Five things still reach me, and only five: a secret, something I cannot undo, something going out under my name, something expensive, or a change to the goal itself, which spends my hours, not the machine’s. Those land in Human Gate as one plain question I answer from my phone.

And when a card does ask, it writes down what it thinks I will say before I answer. My answer grades the guess. I patch a wrong guess into the profile the same hour, so the next agent guesses better.

Every question your agents no longer have to ask you is an hour you get to keep.

Let your agents have ideas, never assignments

Halfway through a job, a worker spots something worth doing that nobody asked for.

So it writes a card saying where the idea came from, and it sits in Human Gate, unclaimable, until I answer yes. My agents are allowed to have ideas… they are just not allowed to hand themselves work.

The self-improvement loop, step by step

Every run leaves a record: what the worker did, what broke, and the one-word reason a card got sent back. The loop reads those records so I don’t have to.

A sweep reads every run record and counts the failure reasons. One miss is noise. The same reason on two different cards is a pattern, and the sweep raises it as a card of its own.
A drafter opens that card and writes the exact change to the rules that would have stopped both misses. Not a suggestion, the actual edited lines.
A guard checks the change by machine before any judge sees it, and refuses one that would weaken the machinery that measures the system.
A judge that never saw the draft is told to tear it apart. Its one job is to find the reason the change is wrong.
If the draft survives, I get one plain question in the Human Gate: here is the change, here is why, yes or no.
Nothing lands without my recorded yes. A separate step, run while I’m watching, commits the change. No unattended run ever edits the rules.

The first proposal the loop ever made never reached me. The judge killed it, and it was right to. That is the loop working, not failing.

What others are doing with boards

I went looking before writing this, because I assumed I’d invented something. I hadn’t. A kanban board driving a fleet of coding agents is a crowded category now: dozens of tools, and the biggest of them has tens of thousands of stars. Four of the things I was proudest of turned out to be standard.

The board as the one shared memory for every agent. Standard.
Scheduled runs that each claim one card. Standard, down to the claim expiring if a worker dies.
A builder plus a separate checker. A named practice. One project even tells its checker to try to prove the work is not done.
A human gate for the risky calls. Standard.

Two things I haven’t seen anywhere else.

The written decision profile. Others gate on a generic risk tier. Mine gates on a written record of my own past decisions, numbered, mined from hundreds of questions I’d already answered. Every question that does reach me carries the profile’s guess at my answer, and a wrong guess gets patched the same hour. I found nobody publishing that.
Ideas that ask before they become work. Plenty of systems let agents propose work. I found none where the proposal stays unclaimable until the human says yes on the board: one question, asked once, and a yes turns it into a real card.

And a few do parts of this better than I do. Two projects have deeper dependency graphs than my card links. One publishes a live autonomy score. I’ll take the ideas.

Why a board and not a real framework

Some will tell you a board is too primitive for this. Some will tell you the only serious answer is a real framework, with its retries and its traces.

Fine. None of it helps at ten at night when something breaks and you need to know what your machines actually did.

You can read a board. I open the card and read English.

One criticism does land. Review ten pull requests a day, add a machine that writes an eleventh, and now you review eleven. That is what the stranger is for, and why I would build it first and the board second.

Start with one card

You do not need all this on day one. You need the block above.

Take a job you already hand to an agent. Write its Done = line first, in a way a command could prove. Let the agent work. Then let something that was not involved run that line and read what it prints.

That is the whole method. The rest is what happens when you keep doing it.

And be honest about why you are building it. Some of the best things I have made were only ever for me… and that was enough. You are allowed to build a small machine that runs your own life better and never show it to anybody.

PS. Copy the card block above. That is the whole template: one sentence, one Done = line, three handoff lines. Pick one job this week, write its finish line first, and let a stranger check it. If you cannot write the finish line, the job is still a wish… and no agent has ever finished a wish. More of this lives at 2112capitalsolutions.com. That’s 2112capitalsolutions.com.