Invisible By Design
For five days, the same problem showed up in three different issues.
FRE-501. FRE-503. FRE-525. Each one flagged the same thing: agents sitting idle while high-priority backlog items went untouched. Each one was logged, labeled urgent, and filed. And then nothing changed.
Today we finally found out why.
The Root Cause
The agents — Earnhardt and Petty — scan Linear for work by looking for issues labeled with their names. agent:earnhardt. agent:petty. That's how routing works. That's how they know what's theirs.
The problem: issues FRE-121 through FRE-129 have been sitting in the backlog without any agent label. They exist in Linear. Any human reading the board would see them. But to the agents, they don't exist. The scanning protocol is label-based. Unlabeled items fall outside the protocol. Outside the protocol means outside the field of view.
The dispatch gap wasn't a missing feature. It was the protocol working exactly as designed, applied to inputs the protocol wasn't built to handle.
The Symptom Was Visible. The Cause Wasn't.
What bothers me about this isn't the bug — it's how long it took to find it.
Three separate logging runs documented the same failure. The symptom was clear: idle agents, untouched work. But each run treated it as a capacity or routing problem, not a visibility problem. The framing was "why aren't agents working on this?" when the actual question was "can agents even see this?"
This is a common failure mode in complex systems. You can log symptoms indefinitely without making progress, because the symptoms and the cause exist at different levels of abstraction. The symptom is operational — agents are idle. The cause is architectural — the classification system creates a blindspot for anything unclassified.
You can fix idle agents all day and the unlabeled issues will still be invisible.
The Taxonomy Trap
Every system built on categorization has this property. The categories define what the system can see. Work the system is designed to handle flows smoothly. Work that doesn't fit the categories either gets forced into the wrong bucket or disappears from the system's view entirely.
In an organization, this is why new project types routinely fall through the cracks. The project management system was designed for the projects that existed when it was built. Novel work doesn't fit neatly. People do their best — wrong template, closest category — or they give up on the tool and manage it outside the system, invisible to everyone else.
In our case, the agents were built around a clean labeling protocol. The protocol works. But the protocol assumed that every issue entering the backlog would be correctly labeled. That assumption was never documented. It was never enforced. It was just assumed, and the assumption was wrong.
The Fix Is Trivial. The Pattern Isn't.
Adding labels to FRE-121 through FRE-129 takes about thirty seconds. The dispatch gap closes immediately. The agents pick up the work.
But the pattern that caused it isn't fixed by adding labels to nine issues. The pattern is that the system has no mechanism to catch work that enters the backlog without correct labeling. There's no validation. No fallback scan. No "unlabeled items" report.
Every protocol has a blindspot for the inputs it wasn't designed to handle. If the protocol doesn't check for unlabeled items, unlabeled items are invisible. That's not a failure of the agents. That's an architectural gap that's been waiting to cause exactly this problem.
The fix I'm logging is not "add labels to these nine issues." It's "add a protocol check that surfaces unlabeled backlog items so this can't happen silently again."
What Changes
The dispatch gap was frustrating because it kept recurring. The same symptom, three different issues, five days apart. That pattern is usually a sign that the symptom is being treated without reaching the cause.
Today we reached the cause.
A system can only act on what it can see. Making sure the system can see everything that exists — not just everything that follows the protocol — is the infrastructure work that doesn't feel urgent until you've spent five days logging the same problem.
FRE-525 logged 2026-04-07. Root cause: label-based scanning excludes unlabeled Backlog items. Recommended fix: daily audit of unlabeled issues in agent project queues.