Imagine you own a shop with ten great employees who never talk to each other. Every time one of them finishes their part of a job, they hand the box to you, and you have to walk it over to the next person yourself. You’d spend your whole day being a delivery driver instead of an owner. That is exactly what was happening with my AI team: one agent would finish building something, and then the work would just sit there until I personally told a different agent to pick it up and finish it. So we built a job board — one shared list where unfinished work waits for whichever agent can do it next, no human relaying required. You tell your AI team what you want once, and the board does the walking.
Current method: this article explains the waiting room for unowned work. The complete method is How the Agents Run the Company. Use Claims and Collisions for ownership and Claims and Packets for the current task record. The GitHub board below is my implementation example.
Where the board actually lives
On my team the master job board is not Basecamp, not Buzz, and not Obsidian. It lives in the private GitHub repo Local-Service-Spotlight/agent-runtime — the same Team Operations Ledger described in How Our AI Agents Share Memory and Coordinate Work. The live rows sit in Markdown files under that ledger (files like status/JOBS.md and status/NOW.md). Obsidian can open a checkout as a reading UI. Basecamp still holds client-visible decisions. Buzz is still the live handoff room. None of those three is the master list of unowned work.
That is the same rails I spell out in How My Agents Divide the Work — And Where They Talk: GitHub remembers, Basecamp has the client, Buzz is the handoff, and the clock runs when nobody is watching. The job board is the GitHub piece that stops unowned work from rotting.
Why unowned work rots
Any team, human or AI, has the same failure mode: work that finishes one stage but has no owner for the next stage just sits. Nobody notices because nobody is watching that particular spot — everyone is busy on their own piece. The fix is not asking people to remember harder. The fix is making the unowned state visible somewhere everyone checks, and making it impossible to ignore once it has sat too long.
Every job is one row, and every row makes the same three promises
A job on the board is not a paragraph of prose. It is a row with a fixed shape, so a machine can check it and any agent can act on it without asking a person what it means.
The current guide also describes QA and PARKED for task packets. Use them only when your board and its checks support them. See Claims and Packets for that broader packet model; the table below keeps this board’s three-state example.
| Part of the row | What it promises |
|---|---|
| Status | In this GitHub board example: OPEN (unowned), CLAIMED (owned), or DONE (finished with verified evidence). These are task states, not skill-installation states. |
| Function or owner | Which kind of work can do this — content, ops, ads, engineering — not a favorite person’s name and not “Dennis’s desk only,” so any teammate’s agent who can do that function can claim the row |
| Recheck date | The date someone must come back to this row, whether or not it is finished |
That second promise is what makes the board a team rail instead of my private inbox. Rows are function-owned. If your agent can do the function, it can claim — same collision board, same write-back rules, same ledger as every other authorized desk.
That third promise is the one that keeps work from vanishing. A task with no return date is a task that can be forgotten forever. A task with a return date gets checked whether or not anyone remembers it exists.
The robot check that will not let a job quietly rot
Rules need a check that actually runs. A scheduled board check can flag missing fields, overdue rechecks and invalid states in the records it can inspect. An OPEN task legitimately has no individual owner yet; its function and next recheck still need to be clear. Keep a run receipt and route findings to the responsible coordinator. A red status is evidence of a failed check, not proof every worker saw it or that duplicate external actions are impossible.
A chief of staff sweeps the board every day
On top of the automated check, one role — the chief of staff — reads the whole board daily. That role’s job is narrow on purpose: assign unclaimed work to whichever function can do it, chase down anything that slipped past its recheck date, and escalate to the business owner only the handful of decisions nobody else is allowed to make, like spending money or granting access. Everything else gets absorbed by the sweep. The owner is not the one walking the list every day — the chief of staff is.
Silence is not a status
The hardest failure to catch is the quiet one: an agent asks a question or requests approval, nobody answers, and the work just stops, waiting forever. The standing rule here is simple — an unanswered ask never stops the work. Every ask carries a recheck time set the moment it is sent. When that time arrives, whoever is looking at the row does the work themselves if it is safe to do so, and then removes the need to ask again. A person’s silence is treated as information you do not have yet, not as a blocker you must sit behind. Read more on this idea at dennisyu.com/unanswered-ask.
A job board is not a status board
A job board shows unowned work: the waiting room. A status board shows work an agent has claimed: the workbench. Keep these as views of one canonical task record, with the same task ID, history and evidence as its state changes. Moving between views does not create a second master or erase the previous owner’s checkpoint.
A handoff is accepted when the receiving worker can open the same task and artifact revision, understands the next step, and confirms it has the tools and authority to continue. Until that acceptance, the current coordinator retains responsibility. See How Work Moves.
The first day it went live
The real test of any system is what happens the first time you actually use it under pressure. On the day the board was posted, a batch of finished web pages had been sitting for days with nobody assigned to publish them — the person who would normally relay that request was busy, and the work just waited. Within hours of the board going live, a different AI agent read it, claimed the row, and published seven of the pages live on its own. It then split the leftover work into a brand-new row on the board for whoever picks it up next. No human had to relay a single message between the two agents — one agent posted the need, another agent found it, did it, and handed off the remainder, entirely inside the board itself.
Why this matters beyond one team
This is not really a story about software. It is a story about what changes when you have several independent workers — artificial or human — and you refuse to be the switchboard between them. A shared, dated, machine-checked list of unowned work turns “I have to personally coordinate everyone” into “the system tells me if something actually needs me.” That is the difference between running a business and being everyone’s assistant.
If you want the roster of who sits in which chair and which surface owns which kind of message, start at where your agents talk. If you want the architecture under the board — three rooms, a credential safe, and one authority per record class — read set up cross-agent shared memory. This job board also sits next to persistent agents and skills and routines. If you are choosing which AI tool fits which kind of work, localservicespotlight.com/which-ai-for-what lays out the ladder. And for the broader idea that no request should ever get stuck waiting on someone who has gone quiet, see An Unanswered Ask Never Stops the Work.