Team Configuration

Teams allow multiple agents to collaborate on tasks. MindRoom supports two collaboration modes.

Team Modes

Coordinate Mode

The team coordinator analyzes the task and delegates different subtasks to specific team members:

teams:
  dev_team:
    display_name: Dev Team
    role: Development team for building features
    agents: [architect, coder, reviewer]
    mode: coordinate

In coordinate mode, the coordinator analyzes the task and selects which agents should handle which subtasks based on their roles. The coordinator decides whether to run tasks sequentially or in parallel based on dependencies, then synthesizes all outputs into a cohesive response.

Collaborate Mode

All agents work on the same task simultaneously and their outputs are synthesized:

teams:
  research_team:
    display_name: Research Team
    role: Research team for comprehensive analysis
    agents: [researcher, analyst, writer]
    mode: collaborate

In collaborate mode, the task is delegated to all team members simultaneously. Each agent works on the same task independently, and the coordinator synthesizes all perspectives into a final response. This is useful when you want diverse perspectives on the same problem.

Full Configuration

teams:
  super_team:
    # Display name shown in Matrix
    display_name: Super Team

    # Description of the team's purpose (required)
    role: Multi-disciplinary team for complex tasks

    # Agents in this team (must be defined in agents section)
    agents:
      - code
      - research
      - finance

    # Collaboration mode: coordinate or collaborate (default: coordinate)
    mode: collaborate

    # Rooms the team responds in
    rooms:
      - team-room

    # Model for team coordination (default: "default")
    model: sonnet


    # Team-scoped replay controls (optional; inherit from defaults when omitted)
    num_history_runs: 8
    num_history_messages: null
    max_tool_calls_from_history: 6

    # Team-scoped required-compaction overrides (optional)
    # Soft thresholds do not compact by themselves while history still fits.
    compaction:
      enabled: true
      threshold_percent: 0.8
      reserve_tokens: 16384
      timeout_seconds: 600

Configuration Fields

Team YAML keys follow the same naming rules as agents: alphanumeric characters and underscores only, and no overlap with agent names. Each configured team must contain at least one unique, known agent. Private agents, and agents whose delegation closure reaches private agents, are not supported in configured teams.

num_history_runs and num_history_messages are mutually exclusive, just like the agent-level settings. When a named team sets these fields, the team scope uses the team-owned policy instead of inheriting one member's history policy.

Team-scoped compaction supports enabled, threshold_tokens, threshold_percent, replay_window_tokens, reserve_tokens, model, fallback_model, and timeout_seconds. When the active team model has a known context_window, MindRoom always computes a final replay plan for the shared team scope and reduces or disables persisted replay for the run when needed. Automatic destructive compaction is enabled by default through defaults.compaction, but it runs only when raw history exceeds the hard replay budget for the next reply. threshold_tokens and threshold_percent set a soft trigger budget for planning metadata and compaction notices. Crossing that soft trigger while still within the hard budget leaves the stored session unchanged and relies on replay fitting.

You can tune team-scoped compaction behavior with these settings:

• Use replay_window_tokens to cap persisted replay and required-compaction planning below the model's real context window without lowering the provider request limit.
• Use reserve_tokens to leave hard-budget headroom.
• Use model to choose the summary model.
• Use fallback_model to name a different model config retried once when the summary model refuses for safeguards; the same input is reused when it fits, otherwise it is rebuilt under the fallback model's own context budget, and after success that model serves the remaining chunks.
• Use timeout_seconds to bound each primary, retry, or fallback summary request; it defaults to 600 seconds, while an explicitly shorter provider timeout remains the stricter cap.
• Set enabled: false to disable automatic pre-reply compaction for a team.

When the active team model window is known, replay safety uses the smaller of it and replay_window_tokens. When that model window is unknown, an explicit replay_window_tokens still supplies the replay-planning window. Each compaction summary input chunk is sized independently from the selected compaction model's real context_window, after reserve, prompt overhead, and a safety margin. Destructive compaction requires the resolved summary input budget to exceed 2,000 tokens. With the default reserve_tokens, this makes destructive compaction unavailable when the compaction model's context window is roughly 10,000 tokens or smaller; lowering reserve_tokens restores availability for such small windows. If you set compaction.model, that summary model must also define its own context_window, but only for the durable summary-generation pass. compaction.fallback_model must also name a configured model with its own context_window; a fallback naming the summary model's alias, or another alias resolving to the same provider and model ID, is ignored because it would resend the refused request to the same model. Manual compact_context remains available when a compaction model and context window are configured and the resolved summary input budget exceeds 2,000 tokens. Compaction uses an in-room lifecycle notice that is edited in place.

When to Use Each Mode

Dynamic Team Formation

When multiple agents are mentioned in a message (e.g., @code @research analyze this), MindRoom automatically forms an ad-hoc team. Dynamic teams form in these scenarios: In threads with multiple human participants, stale thread context does not auto-form a team. A fresh explicit @mention in the current message is required before agents respond.

1. Multiple agents explicitly tagged - e.g., @code @research analyze this
2. Thread with previously mentioned agents - Follow-up messages in a thread where multiple agents were mentioned earlier, as long as the thread has not become a multi-human conversation that now requires a fresh explicit mention
3. Thread with multiple agent participants - Continuing a conversation where multiple agents have responded, as long as the thread has not become a multi-human conversation that now requires a fresh explicit mention
4. DM room with multiple agents - Messages in a DM room containing multiple agents (main timeline only)

Mode Selection

For dynamic teams, the collaboration mode is selected by AI based on the task:

• Tasks with different subtasks for each agent use coordinate mode
• Tasks asking for opinions or brainstorming use collaborate mode

Before model selection completes, explicit mentions carry a provisional coordinate heuristic and thread-derived groups carry a provisional collaborate heuristic. The execution layer asks the model to refine that choice; when model selection fails or returns an unexpected result, MindRoom falls back to collaborate.

Dynamic teams do not have a named teams: entry, so their history replay and compaction policy comes from defaults, not from any participating agent's overrides.