Opus Max as architect: what actually changed when Fable went away

I got back from CAST26 with one question stuck in my head, because I got asked it maybe fifteen times in the hallway track:

"So what do you actually lose without Fable?"

Short answer: less than you'd think — if you know what the tier is for.

Last week's post was the emotional version of this story: I lost my favourite tool, and the constraint made me better. That one was about me. This one is about the machinery. What does the architect tier actually do, independent of whichever model is sitting in it — and how well does Opus Max hold the seat?

The architect tier is three jobs, not one

Every time this comes up, people describe the top of the stack as "the smart one." That's not a definition, it's a compliment. When I actually traced what the tier was doing across the last two months of BowSmith work, it collapsed into three specific jobs:

1. Fuzzy intent → structured plan. I arrive with something half-formed. The architect tier's job is to turn that into a specification with named components, explicit constraints, and stated assumptions. Not code. A plan someone else could execute.

2. Architecture and boundaries. Where does this live, what does it touch, what is it forbidden to touch. This is the job that prevents the orchestrator below from making forty locally-sensible decisions that add up to a mess.

3. The first quality gate. Before a single worker runs: is this plan even worth building? This is the one everybody skips, and it's the one that saves the most time.

Notice what isn't on that list: writing the code. The architect tier doesn't implement. The moment it starts implementing, you've collapsed your stack and you're paying architect prices for worker output — which is exactly the trap I wrote about when I took the tier out of my delivery work on purpose.

Where Opus Max matches, and where it doesn't

Handing the seat to Opus Max wasn't a like-for-like swap. Here's the honest breakdown after two months (diagram 2).

Job 1 — intent to plan: comparable, with a caveat. Opus Max produces plans of similar structural quality. The caveat is input tolerance. Fable would absorb a vague brief and quietly reconstruct what I meant. Opus Max doesn't do that as generously — it either asks or it commits to an interpretation. Which sounds worse and turned out to be better, for the reasons in last week's post.

Job 2 — architecture and boundaries: comparable, more literal. Opus Max holds boundaries well but states them more literally than it infers them. If I don't say "don't touch the persistence layer," I'm more likely to get something that touches the persistence layer. So I say it now.

Job 3 — the first quality gate: this is where I had to change my habits. Fable was noticeably willing to tell me a plan wasn't worth building. Opus Max will do it, but it needs the invitation. Left to itself it tends toward "here's how to build what you asked for" rather than "you shouldn't build this."

The two habits I changed

Both fixes are on my side of the interface, not the model's.

I made the plan spec explicit. I stopped relying on the architect tier to infer the shape of its own output. The brief now names what the plan must contain — components, constraints, assumptions, and the things deliberately out of scope. Boring, and it removed most of the round-trips.

I made the kill-gate a required field. The plan spec now ends with a mandatory section: reasons not to build this, and what you'd build instead. Not optional, not "if you have concerns." A required output. That single change recovered most of what I thought I'd lost with Fable.

That second one is worth sitting with. What I read as "Fable has better judgment" was substantially "Fable volunteered its objections and Opus Max waits to be asked." The judgment was available in both. Only one of them offered it unprompted. If you're evaluating a model for this seat, that distinction matters enormously and it will not show up in any benchmark.

The reframe: it's a role, not a product

This is the part I'd want you to take away, and it's why I stopped writing about Fable specifically.

The architect tier is a role in your system. It has a job description — those three jobs above — and an interface contract with the tier below it. Any model that can do the job description and honour the contract can hold the seat. Some will need more explicit prompting than others. That's a configuration difference, not an architecture difference.

Design the seat, and a model going unavailable is an afternoon of adjustment. Design around a favourite, and the same event is a crisis. I got to run that experiment involuntarily, and the portable criteria from last week came directly out of it.

There's also a quieter point hiding in job 3. A quality gate that only fires when you remember to ask for it isn't a gate — it's a habit, and habits decay. Making it a required field in the spec is what turns it into part of the system. That's squarely the territory I've been circling in the RPIQ loop post and in quality at machine speed — and it's the thread running toward the forthcoming book chapter on "Quality at Machine Speed." More on that when the date is confirmed.

Next week

I'm writing up the CAST26 recap — what landed, what didn't, and the questions from the room that I didn't have good answers for. I'll share the slide deck with it, so if you wanted the diagrams from the talk, that's the one to watch for.

If you're testing Fable / Opus Max too, where did it land for you? Specifically: has your architect tier ever told you not to build something — and did you have to ask it to, or did it volunteer?