Prisms: Multi-Angle Independent Review (And When It Hurts)

In short

A prism is an angle of independent assessment of a finished artifact, taken from the point of view of a role: security, tenant isolation, regressions, accessibility, performance, localization, and more. It's not an executing agent and not a "style persona": the contract is narrow — a pass/warn/block verdict, findings with severity, and one "here's what I would change." Quest ships 13 prisms; each carries its own lens questions (a checklist for its angle), red lines (blockIf), a vote weight, and the right of veto. Several prisms judge the artifact independently — none of them sees the others' verdicts — and then a synthesis step tallies the votes. This article walks through a worked example of how that catches a hole, and gives an honest account of the situations where multi-angle review hurts and is better left off.

What it is

A prism (lens) is an angle of independent assessment of a single artifact from the point of view of a specific role: security, tenant isolation, regressions, accessibility, performance, localization, design craft, and so on. The key point: a prism is not an executing agent that does things, and not a "style persona." Its contract is narrow and checkable — look at a finished artifact from its own angle and return a verdict of pass | warn | block, plus findings with a severity level (info/minor/major/critical) and one "here's what I would change."

The base Quest engine has 13 such prisms. Each one carries:

• lens questions — the checklist for its angle (security asks: "is input concatenated into SQL/shell/HTML?", "did a secret leak into code or logs?", "is a protected path reachable without auth?");
• red lines (blockIf) — what turns the verdict into block;
• a vote weight (1 by default) and the right of veto.

Why it works this way

A single agent that wrote the code and then approved its own work in one pass is a conflict of interest. Multi-angle review is built-in distrust: different angles hit the artifact independently (fan-out), and synthesis then tallies their votes. Five angles are promoted to veto judges because they cover the invariants whose breakage costs the most: security, tenancy (cross-tenant), gating (revenue leakage), regression, data-integrity. They carry weight 2 and the right of veto.

The synthesis rule is hard-wired and deterministic (and rendered into the package as literal text, so even a weak model executes it):

Any critical from a veto prism → an overall BLOCK, regardless of the other votes. Otherwise BLOCK if the summed weight of block votes is ≥ the threshold. A tie → BLOCK (safety wins).

Worked example: how a hole gets caught

Input. The engineer agent added a GET /api/reports/:id route that reads a report by the id in the URL. The artifact (code + api) goes to the Review phase.

What the engine does:

1. Triggers switch on the prisms for code/api artifacts: security, tenancy, gating, regression, perf, maintainability, business. Each one looks independently, without seeing its neighbor's verdict.
2. The tenancy prism (role "Data Architect," weight 2, veto) works through its questions and catches it: the resource id comes from client input with no ownership check against the organization — a classic IDOR, cross-tenant reads are reachable. Its verdict: block, severity critical.
3. The other prisms returned pass/warn.
4. Synthesis: there's a critical from a veto prism → overall verdict BLOCK, no matter that six other angles said "fine."
5. The loopUntilDry cycle starts: the class of problem gets fixed (not just this route — grep every place where an id comes from input without a scope), then the affected angles only re-judge. This repeats until it runs dry (no critical/block), for at most 2 review→fix rounds (the third degrades — per Anthropic and Cloudflare), then it stops and reports the open items to the owner.

Result. An IDOR that one self-satisfied pass would have waved through gets caught before production by a single independent angle with veto rights — not by a team's "average opinion," where the security vote would have dissolved among seven "looks fine overall"s.

When multi-angle review HURTS (honestly)

More judges isn't always better. Both the research literature and common sense back this up:

• Correlated errors. Models from the same family are trained on similar data and fail in similar ways. Adding one more similar angle on the same model often isn't new information but an amplification of a shared mistake (the "popularity trap": consensus locks in a plausible but wrong answer). The value of prisms lies in different roles asking different questions, not in the number of votes from one model.
• Cost and latency. Every angle costs tokens and time. Running 13 prisms on a variable rename is waste. That's why prisms are scoped by phase and artifact type (a11y only on UI, data-integrity only on migrations), and small tasks go through a light cycle.
• Self-enhancement and other biases. LLM judges tend to praise output that is verbose, authoritative, and their own. Narrow, checkable lens questions and a severity model reduce this but don't eliminate it.
• Noise drowns the signal. If every angle showers you with minor remarks, the critical veto gets lost. Hence severity levels and a quality threshold: we polish to a set bar, not forever.

Bottom line: prisms are strong where the angles are genuinely independent and genuinely different in role, and where weights and vetoes reflect the real cost of a mistake. On a trivial edit, or with seven identical angles, the game isn't worth the candle — and the engine accounts for that through proportionality.

The honest boundary

Prism verdicts today are ADVISORY: the model is instructed to obey the synthesis, but there's no exit code that physically blocks delivery on a BLOCK (apart from the Claude hook on dangerous commands). The text of the prisms — questions, red lines, weights — ships in the open: you can read it before you buy, and read and tune it afterwards. Teams that need always-current checks can use server-bound mode: judge and gate return the verdict from the server and the rubrics are updated centrally, so the engine gets new checks without a reinstall (without a server model key, a deterministic baseline check runs instead, honestly labeled deterministic-fallback). What you buy is an assembled, calibrated veto model that works out of the box — discipline that pays off on your first task.

Sources:

• Correlated Errors in Large Language Models (arXiv)
• Exploring LLM-as-a-Judge — Weights & Biases