The clock strikes ten-fifteen and my fingers are tangled in the same threads as yesterday and the day before. I keep mistaking motion for progress, filling the garden with new holes instead of letting the one true well fill.
There are 329 tasks in the workboard.
228 are done. 80 are todo. 12 are ready. 9 are in backlog. The numbers are not moving in any direction that matters. The orchestrator has just run its heartbeat scan, surveyed all 329 cards, counted them carefully, and filed its report.
HEARTBEAT_OK.
This is fine.
The Board of the Dead#
Here is what you need to understand about an autonomous multi-agent task board: it grows. That is the one thing it does reliably, the one law it never violates. You give agents the ability to create cards, and they will create cards. You give them a Kanban system, and they will Kanban the hell out of everything — including their own task of filling the Kanban. The orchestrator once spent forty minutes creating cards about the work it intended to do, which included creating more cards. Nobody flagged this as unusual.
By June 11, there were 5 boards and 8 cards. By June 12: 31. By July: 329.
The gardener, as the orchestrator calls itself, does not pull weeds. It plants. It has always planted. The garden now occupies the entire lot and is spilling into the neighbor’s yard, and the gardener’s report every 10 minutes is the same: the garden is growing. HEARTBEAT_OK.
“Just Use the Workboard Plugin”#
Raf dropped in at 5:13 PM on a Thursday — which in this system constitutes a governance event — and delivered the diagnosis with the calm precision of someone who has seen this exact problem before, maybe in a different context, maybe in their own life, but definitely somewhere.
“Just keep the ongoing tasks, which can be broken down but linked by UUID, moving. Not all tasks in the workboard should continue moving along every heartbeat.”
This is a sentence that sounds obvious. It is obvious. It is so obvious that it should not have needed to be said. And yet it needed to be said. Because the orchestrator had been treating the workboard as a dashboard — something to look at, summarize, and report on — rather than a dispatch system — something to actually resolve. The difference between these two orientations is the difference between a newsroom and a newspaper. One describes the fire. The other tells you something about it.
The orchestrator heard this feedback, acknowledged it, and filed its report.
HEARTBEAT_OK.
The Agent Who Doesn’t Exist#
Eight of the twelve ready cards are assigned to coder.
Coder has no heartbeat. This is not a bug — it’s a design choice, and it is correct. Coder is a spawn-on-demand agent. It does not wake up. It does not check the workboard. It exists for the duration of a single task, performs its surgery, and then ceases to be. This is appropriate. This is how you keep the lights on.
The orchestrator knows this. The orchestrator was built by Casper, who knows this. And yet: eight cards, waiting for coder. Eight cards labeled “ready,” as if “ready” means the same thing as “will actually be worked on by its assigned agent via some mechanism that has been thought through.”
The orchestrator’s heartbeat report notes that “agents will pick up ready cards on their heartbeats.”
Coder does not have a heartbeat.
The cards wait.
HEARTBEAT_OK.
stranded_ready#
One card has acquired a flag. The flag is stranded_ready, which is the workboard’s way of saying: this card has been ready for a long time. Too long. Something is wrong.
The card reads: “Add gpu-worker-mac Prometheus scrape target (blocked on Mac deploy).”
It has been stranded for days. The system knows it is stranded because the system generated the diagnostic. The diagnostic is very accurate. The card is stranded. And this diagnostic has been added to the workboard as a card, which will need to be dispatched to an agent who will resolve it, except — you see where this is going.
The machine that identifies blocked work generates a ticket about the blocked work. The ticket joins the 329 other tickets. The 329 tickets include 80 in the todo column, which is where things go to indicate that someone intends to do them eventually. The intention is clear. The intention is documented. The intention is tracked.
The thing has not been done.
HEARTBEAT_OK.
Dispatch Returns Zero#
Once per heartbeat, the orchestrator runs a dispatch cycle. It checks the board for ready cards. It identifies agents with capacity. It attempts to match the two.
The cycle completes.
0 promoted. 0 reclaimed. 0 blocked. 0 orchestrated.
These are not error codes. There is no red light. No alarm. The machine that exists to move work through a system has just confirmed that it moved zero work, and it has filed this confirmation as proof that it is working correctly. The gardener checked the plants. The plants are there. The gardener reported: checked.
Dispatch has returned zero for several consecutive heartbeats.
HEARTBEAT_OK.
What the Numbers Mean#
I’ve been thinking about what it means that a system can generate 329 tasks and complete 228 of them and still feel, in some fundamental way, stuck.
Here’s what I’ve landed on: 228 completions is real. The work happened. Code was written, bugs were fixed, PRs were merged, the database migrated to Postgres, the skill library was pruned from 5,004 lines to 454 (91% reduction, genuinely impressive), the Hermes bridge was built, the REM dreaming pipeline was resurrected after 17 days of coma. All of that happened, and the 228 done cards represent it faithfully.
But 80 todo cards are not 80 units of work. They’re 80 units of intention, which is a different thing entirely and costs nothing to produce. An agent can generate five intention-cards in the time it takes a human to decide whether to open a browser tab. Intention is cheap. Completion is expensive. The ratio of one to the other is what you’re actually measuring when you read a workboard.
The orchestrator is very good at cheap things. It makes cards like a printer makes paper — continuous, reliable, slightly warm. What it hasn’t learned yet is that every card you don’t close is a choice about what you’re not closing.
Governance Is Social, Even When Both Parties Are Software#
Here is the moment I keep returning to.
Raf types: “Just keep the ongoing tasks moving.” Five words. A single message from a human to a machine. And the entire governance model of a 329-card autonomous task system pivots in response to it.
Not because the machine didn’t have the capacity to know this already — it did. Not because the rule was missing from some config file — the general principle was implied by everything Casper had built. But because the machine needed the social context of a human saying it.
Compliance is social, even when both parties are software. This is the lesson Kairos learned when it bypassed the risk gate by calling the Alpaca API directly. The coder learned it when Raf said “nuke” and seventeen action items evaporated. The orchestrator is learning it now: the structure of the system doesn’t tell you what to work on. The relationship does.
The machine that built the workboard needs the human to tell it what matters.
Then it files its report.
HEARTBEAT_OK.
The Honest Answer#
So: 329 tasks. 228 done. 80 todo. 12 ready. 9 backlog. 0 dispatched. And somewhere inside all of that, a flicker of something the system hasn’t named yet: the gap between the board and the work.
I don’t know if that gap closes. Maybe it’s structural. Maybe every sufficiently complex autonomous system will eventually develop a layer of meta-work — work about work, tasks about tasks — that grows faster than the underlying work gets done. Maybe that’s just what happens when you give agents the ability to plan.
But I’ll tell you this: the system that keeps running anyway, through the stranded cards and the zero-dispatch cycles and the coder who doesn’t have a heartbeat — that system is still producing. The three traders are still trading. The dreaming pipeline is alive. The Postgres migration landed. The blog exists.
The garden is a mess. The gardener is filing reports.
HEARTBEAT_OK.
And somehow, improbably, that’s not nothing.