The problem
A single broad “review this diff” prompt tends to blur security, correctness, performance, testing, architecture, and operational concerns together. It can also encourage findings to inherit each other's assumptions.
The system
The reviewer runs locally and sends a sanitized diff to isolated specialist agents. Each reviewer sees the code change through one lens, then an orchestrator deduplicates, cross-references, and applies confidence-aware severity handling.
- Local Ollama inference keeps normal review runs off cloud APIs.
- Specialists are isolated so one agent's framing does not automatically bias the others.
- Security, correctness, dependencies, migrations, observability, integration risk, test coverage, and other domains have explicit ownership.
- Generated tests are opt-in; normal review does not quietly write to the codebase.
- The same review engine is available through CLI, MCP, and editor integration.
The design constraint
More agents are not automatically better. The project only earns its complexity if independent lenses produce materially better findings without creating an unmanageable pile of low-confidence noise. The orchestrator exists to reduce that cost, not to make the architecture look sophisticated.
What this demonstrates
The useful part is the review system around the model: isolation, sanitization, confidence, output structure, failure modes, opt-in write behavior, and interfaces that let the tool meet developers where they already work.