Grounded in research from MIT, Google Research, and CLEAR. The discipline that gets a system architected before it's built. Each gate is a decision the build cannot skip — and each one, when skipped, has a documented consequence in production.
The gates, in order
| Gate | Question | Why it matters |
|---|---|---|
| Gate 0 | Agent needed? | Most systems don't need agents. A deterministic pipeline or a single call is often cheaper, faster, and easier to audit. |
| Gate 1 | Multi-agent? | Only justified when each agent adds new signal. Extra agents that don't add signal add cost and cascade risk. |
| Gate 2 | Topology | Chosen by the shape of the task, not by aesthetic. A flow, a mesh, and a supervisor tree each fit different problems. |
| Gate 3 | Instrumentation | Evaluators and telemetry are in place from week one — not bolted on after the system is already in production. |
| Gate 4 | Protocol | Standard interfaces for tools and peers, so the system connects cleanly and leaves an audit trail. |
Why the discipline exists
The methodology is grounded in research from MIT, Google Research, and CLEAR. Multi-agent systems fail in characteristic ways — cascade failures, runaway token budgets, silent degradation — and most of those failures trace back to a gate that was skipped early. Getting the architecture right before any code is written is cheaper than remediating it in production.
The architecture is the product. Get it right before you build, and the build follows.
For teams comparing vendors, the full methodology whitepaper walks gate-by-gate through the discipline with citations and the CLEAR scorecard methodology. Read the research behind the gates, or request the whitepaper below.