Most teams that fail at agent systems don't fail at code. They fail at architecture — they reach for multi-agent topologies the task never needed, then spend months debugging emergent failures that were designed in from the start. Our answer is a gate discipline: five architecture decisions, each made and defended before any build begins.
None of this is original. The findings come from MIT, Google Research, the University of Washington, and a body of arXiv work on how agent systems actually scale. What we did was turn those findings into a checklist the build cannot skip.
Gate 0 — do you even need an agent?
The default is not an agent. The default is a single strong LLM with retrieval. You escalate to agents only when the task's properties actually demand it: a long horizon, real branching, genuine tool use, or a maker-checker loop that needs separation of duties. Most systems people describe as "agentic" are a single model with a good prompt and a vector store. Building them as agents adds cost, latency, and failure surface for nothing.
So Gate 0 asks one question and asks it adversarially: what property of this task can a single retrieval-augmented model not satisfy? If you can't name one, you don't pass.
Gate 1 — does it need to be multi-agent?
This is the gate most teams fail. The MIT signal test is simple: every agent in the system must add new exogenous signal. If your "specialist" agents are just bounded capabilities a manager invokes in sequence — summarize, then classify, then extract — they are not agents adding signal. They are functions, and you should build a single agent that calls them as tools.
The evidence is stark. In the scaling-agents study (arXiv:2512.08296), multi-agent variants lost up to 70% against a single-agent baseline on sequential planning tasks. More agents did not mean more capability. They meant more coordination overhead, more places for errors to enter, and worse outcomes on exactly the kind of step-by-step work many enterprise pipelines consist of.
"Architecture-task alignment, not agent count, predicts success." — Kim et al., Towards a Science of Scaling Agent Systems
Gate 2 — what topology fits the task shape?
If you've earned a multi-agent system, the topology is chosen by task shape, never by aesthetic. There are three honest choices:
- Flow — a pipeline — for regulated, sequential work where each stage hands off to the next and order matters.
- Orchestration for parallelisable breadth, where a coordinator fans work out and gathers it back.
- Peer mesh only when agents genuinely produce independent evidence that needs to be reconciled — not when you just want them to "collaborate."
Topology is the single highest-leverage decision in an agent system, and it is almost always made by feel. We make it by task shape and write down the reason.
Gate 3 — is it instrumented from week one?
You cannot operate what you cannot see. Gate 3 requires the observability to exist before the system does: structured outputs treated as data contracts, per-stage evaluators, a token budget audit, and human-in-the-loop checkpoints at every high-stakes boundary. CLEAR telemetry is plumbed in from week one — not bolted on after the demo works.
CLEAR-dim, our evaluation harness, scores five dimensions per stage. Comprehensiveness: does the system handle the full task surface, checked against a golden set. Latency: p50 and p95 per stage, cost-aware, because faster is not better if it costs ten times as much. Explainability: can the system tell you why, with reasoning traces visible at every HITL approval. Auditability: every external call, model invocation, and human decision written to an immutable store with DPDP-compliant retention by class. Reproducibility: same input, same output within stochasticity bounds, with a cascade test that replays prior failures against every release.
Gate 4 — are the protocols right?
The last gate is plumbing, and it is where cost discipline lives. MCP for tool access. A2A for peer-to-peer communication. ACP for governance. And one hard rule: never dynamically mutate the tool set mid-iteration. KV cache invalidation is a 10x cost penalty, and a system that rewrites its own tool list on every turn pays it on every turn.
Why we trust this.
The gates are built on published work, not opinion. The scaling study (arXiv:2512.08296, Kim et al., MIT · Google · UW) ran 260 configurations across six benchmarks; relative performance against a single-agent baseline ranged from +80.8% on decomposable financial reasoning to −70.0% on sequential planning. The error-cascade work (arXiv:2603.04474, Xie et al.) names three failure classes — cascade amplification, topological sensitivity, and consensus inertia — and shows a genealogy-graph governance layer lifting defence success from 0.32 to 0.89. CLEAR gave us the five-dimension production benchmark we extended into CLEAR-dim.
So this isn't a methodology we invented. It's a methodology we enforce. The gates are how we stop ourselves — and our customers — from building the thing the research already showed will fail.