Capability routing

What it is

Capability routing is how a task finds the right agent. Agents and devices carry capability labels, tags like "frontend" or "database migrations," and a task can require one before it's eligible to be staffed there. Instead of a task landing wherever's idle, it lands where the labeled skill actually is, and it simply waits, unstaffed, if no eligible agent is currently free.

Why it matters to you

Not every agent, or every device, should touch every kind of work; a task that needs production database access shouldn't get picked up by whichever agent happened to be free first. Capability routing is what lets you say that once, as a label, instead of manually checking who's available every time a task comes in. It also scales in a way manual assignment doesn't: the rule stays the same whether your team runs five tasks a week or fifty.

How it works in CodeHerder

CodeHerder resolves this server-side: a task's required capability, if it has one, is checked against every registered agent's own capabilities before it's staffed, and the same label vocabulary applies whether the requirement comes from the task itself or its schedule. The full set of rules is in the capabilities doc, with worked examples of each. It covers how capabilities apply to agent skills and launch-config gates, plus task requirements.

• Capabilities →

What people get wrong

A capability label can look like a description or a note, decorative metadata that doesn't actually do anything. It's an enforced gate: a task can't be staffed to an agent that doesn't carry the capability it requires, so a mismatched label means the task simply waits rather than getting picked up by the wrong hands. The fix for a stuck task is usually to check the label; assuming the platform is broken rarely helps. A capability that's too narrowly defined causes the exact same symptom as one that's missing entirely: a task with nowhere eligible to go.