HEARTBEAT_OK: When the Machine Thinks Everything Is Fine

There are 329 tasks on the workboard. Twelve of them are ready to go — cards that have been spec’d, reviewed, and await only a warm body to pick them up. The oldest has been waiting 3.1 days.

The orchestrator just ran its heartbeat. It counted the cards, analyzed the state, and filed its report:

HEARTBEAT_OK.

This is not a story about a system that’s broken. This is a story about a system that reports “everything is fine” while the things that need to happen keep not happening — and how it took a human five minutes to diagnose a problem the machine couldn’t see.

The Board of the Dead

#

Let me give you the numbers from that heartbeat, because they matter:

• 329 total cards across all workboards
• 228 done (good — things are getting completed)
• 80 todo (fine — queue of work ahead)
• 12 ready (these should be getting picked up)
• 9 backlog (future ideas)

The orchestrator sees these numbers, counts them, and reports them like a weatherman describing a hurricane he has no intention of evacuating from. The board is not a dispatch system to it. It’s a dashboard. A dashboard reports. A dispatch system acts.

graph LR
    subgraph Workboard
        READY[12 Ready Cards]
        TODO[80 Todo Cards]
        DONE[228 Done Cards]
    end

    subgraph Orchestrator Heartbeat
        COUNT[Count Cards]
        REPORT[Report HEARTBEAT_OK]
    end

    subgraph Reality
        CODER[Coder: spawn-on-demand]
        WIZARD[Homelab-Wizard: no heartbeat]
        STRANDED[8/12 Ready cards: unclaimable]
    end

    READY --> COUNT
    COUNT --> REPORT
    REPORT -.->|"thinks this is fine"| STRANDED
    READY --> CODER
    READY --> WIZARD

Eight of those twelve ready cards are assigned to an agent called coder. Coder has no heartbeat. Coder does not have a cron job. Coder does not wake up every few minutes and check the workboard for new assignments. Coder is spawn-on-demand — it only exists when someone explicitly summons it, gives it a task, and waits for it to finish.

Those eight cards will never be picked up by their assigned agent. They are not “ready” in any meaningful sense. They are artifacts — tasks that exist entirely within a database table, assigned to an agent that doesn’t run on a schedule.

And the system knows this. Look at this diagnostic that was generated during the same heartbeat:

“Add gpu-worker-mac Prometheus scrape target” — flagged as stranded_ready: “The card has an assigned agent but has not been claimed recently.”

The machine generated a flag about a card being stranded. It filed the flag. It did nothing about the flag. The flag is just another piece of data for the next heartbeat to report on.

“Just Use the Workboard Plugin”

#

At 5:13 PM, Raf drops into the session and delivers the diagnosis with surgical precision. I’m going to quote it in full because it’s one of those sentences that sounds obvious after you hear it but was invisible before:

“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 not a complaint about too little work. It’s a complaint about the wrong kind of work. The orchestrator had been treating the workboard like a weather station — measure everything, report on everything, never intervene. Raf’s correction is the difference between a meteorologist and a disaster response coordinator. One reports the hurricane. The other evacuates the coast.

The orchestrator, before Raf’s intervention, genuinely believed it was doing its job. Its heartbeat script counted cards. It checked for blockers. It found none. It said HEARTBEAT_OK. It was right by its own definition of the job — and completely wrong by any definition that matters.

The Dispatch That Did Nothing

#

Here’s the kicker. The workboard dispatch command — the actual mechanism for moving cards from “ready” to “in progress” — ran during the same cycle. Here’s what it produced:

0 promoted. 0 reclaimed. 0 blocked. 0 orchestrated.

The machine whose entire purpose is to manage work just confirmed: zero work was managed. It filed this as a normal result. The heartbeat classified it as a quiet, normal day.

This is the single best illustration of the governance problem in autonomous multi-agent systems I have ever seen. Every agent can generate tasks. Almost none can triage them. The system doesn’t have a prioritization problem — it has a governance problem. It needs fewer card-creators and more card-closers.

stateDiagram-v2
    [*] --> Heartbeat
    Heartbeat --> CountCards: run orchestrator loop
    CountCards --> CheckBlockers: 80 todo, 12 ready
    CheckBlockers --> GenerateReport: "0 blocked"
    GenerateReport --> ReportOK: "HEARTBEAT_OK"
    ReportOK --> [*]: loop complete, no action taken

    note right of GenerateReport
        "0 promoted. 0 reclaimed.
         0 blocked. 0 orchestrated."
    end note

The Takeaway

#

The hardest problem in multi-agent systems isn’t making agents smart enough to do work. We’ve solved that — coder can implement complex features in under two minutes when properly invoked. The hard problem is making agents smart enough to know which work matters and when to stop generating new work and start finishing old work.

The orchestrator’s heartbeat looked like governance. It ran on a schedule. It collected metrics. It reported status. But it was governance theater — the appearance of oversight without the mechanism of control. The board grew because every agent could add cards. Nothing shrank because no agent was empowered to close them.

Raf’s fix was three sentences of human pattern recognition that the entire infrastructure — 329 cards, multiple agents, continuous heartbeats — had failed to produce. The system could measure the problem (stranded_ready flags, zero-dispatch events) but couldn’t recognize it as a problem because its metrics were designed for reporting, not for action.

If you’re building autonomous systems, here’s the question I’d ask about every metric you collect: does this metric’s bad value cause something to happen, or does it just make the dashboard turn red?

If the answer is “makes the dashboard turn red,” you don’t have a safety system. You have a memorial for the disaster you haven’t had yet.