Squads and council

Two different multipliers

Squads and councils both add agents to a run, but they solve opposite problems. A squad splits one stage's work across parallel workers to finish faster. A council asks several models the same question to answer better. Squads are about throughput; councils are about judgment.

Squads

Every authored agent stage runs as a squad. There is no per-stage toggle: a manager agent looks at the stage objective and decides whether it is worth splitting. If it is not, one worker carries the whole objective and the run looks exactly like a single-agent stage.

The three steps:

1. Decompose. The manager receives the stage objective and emits zero or more subtask lines in the form SUBTASK: <title> :: <instruction>. Its decomposition is broadcast to every participant.
2. Dispatch. One worker per subtask, run in parallel behind a concurrency semaphore. Each worker gets a clean context and sees only its own subtask.
3. Reconcile. An integrator agent re-reads the original objective, the per-worker summaries, and emits the stage's routing directive.

The reconcile step runs only after a real fan-out. When the manager chose not to split, the lone worker's reply is the stage output — an extra integration run would only restate it and double the cost.

The disjointness rule

Every squad role — manager, workers, integrator — runs in the same worktree: the stage's own. Nothing is branched per worker. That makes the decomposition contract load-bearing, and the manager prompt states it plainly:

Workers run IN PARALLEL in this SAME worktree. Subtasks MUST touch disjoint
files — two workers editing one file will corrupt each other.
Each subtask must be independent: workers cannot see each other's context or
output, only the shared tree.
If the work is small, inherently sequential, or cannot be split into
file-disjoint units, emit NO SUBTASK: lines — a single worker will handle the
whole objective.

Workers are told to touch only the files their subtask needs and never to run git commit, branch, checkout or stash — the working-tree changes are left in place for the manager to reconcile.

Coordination

Workers coordinate through a mailbox — a small SQLite message bus opened in-memory per stage run, scoped to task-<id>-<stage>. What actually flows:

A failed worker is not fatal. Its mail task is requeued and its error recorded; the stage output header reports how many workers ran and how many succeeded:

squad: fanned out (3 worker(s), 2 ok)
  - worker [ok] Port the reach selector
  - worker-2 [FAILED] Update the fixtures
  - worker-3 [ok] Refresh the snapshot tests

A manager or integrator failure does fail the stage.

Concurrency

Fan-out is bounded by the pipeline's Max concurrent agents setting (presets 1, 2, 3, 4, 6, 8, 10, 12, default 2), and the manager may propose at most five subtasks per stage. Squad progress lands in the task's Sub-tasks panel as checklist rows, with a final Integrate branches row.

Council

A council is not a separate app or mode. It is a property of a persona: the persona's own model chairs, and 2 to 4 counselor models give independent opinions.

question → 2–4 counselors answer independently (Response A, B, C…)
        → each counselor reviews the others' answers, blind, and ranks them
        → the chairing persona's model synthesizes the accountable verdict

Three properties matter:

• Independent first. Counselors answer in parallel, without seeing each other.
• Blind cross-review. Each judge receives every opinion except its own, anonymized behind labels. Self-grading is a bias with no upside, so it is removed rather than corrected for. Each judge ends with a FINAL RANKING: block; a ballot that breaks the contract is dropped.
• One accountable answer. The chairman receives the identified answers, the reviews and the aggregate ranking (average position, lower is better) and writes the verdict. A chairman failure fails the council; a counselor failure does not.

Fewer than two counselors is not a council. Past four, the marginal opinion stops paying for its cost and latency — so the bench is capped at four.

Configuring one

The Council: row lives in the persona form (Control → Agents). Turn it on and TDE seats a bench for you, preferring provider diversity: counselors from different model families than the chairman, because several variants of the same family produce several variants of the same blind spot.

Counselors are stored as fully qualified refs — llm/<runtime>/<model> — so one council can combine Claude, Codex, Cursor, OpenCode, TDE Pass and Ollama models. The model id alone would be ambiguous: different CLIs expose overlapping ids and need different authentication and execution paths.

Rules the form enforces:

• At least two counselors, or the toggle must be off, before you can save.
• No seat may duplicate another or equal the chairman.
• Turning the toggle off keeps the bench, so re-enabling restores it.
• Changing the persona's LLM re-seats the bench, or turns the council off with Council turned off: the new LLM's catalog can't seat 2 counselors.

Running one

The Council button appears on the task detail toolbar only when the task sits at a human-gate stage and some persona has a runnable council. Pressing it builds the question from the task id, title, description and the worktree's git diff HEAD --stat -p (truncated at 24 KB), and toasts N counselors deliberating — verdict lands as a comment.

The verdict is posted as a task comment authored by council:

⚖ Council verdict (Reviewer)

<the chairman's synthesis>

Peer ranking (avg position):
  claude-opus-4-8   1.33
  gpt-5.5           2.00
  composer-2.5      2.67

Counselors that failed are listed too, so a thin verdict is never silently thin.