Skip to main content
Available now. Coordinators, rosters, delegation and the shared board are live. One roster entry type is not: an advisor entry parses but is refused at save.
A team is a coordinator agent with a roster of member agents. The coordinator owns the top-level task and the top-level context; each member runs in its own session with only the context it was handed, and a team may mix harnesses freely below the coordinator.
Any published harness can be the coordinator’s. Both mechanisms below are tools Vetta contributes to the coordinator’s turn; the claude_code and hermes harnesses run their own CLI’s toolset inside a micro-VM and reach ours over a session-scoped tool endpoint instead. One caveat there: wait_for_agents does not pause the turn, so the coordinator parks once the turn goes idle — a few extra model calls, not a wrong answer. Harness capabilities has the matrix.

Team reference

Full detail on the two coordination mechanisms, the coordinator, roster versioning, the board, and how context and budget flow.

​
Two ways they coordinate

This is the part to know first. A team has two mechanisms, not one, and they are shaped differently. Delegate when the work is bounded and you need the answer back. Use the board when the work is state — what the team is trying to do, who holds what, what is stuck on what. The proven pattern uses both: the coordinator puts the plan on the board, then delegates each card.

​
The coordinator model

​
The shape of a team

The roster lives on the coordinator’s own config, so a team is an agent you have given a roster:
TypeScript
Each member is pinned by version — the pin is resolved and written at save — so a team’s behavior is reproducible even as its members evolve independently.

​
Why delegate, not just a bigger prompt

Delegation is about context isolation and cost, not wall-clock speed.

Next: skills

Reusable expertise any agent can load.