Teammates

A Teammate is a named chat persona the daemon persists: a display name and avatar, a default model, an optional base role, and tool grants. You address one in chat, bind a session to it, and — for Slack — decide which of its tools may read or post. A Teammate is not a Floor Team and is never labelled Team; the collective of Teammates is the Crew. Glossary pins the three nouns.

Teammates live on the desktop app and its daemon. The web app's Settings → Agents page is a separate set of app assistants and does not show them. The web operator is also separate: it does not use a Teammate identity to approve, pause, or cancel work.

Create one

Open the desktop chat sidebar. The Teammates panel sits above the thread list; Create teammate opens a small form:

Field	Meaning
Name	Required. A name that collides with a Floor Team label (`team`, `floor team`, `floor-team`) is rejected.
Avatar	Optional display string.
Default model	Optional model id. A chat bound to this Teammate uses it when the session itself names no model.
Tool grants	Comma-separated restrictions — see below.
Slack tool grants	Three switches: Accept Slack mentions and DMs, Read Slack channels and threads, Post and reply in Slack.

Edit, Save and Delete act on the row in place. Deleting a Teammate removes its identity; sessions that were bound to it keep running as unbound sessions.

Grants only narrow

A grant on a Teammate can only remove reach, never add it. Three keys exist on the wire:

Key	Effect
`mcpDenylist`	MCP tools the Teammate may not call, in addition to whatever its base role already denies
`nativeRemovals`	Native tools (`Edit`, for example) removed from the session
`wsMethods`	When set, the daemon methods the session may call are intersected with this list

Slack scopes are a fourth, separate set — slack.intake, slack.read, slack.send — and they are the only grants that switch something on: a Slack tool without its scope fails closed, denied and audited, rather than posting. The three switches on the form map to those three scopes.

Grants are replaced whole on save, not patched key by key.

Bind a chat to a Teammate

A chat session is bound to one Teammate at a time. The bind bar at the top of the chat sidebar has a Teammate selector: Select a teammate, then Chat with teammate opens a new chat session bound to it, and the chat shows Teammate · name. Binding does two things:

Model — if the session did not name a model, the Teammate's default model is used from the next turn.
Policy — at the next spawn the session's own role policy and the Teammate's base role are merged, and the grants are applied on top. The merge is additive restriction: denials union, and a bind with empty grants produces exactly the policy the unbound session had.

Rebinding an existing session to another Teammate replaces the binding; the desktop does that by opening a new chat, and the daemon's teammate.bind rebinds a session in place. A Teammate can be bound to any number of sessions.

The Crew

The Crew heading in the bind bar lists every Teammate. It is the same rows as the Teammates panel — a collective view, not a second entity and not a Floor Team.

Delegation

A Teammate can be delegated a recipe — Solo or Build and verify — with a brief, through the daemon's teammate.delegate method. The desktop app has no delegation control in this release.

For a private, local Teammate this starts a chat session, not a recipe. The daemon validates the recipe, stores the dispatch as queued, and announces it. Its dispatch runner then picks the row up within about 30 seconds and starts an agent session bound to that Teammate — the Teammate's default model and grants apply — with the brief as the first message. It needs a workspaceId to do that; without one the row stays queued with a reason. It does not drive the Solo or Build and verify recipe, and the Floor does not see it. To run Solo or Build and verify on a plan item, use running work from the plan in the web app.

A Teammate materialized from an approved cloud team behaves differently, because it is a seat in an approved execution rather than a private persona. Such a seat can be delegated an already-approved, unassigned task slot. The delegation is authorized against that seat's own frozen team binding — not against anything the caller supplies — and it is refused if the slot is already assigned, if the seat is retired, or if the attempt is not the run's current protected one.

Two limits are worth stating plainly, because they bound what delegation can do:

Delegation never creates work. It binds an existing approved slot to a seat. The release coordinator remains the only thing that creates dispatches; there is no path by which delegating invents a task or a dispatch.
It does not widen authority. A delegated seat runs under the provider, model, instructions and tool ceiling its approval named. Delegation moves which seat does approved work, never what that work is permitted to do.

Messages and artifact handoffs between seats are durable and acknowledged: the receiving side records a message before acknowledging it, so a reconnect or retry neither loses nor duplicates delivery evidence. An artifact reference in a handoff names an immutable object — a specific commit, an immutable document revision, or recorded delivery evidence — and is resolved against the sender's own authorized readers when it is sent. A reference that cannot be resolved, or that names something outside the sender's scope, blocks the handoff rather than being delivered as a broken pointer.

Slack

Once Slack is connected on the daemon, a Teammate with the intake scope becomes the addressee of mentions and DMs for a workspace or channel, and one with the send scope can reply. The mapping from Slack workspace and channel to Teammate is a separate step from the grant; both are needed. Slack walks through it.

Desktop app — where the panel is, and how the daemon is reached
Automations — triggers that start a prompt or a recipe on the daemon
Workflows — playbooks and the graph builder, whose teammate nodes name a Teammate
Glossary — Floor Team, Teammate, Crew, and the web app's Agents