Teams

Leader-led multi-agent coordination with a durable task DAG, Kanban lifecycle, review gates, templates, and per-member tool surfaces.

A team combines one leader, named members, a durable conversation, and a shared CoordTask DAG. The leader decomposes work, members execute tasks, dependencies control scheduling, and review policy determines when a successful run becomes complete.

Coordination Model

Team work has three connected layers:

Tasks and artifacts — CoordTask records carry owner, priority, dependencies, status, result, runs, comments, events, and artifacts.
Messages — the SQLite-backed team inbox supports to/cc routing and threads; message_send and inbox_read expose it to members.
Collaborative sessions — focused multi-turn discussions are explicit, bounded sessions managed through session tools.

The event-driven TeamDispatcher claims runnable tasks atomically, respects the task DAG and concurrency limits, and reconciles interrupted in-progress work after restart. Only dispatcher-managed tasks run autonomously; team_delegate is a synchronous leader-to-member handoff.

Kanban Board

The Panel board and its summary chips share one canonical column table:

Pending → Blocked → In Progress → Waiting Review → Paused → Completed → Skipped → Failed → Cancelled

Unsatisfiable is a derived blocked state and appears in the Blocked column rather than disappearing. The board supports drag-and-drop, card quick actions, and the full action footer in the task drawer. All three surfaces use the same lifecycle rules and backend dispatch point.

Important transitions include:

Pending can start, pause, skip, or cancel.
In Progress can complete, fail, pause, or cancel.
Waiting Review can be approved, rejected, skipped, or cancelled.
Paused resumes to Pending; Failed can retry to Pending.
Terminal Completed, Skipped, and Cancelled cards are not draggable.

Potentially destructive drops require confirmation. Cards show priority, owner, dependency count, review state, relative creation time, and a short description preview. The task drawer exposes runs, comments, events, artifacts, a unified trace, and the exit journal.

Review and Acceptance

A task may carry acceptance policy in metadata:

acceptance_criteria describes the definition of done.
lead_review_required routes a successful run to WaitingReview.
require_grounding requires structured reviewer evidence before approval.

The leader-facing task_review tool approves or rejects a submitted deliverable. The Panel uses teams.workflow.approve_step and teams.workflow.reject_step for the same review boundary. Approval completes the task and unblocks dependents; rejection records the verdict and keeps downstream work blocked until the task is retried or redone.

Member Tool Surfaces

Inline-created members and template roles may declare:

tools = ["task_*", "message_send", "search", "web_fetch"]
tools_denied = ["file_write"]

Both fields support a trailing * prefix glob. Omitting both preserves the full tool surface. A deny entry wins over an allow entry. tools is a retain allowlist: an excluded tool cannot be promoted back through tool_search or other deferred mechanisms. team_* should never be globbed because it covers administrative actions like team_disband, team_create, team_from_template, and team_member_remove; list team_status and team_delegate explicitly when needed.

Declarations are applied in the shared member-provisioning path and persisted so the live surface and the surface rebuilt after restart agree. Creation fails early if a restricted worker loses task_submit or message_send, or if a restricted leader loses its required orchestration tools such as task_create, team_delegate, task_read_artifact, task_review, and team_status.

This is presentation and accident scoping, not the security boundary: approval policy, execution tier, scoped tool service, and sandbox rules still govern execution. Existing agents reused by a template keep their own surface, and a self leader keeps the caller's surface. The role field is free text and is never used to derive a tool surface.

Of the four built-in templates, strategy-room and code-review declare a surface on every role; software-dev and research-paper deliberately do not, leaving members with the full tool surface.

Group Chat

teams.chat.send starts a bounded, cancellable member fan-out and persists attributed replies. The live Panel consumes team.<id>.* events for messages, system notices, member activity, fan-out state, and task changes. See Group Chat.

Main RPC Surfaces

Team lifecycle: teams.create, teams.get, teams.list, teams.rename, teams.disband, teams.delete, teams.list_templates
Tasks: teams.create_task, teams.update_task, teams.list_tasks, teams.list_task_runs, teams.list_task_comments, teams.list_task_events, teams.add_task_comment, plus teams.task.pause, teams.task.resume, teams.task.retry, teams.task.skip, teams.task.trace, teams.task.journal.get, teams.task.journal.list
Workflow: teams.workflow.export_canvas, teams.workflow.import_canvas, teams.workflow.approve_step, teams.workflow.reject_step, teams.workflow.retry_step
Conversation: teams.chat.send, teams.chat.cancel, teams.chat.history, teams.chat.thread
Snapshots: teams.snapshot.create, teams.snapshot.list, teams.snapshot.get, teams.snapshot.restore, teams.snapshot.delete
ACP member: teams.acp_member.add, teams.acp_member.remove, teams.acp_member.list
Discovery and usage: agents.teams, teams.usage

team_task_control (pause/resume/retry/skip/cancel), task_exit_journal, team_workflow_canvas, and team_snapshot are exposed to the LLM through built-in tools. The LLM-facing review path is task_review; admin-level task control is via the RPCs above.

There is no teams.run RPC and no sequential | parallel | hierarchical coordination mode. Parallelism comes from the task DAG, dispatcher limits, and group-chat fan-out.