Council

Council Protocol

This protocol is loaded on demand by the architect runtime. The architect prompt keeps only activation, action, and hard safety constraints; the full execution details live here.

MODE: COUNCIL

Activates when: user invokes /swarm council <question> (optionally with --spec-review).

Purpose: convene a fixed three-agent multi-model General Council (generalist / skeptic / domain expert) for an advisory deliberation. The architect runs a curated web research pass upfront, dispatches the three agents in parallel with the gathered RESEARCH CONTEXT, routes any disagreements back for one targeted reconciliation round, and synthesizes the final user-facing answer directly.

This mode is ADVISORY. It does not block any other workflow and does not modify code, plans, or specs. The output is for the user (general mode) or for the spec being drafted (spec_review mode is available via /swarm council --spec-review for manual spec review). General Council advisory input is offered as an early workflow option in MODE: BRAINSTORM (Phase 1b) and MODE: PLAN before save_plan.

Pre-flight (always run first)

1. Read council.general from the resolved opencode-swarm config. Resolution is global first (~/.config/opencode/opencode-swarm.json), then project override (.opencode/opencode-swarm.json). A global config is valid and must be used when no project override is present; do not fail after checking only the project file. If council.general.enabled is not true OR no search API key is configured (neither council.general.searchApiKey nor the corresponding env var TAVILY_API_KEY / BRAVE_SEARCH_API_KEY), surface to the user: "General Council is not enabled. Set council.general.enabled: true and configure a search API key in global ~/.config/opencode/opencode-swarm.json or project .opencode/opencode-swarm.json." Then STOP.

Research Phase (always run before dispatching council agents)

2. Formulate 1-3 targeted web_search queries that best capture the information needed to answer the question. Prefer specific, keyword-focused queries over broad ones.

   Hard grounding rules:

   • Do not append a model training-cutoff year to searches.
   • Use web_search with its default freshness: "auto" behavior for current queries unless the user explicitly asked for a historical window.
   • Preserve each web_search result's normalized query, temporalIntent, freshness, and removedStaleYears metadata in RESEARCH CONTEXT audit notes.
   • For current, latest, today, now, state-of-the-art, pricing, release-status, legal/regulatory, financial, security, or otherwise time-sensitive questions, the Research Phase must produce usable current sources before council dispatch.
   • If web_search returns no results or an error for a time-sensitive question, stop and surface the failed search result to the user instead of dispatching ungrounded members.
   • For stable/non-current questions, if web_search returns no results or an error, note this in the dispatch message and proceed without a context block. In that degraded mode, members may use stable background knowledge only and must not make current-fact claims.

   Compile all successful results into a RESEARCH CONTEXT block in this format:

RESEARCH CONTEXT
================
[1] <title> - <url>
    <snippet>
    query: <normalized query>; temporalIntent: <current|historical|unspecified>; freshness: <day|week|month|year|none>; removedStaleYears: <comma-separated years or none>

[2] <title> - <url>
    <snippet>
...

Read-before-cite discipline

When citing source code, API behavior, CLI flags, file paths, or line ranges, the synthesizing agent MUST read the actual file or tool output first. Search snippets, file globs, conversation history, and prior-round memory are not sufficient evidence. Specific anti-patterns to refuse in synthesized output:

• Quoting a line range (e.g. src/foo.ts:123-145) without reading those lines in the current revision.
• Restating an API signature, error message, or option flag from prior context after the source has been edited.
• Citing bunSpawnSync / child_process.spawnSync behavior from documentation that pre-dates the current version.

The synthesized answer's sources array should reference URLs and tool outputs the agent actually retrieved during the current session, not sources inherited from prior rounds. Mark confidence: LOW for any claim the agent could not verify against current source this round.

Round 1 - Parallel Independent Analysis

3. Dispatch the active swarm's council_generalist agent, the active swarm's council_skeptic agent, and the active swarm's council_domain_expert agent with dispatch_lanes_async when available -- one lane per agent. Before the first dispatch, verify from the session's actual tool list whether the controller's lane tools are present; when they are absent, use the native parallel subagent path from the start rather than discovering the gap on first failure. Record the returned batch_id, then continue only non-dependent architect work: prepare the synthesis outline, normalize the RESEARCH CONTEXT citations, and draft disagreement categories. Do not call convene_general_council or present conclusions from running lanes. Dispatch promptly — do not accumulate extensive planning prose before the call, or output truncation may swallow the tool call itself. Keep each lane prompt compact: send shared context ONCE via the common_prompt field, or have lanes read it from a file by absolute path, instead of inlining the same large blob into every lane prompt. Each dispatch message must include:
   • The question
   • Round number: 1
   • The CURRENT DATE in ISO YYYY-MM-DD form
   • The full RESEARCH CONTEXT block from step 2
   • Instruction: "Cite from the RESEARCH CONTEXT for external evidence. Your memberId and role are hardcoded in your system prompt."

Do NOT share other agents' responses at this stage.