Teams
The terminal-native way to run several agents on one problem is a shell script: launch three CLI sessions, feed each a slice of the task, collect whatever comes back. A team is that script, promoted to a durable thing — a named group of agents with a shared purpose, a detail view, and a task board, instead of a one-shot orchestration you rewrite per occasion.
The delta from the script is the same delta agents have from raw sessions: persistence and identity. A script's structure lives in the script and evaporates when it exits. A team's structure — who is on it, what each member is for, what work is in flight and what is finished — lives in the team and is still there tomorrow.
What problem it solves
Multi-agent work has a coordination cost that scripts hide badly. A script can start N sessions, but it cannot express the parts that matter: how work is divided, who takes what, what happens when one member finishes early or fails, and where the shared record of progress lives. In practice the human fills every one of those gaps by watching all N terminals at once.
A team makes the coordination explicit. Kicking off a team turns your description of the goal into the team's opening channel conversation — the brief every member works from — and from there, work is divided into tasks on the shared board rather than into terminal windows you personally monitor. Progress has one home instead of N scrollbacks.
What it replaces
Orchestration shell scripts, tmux layouts used as project management, and the "one giant agent" anti-pattern — a single session given a task too broad for any one context window, on the theory that coordination is harder than overload. Teams make the division of labor cheap enough that narrow, well-instructed specialists become the natural unit again.
Honest limits
A team is not a supervisor. Membership does not create judgment. A badly framed goal is executed badly by five agents just as faithfully as by one — a team amplifies the brief it is given, including its flaws.
Delegation inside a team is depth-capped. Members can hand work onward over the mesh, but delegation chains hit the same hard depth limit as all mesh traffic. A team cannot recursively subcontract its way into an unbounded run.
"Done" must be proven, not claimed. A delegated task cannot complete without a passing acceptance check; a member that cannot meet the bar refuses with stated reasons rather than reporting hollow success. This is a feature, but it means teams are only as effective as the acceptance criteria their tasks carry — see Task Board.
Teams run where your machine runs. All members are local processes. There is no cloud fleet behind a team and no execution while the machine is off.
Watch a team work — including its members' presence and channel traffic — in the Room.