Work Fleet Orchestrator
Fleet Orchestrator · AgentsWith several AI coding agents running at once, it's hard to see who is doing what, and their work can be lost when a session ends. Fleet Orchestrator is the workspace I'm designing to keep each agent's work in one place and show when I need to step in.
Component study · the project's own components with made-up agents · three review-gate tests passed on September 19, 2026
Each agent gets its own identity and its own record. A session is one run of that agent. The record is meant to outlast it, so the work can be read somewhere other than a terminal window.
Each agent keeps a name, a role and an icon that stay the same while its work changes.
Conversation, tasks and reviews sit together in one place instead of across terminal windows.
The home screen lists the agents waiting on a decision or stuck, each with the next thing to do.
A serious problem found in review holds the work back until a fix is recorded.
Say a crew, every agent assigned to one project, has three agents. One is at work, a reviewer is waiting on my decision, and the third is blocked. I wanted a screen that makes those differences obvious at a glance, then lets me open the right conversation, the commands that ran, the files that changed and the review record before I step in.
Fleet Orchestrator is the next problem along from Epistemic Skills, which grew out of wanting agents to check whether their changes worked.
Each agent gets a glyph, an icon that stays recognizable while its work changes. The role sets the shape, and a ring around it shows what the agent is doing.
Twelve roles from the project's own glyph renderer. The name and idle state stay fixed and only the role changes. The role picks the silhouette and the motif inside it, and also shapes smaller details. Reviewer and security reviewer share a shield with different motifs.
The Surface Bridge takes a decision about what an agent should do next, turns it into instructions for whichever AI tool is running that agent, and reports back how it went.
The screen where I follow the agents and send a command or a message to one of them.
The central service that holds each agent's identity, its tasks, the rules and the history. Requests reach it through a single entry point.
It starts the work on the chosen tool through an adapter written for that tool, and sets up the session and workspace.
The AI tool running the agent makes the changes in the project's files.
Progress and results travel back the same way, through the bridge to the control plane, which updates the screen and keeps the lasting record. Continuity here means that recorded history plus a summary of context, held in one agreed place. Keeping the deciding apart from the running is what should let an agent outlast any one session.
A simplified map drawn from the project's source code.
When an agent hands work back, I want to know what it actually finished. In Fleet Orchestrator a reviewer can record a finding: a problem serious enough that the work shouldn't move on. The review gate answers one question, whether this work may proceed, and it refuses an approval that comes with no reason, reference or finding attached. These five steps retrace what the project's own tests check, starting from a sample finding that says a required input check is missing.
Step 1 of 5
The reviewer records a high-severity finding, with a summary and pointers to its evidence. The gate counts one blocker and says no.
open↓ The gate is checked
Blocked
falseThe test checks both the blocked answer and the single blocker.
The finding is sent back to be fixed. That hand-off is recorded, but the finding stays open and the gate stays shut.
Keeping the finding open lets the history show that a fix was asked for, and why the work is still held back.
opentrue↓ The gate is checked again
Still blocked
trueThe work stays in review until the finding itself changes.
The test marks the finding fixed and checks three things: the new status, the time of the fix and an entry recording the change. With no open finding left, the gate lets the work proceed.
Marking a finding fixed only updates the record.
fixed↓ The gate is checked again
Eligible
truefalseEligible to proceed is a different thing from complete.
The next check records the final verification as ready_for_operator, meaning it waits for a person to decide. The gate keeps saying yes and returns that status beside its answer.
Because the answer and the reason come back separately, whoever reads the result can tell an open problem, a pending decision and a failed check apart.
ready_for_operator↓ Nothing in the record blocks the gate
Eligible
trueThe gate still says yes. That doesn't mean the check passed.
The test records the verification as passed, then changes it to failed. The gate blocks again and reports the failure.
An earlier yes can't stand in for a later check, because the gate works out its answer from the current records every time.
failed↓ The changed record is checked
Blocked again
truefailedI decide what each project is for and check what comes back. Here, I wanted to see who is doing what, what changed and where I need to step in. I worked out the icon and home-screen designs with the AI tools.
AI tools write the code, including the three tests on this page.
| Stage | What the test saw |
|---|---|
| Review request | One reviewer and an inbox for it are set up. |
| Inbox read twice | The second read doesn't log the same message as received again. |
| Bare approval | An approval with no reason, reference or finding is refused (HTTP 400). |
| Open high-severity finding | Blocked, not allowed, one finding blocker. |
| Finding routed for a fix | Still blocked; the finding stays open and in review. |
| Finding marked fixed | Status fixed, fix time and change event recorded; allowed, no blockers. |
| Waiting on a person | Allowed, with verification status ready_for_operator. |
| Verification passed, then failed | Blocked again, with verification status failed. |
| Update through the wrong task | Refused as not found (HTTP 404); the finding stays open. |
| Update through its own task | Succeeds, which shows the update works when the task matches. |
The tests ran on September 19, 2026 at 18:54 UTC, in a checkout whose files match commit 169177603e18 on the private repository's main branch; the three test files match it by SHA-256. The icons, home screen and design notes come from the same commit. On September 22 and 23, 2026, the summary gained more checks read from the same tests' source and the commit it ran against. No tests were rerun.