Build a multi-agent verification council

Review a proposed technical change with three subagents: correctness, security, and simplicity. Each starts with isolated context and returns a validated result. The parent checks their evidence and produces the final verdict.

1. Create the reviewing agent

Run:

jazz agent create

Name it change-council, choose the coder persona, and ensure spawn_subagent, repository reading, and git inspection are available. Do not give it mutation tools for a review-only job.

2. Create the workflow

Add workflows/change-council/WORKFLOW.md to the repository:

---
name: change-council
description: "Independently verify a proposed code change before implementation"
agent: change-council
autoApprove: read-only
maxIterations: 60
maxCostUSD: 1.00
maxDurationMs: 900000
---

# Independent change verification

Review the proposal in `PROPOSAL.md` against the current repository. Do not modify files.

Delegate these three questions to separate subagents so that each starts with fresh context:

1. **Correctness:** trace the affected code paths and identify false assumptions or missing failure modes.
2. **Security and operations:** identify changed trust boundaries, credentials, destructive actions, observability gaps, and rollback requirements.
3. **Simplicity:** search for existing abstractions and propose the smallest implementation that satisfies the stated outcome.

For each `spawn_subagent` call, set `resultName` to `review` and pass this object as
`resultSchema`:

{
"type": "object",
"required": ["verdict", "evidence", "risks"],
"properties": {
"verdict": { "type": "string", "enum": ["proceed", "revise", "block"] },
"evidence": { "type": "array", "items": { "type": "string" } },
"risks": { "type": "array", "items": { "type": "string" } }
}
}

Give each subagent only its question, the path to `PROPOSAL.md`, and permission to inspect the repository. Do not tell one reviewer what another concluded.

After all three return:

- reject any conclusion without file, symbol, test, or command evidence;
- resolve disagreements by inspecting the cited code yourself;
- distinguish verified facts from recommendations;
- return one verdict: `proceed`, `revise`, or `block`;
- list the minimum changes required before implementation.

read-only admits spawn_subagent and repository inspection. The workflow also bounds iterations, cost, and wall-clock time.

3. Write a real proposal

Create PROPOSAL.md with the outcome, affected behavior, constraints, migration plan, and validation criteria. Describe the constraints without prescribing the implementation.

4. Run it with live delegation events

jazz workflow run change-council \
  --auto-approve \
  --json \
  --watch subagent,tools,usage

The event stream shows each child start and finish while the final answer remains clean. Each child has isolated context and a bounded iteration budget inherited from Jazz’s subagent configuration. Invalid structured output returns validation errors to the parent instead of silently becoming evidence.

What you should see

A subagent_start and subagent_complete event on stderr for each reviewer:

{"type":"subagent_start","agentName":"Sub-Agent (coder)","task":"Correctness: trace the affected code paths…"}
{"type":"subagent_complete","agentName":"Sub-Agent (coder)","durationMs":42000}

Then one envelope on stdout. answer is the parent’s reconciliation, not a concatenation of the three reviews:

{
  "ok": true,
  "answer": "VERDICT: revise. Re-open the upload stream on each retry (src/upload.ts:88). Reuse withRetry() from src/net/retry.ts.",
  "costUSD": 0.214,
  "costKnown": true,
  "tokenUsage": { "promptTokens": 48213, "completionTokens": 3102, "totalTokens": 51315 }
}

costUSD includes the children. An invalid review object returns validation errors to the parent; check its final verdict explains how it handled any failed reviewer.

5. Use the verdict as a gate

In CI, capture the result with Jazz’s headless output contract and require a human to accept revise or block. Do not let the reviewers merge code themselves. Review and mutation should remain separate capabilities.

For a stronger design, run this workflow before implementation and a separate pull-request reviewer afterward. The first challenges the plan; the second verifies what actually changed.

Read Delegation and Context management for the execution model.