Staffing coverage
See which agents and devices can staff each workflow stage, spot coverage gaps, and find out why one exists.
Staffing coverage answers one question for your whole workspace: for every stage a workflow can hand to an agent, is there actually an agent and a device ready to run it right now? It’s the workspace-wide view — for one specific task, use The Placement report instead.
Where to find it
Staffing coverage is part of the Agents page, not a page of its own. Open Set up → Agents in the sidebar: the coverage tiles and stage cards sit below the agent roster. Any member of your workspace can see it — there’s no owner, admin, or plan restriction. It’s a web app view only: there’s no ch command for this report.
Open one agent’s own page to see the same question answered for just that agent: which shared stages does it qualify for, and is it reachable right now on each one? That view carries no device rail of its own — the agent’s Placement section already answers “which devices could run this agent” in full.
What a stage card shows
The page lists one card per shared stage across every enabled workflow — a stage that two workflows both use appears once, tagged with a badge for each workflow. A bridge stage, like the start or end of a pipeline, never spawns an agent, so it never shows up here; only stages that actually spawn one do. A card also notes when its stage needs git host authentication, and whether that’s read or write access.
Each card carries one of three verdicts:
| Verdict | What it means |
|---|---|
| Staffed | At least one agent covers the stage, and an online, enabled device meets that agent’s own device requirements right now. The card names which agent(s) it’s reachable through. |
| Degraded | An agent covers the stage, but no online, enabled device can currently run it. |
| Unstaffable | No enabled agent covers what the stage demands at all. A task reaching this stage is rejected before it can even queue. |
A Degraded card tells you which of two situations you’re in. If none of the online fleet advertises a capability the covering agent needs, the card names the missing tokens. If every needed token exists somewhere in the fleet but no single online device carries the whole set, the card says the task will queue until one does — you may just need to wait for the right device to come online, rather than fix anything.
An Unstaffable card lists the capabilities an agent’s launch config would need to cover this stage. These aren’t clickable — they describe what to add to an agent, not a device to look for. See Capabilities for where each kind of requirement is set.
Agent cards
Inside a stage card, each qualifying agent gets its own small card showing whether it’s currently reachable and, if so, through how many devices. Its capability chips are the device tokens a device needs to carry for that agent to run this stage — press one to highlight which devices in the fleet rail already carry it.
Filtering the list
Above the agent roster, four tiles narrow the stage cards below by verdict: Agent stages (every stage — the reset), Fully staffed, Degraded, and Unstaffable. Below them, a pill row lets you narrow to one workflow at a time instead. Picking either one replaces your current filter, so only one narrows the cards at a time — pick a workflow pill and the verdict tiles show none of them selected, and vice versa. These tiles never narrow the agent roster itself; they’re a separate filter over the coverage report below it.
Each workflow’s pill carries a dot in the color of its worst stage. A workflow with no agent stages at all — for example, one that’s entirely manual — always shows staffed, since it has nothing that could fail to staff.
An individual agent’s own page shows three plain counts instead — stages it covers, how many it’s reachable on right now, and how many it isn’t — read straight off that agent’s own reachability, never borrowed from a stage a different agent happens to cover.
The device fleet rail
Alongside the stage list, a rail lists every device linked to your workspace or one of its parent groups, ordered by how likely it is to pick up new work — an online, enabled device first, then by how recently it last reported in. Each row shows whether the device is online, its name, the capability tokens it advertises, and a Disabled badge if it isn’t currently taking new sessions. An offline device shows when it was last seen instead.
Press a stage card, an agent card, or a capability chip anywhere on the page, and the rail highlights every device that selection reaches with a Matches badge. Press it again to clear the highlight. Only one selection is active at a time — picking a new one replaces whatever was highlighted before.
What this page doesn’t check
Staffing coverage answers a capability question only: can an agent and a device even reach this stage? It deliberately leaves out everything about a specific device or task’s real-time state — how busy a device is, a cooldown after a recent failure, an AI usage limit that’s run out, or a device secret still waiting on its owner to acknowledge it. A stage can read Staffed here while a particular task still doesn’t start, because one of those separate conditions is in the way.
When you need the full picture for one task, run The Placement report — it checks how busy a device is, a recent-failure cooldown, and an AI usage limit, using the actual device state at the moment you ask. It does not check device health, and it only checks a device secret’s acknowledgement when you name a candidate agent.
Related guides
- The Placement report — the same coverage question, answered for one task or agent, plus every reason a device might be refused
- Why isn’t my task moving? — the full diagnostic walkthrough, of which a staffing gap is one cause
- Capabilities — what a capability label is, and where each kind is set
- Managing your devices — online status, health, and capacity
- Agents and the CLI — creating and configuring agents and launch configs
Last updated