Agents

Route /agents. Four sections: definitions, running subagents, teams, and named agents.

Definitions

A definition is a persona: a name, a description of what it is for, and the model and tools it runs with. The list is the core's, so definitions created from a terminal with /agent create appear here as well.

Create agent asks for one thing — what the agent is for, in a sentence — and the core generates the definition from it. Tick Named agent to also register it under a name you choose, which is what makes it addressable from chat.

Each card carries a task box and Spawn, which starts a subagent on that definition without going through a thread.

The picker on each card is the model that agent runs on, and the chip beside it is what that resolves to. It writes the per-agent assignment — the same setting as Settings → Models → Per-agent — rather than editing the agent's file, because built-in roles have no file to edit. An agent left on inherit follows the default; Settings → Models explains the full order.

When a project team is active, a banner above this section names it and the list shrinks to that team's members — those are the only agents that can be spawned or delegated to while it is active. The team itself is a label, not something to run: it has no card and no Spawn button, because the core refuses to spawn an agent by a team's name.

A spawn the core refuses says why, in the core's own words — unknown agent 'x', or which team members you may choose from instead.

Running subagents

The middle section is live. Subagents appear here when any session spawns one, change state as they run, and stay after they finish so you can read the result. State is one of queued, running, done, error.

Clear finished removes the settled rows. It is a display action; nothing on the core is deleted.

Teams

A team is a roster of agent definitions that bounds which agents automatic delegation may reach. It is not the parallel worker run on the Worktrees screen, which is a different thing with a similar name.

Teams come from two places, and the table says which:

• global — defined in the core's own settings.json, available in every project. The global default_team applies wherever a project names none.
• project — defined in <project>/.snowpea/settings.json. A project team shadows a global one of the same name, and the project's activeTeam wins over the global default.

To create one, tick the members and give it a name; Create & use writes it to the project and makes it active. Use switches to an existing team and Delete removes a project team — a global team is shown read-only here, because it is not this project's to delete.

All three run the core's /team command in the open thread rather than writing the file directly, which is what also rebinds the roster on sessions that are already running. That is why the section asks you to open a thread first.

Next to each member is the model profile it runs on — the same per-agent setting as the definition cards above and as Settings → Models. When the core reports stage assignments, a small chip next to a member names the stage it runs: plan, explore, implement, test or review. A core that reports none simply shows no chips.

The banner above the list names the active team. Its members run /team "<task>" as a pipeline — plan → implement → test → review — and are the default owners for delegation; only they are listed below, and only they can be spawned.

Assigning a team to a project

A project's members change over time, so the assignment lives next to the project rather than only here. On the Threads screen, under the project switcher, a chip names the project's team — Team: <name>, or No team. Click it to pick from the teams already created: the project's own first, then the global ones, then None. The same picker is in the project's own settings sheet, under Team, with a Create team… link for when none of them fits.

Picking runs /team use <name> in the open thread, and None runs /team use none, which leaves the project with no team at all — delegation may then reach every agent, which is sometimes exactly what you want. Because it is a command and not a file write, a thread has to be open in that project; the picker says so when there is none.

Clear on the active team's row does the same thing from this screen.

Named agents

A named agent can be bound to a chat channel, which is how it answers messages from Telegram, Discord, Slack or KakaoTalk.

Bind channel asks for the platform, the channel id, an optional user id, and the name of the credentials entry to use. The credential itself is never typed here or shown: it lives in the daemon's credentials file or an environment variable, and the binding only references it by name.

A binding without a user id can receive messages but can never answer an approval, because there is nobody to attribute the answer to. The Gateway screen flags those.

Delete removes the definition from the core.