The RPIQ loop: where the architect tier actually sits

Everyone's arguing about which model is smartest. Wrong question. For three weeks I've been making claims about the three-tier stack — that Fable speaks machine better than human, that the architect tier is for decisions, not work. Claims are cheap. What makes them stick is a methodology that would survive the models being swapped out underneath it. Which, given that Fable is currently unavailable and Opus Max holds the architect seat, is not a hypothetical.

That methodology is the loop I've been running long before any of these models existed: Research → Plan → Implement → Quality. RPIQ. This post maps the stack onto it — and shows why the mapping, not the model, is the thing worth keeping.

The loop, briefly

Every piece of work that ships goes through four stages, whether you name them or not:

Research — understand the problem space before touching it. What exists, what constrains you, what's actually being asked.

Plan — decide what to build and in what order. Boundaries, interfaces, sequencing, what to explicitly not do.

Implement — the typing. The stage everyone optimizes and the stage that matters least to get right the first time, because it's the cheapest to redo.

Quality — did we build the right thing, and did we build it right? Two different questions, and that distinction is the hinge of this whole post.

Skip a stage and it doesn't disappear — it moves downstream and gets more expensive. Skipped Research shows up as a Plan built on a wrong assumption. A skipped Plan shows up as Implementation that has to be done twice. Skipped Quality shows up in production, where it charges interest.

The mapping

Here's where each tier of the stack actually lives:

Opus Max — the architect — owns the front of the loop: R, P, and the first Q. Not the Q at the end. The Q at the beginning: is this plan even worth building? This is the part most people get wrong about the architect tier. They picture it as the smartest reviewer at the end of the pipeline. It's the opposite — it's the reviewer at the start. Killing a bad plan before Implementation costs one conversation. Killing it after costs a sprint.

This, incidentally, answers a question I keep getting: why not plain Opus in the architect seat? Because the architect's job is judgment under ambiguity — fuzzy intent in, defensible plan out, and the spine to say "don't build this." Opus is excellent when the shape of the work is known. The architect tier is what you use when the shape of the work is the question. That difference is the entire line item.

Opus — the orchestrator — owns the hinge between P and I. It takes the architect's plan and decomposes it into tasks a worker can hold in one context: scoped, testable, with acceptance criteria attached. Orchestration is a translation job — from "what should exist" to "what to do next" — and it's where machine-to-machine fluency pays rent daily.

Sonnet — the workers — own Implement. Parallel, cheap, disposable in the best sense: if a worker's output is wrong, you re-run the task, not the project. Volume work at volume prices — the cost-per-leverage logic from last week applied to the loop.

Quality is a gate at both ends

The naive picture of Quality is a checkpoint after Implementation. Tests, review, ship. That checkpoint matters — but it's the second gate.

The first gate is the architect reviewing the plan before any worker sees it. The second gate catches implementation defects; the first gate catches direction defects — and direction defects are the ones that eat weeks. No amount of end-stage review saves a correctly-built wrong thing.

The second gate has its own design problem: who reviews the workers? Not the workers — same-model review inherits the same blind spots. The reviewer needs to sit at least one tier up, with the plan in hand, checking output against intent rather than against plausibility. Reviewer design is a deep enough topic that it gets its own treatment in a forthcoming book chapter, "Quality at Machine Speed" — for now, the short version: quality at machine speed can't mean human review at human speed at both gates. It means designing the gates so machines hold the line and humans audit the gates, not the output.

Why the mapping outlives the models

Fable vanished from availability and this loop didn't flinch — Opus Max slid into the architect seat because the seat was defined, not the occupant. That's the test of a methodology: swap every model in the stack and RPIQ still tells you where each one goes and what "good" means at each stage. Frameworks over favorites.

Taking this to a stage — literally

I'm presenting this loop — the full version, with the BowSmith numbers behind it — at CAST 2026, August 3–5, Cocoa Beach, FL. If your job title has "quality" or "test" anywhere in it, this is the conference where this conversation is happening. Come argue with me about gate design in person.

Next week is the honesty post: three weeks of running this stack, and where it was complete overkill — including the decision flow I now use before reaching for the architect tier at all.

If you're testing Fable / Opus Max too, where did it land for you? Which stage of your loop did it actually own — and which did you just assume it owned? I'm collecting answers.