BowSmith, one feature, fully orchestrated: the case study

This is one feature in BowSmith, shipped end-to-end through Opus Max (architect) → Opus (orchestrator) → Sonnet (workers), with the numbers. Not a toy. A feature I'd have budgeted the better part of a week for if I'd built it by hand.

BowSmith, one feature, fully orchestrated: the case study

Five weeks of argument. Time for one receipt.

Everything in this series — the machine-fluency claim, the architect-tier economics, the RPIQ mapping, last week's honest accounting of where it's overkill — comes down to a single testable question: when the shape of the work is genuinely uncertain and you do stand up the full stack, does it pay?

This is one feature in BowSmith, shipped end-to-end through Opus Max (architect) → Opus (orchestrator) → Sonnet (workers), with the numbers. Not a toy. A feature I'd have budgeted the better part of a week for if I'd built it by hand.

The feature

BowSmith needed to ideate a new Feature Epic from short user proposal. Uncertain shape on purpose: unclear data model at the edges, three format branches, a validation surface nobody had mapped, and a "does this even belong in the product this way" question sitting underneath it. Exactly the profile from last week's filter — the shape of the work was the question — so it earned the architect tier.

How it decomposed

The architect didn't write code. It produced a plan and, critically, killed two branches I'd have wasted a day on — a config-driven format system that was more machinery than the three formats justified, and a caching layer for data that didn't move. That's the front-loaded Quality gate doing its actual job: catching direction defects before a single worker starts. From the architect's plan, the orchestrator cut the feature into worker-sized tasks — each scoped to one context window, each with acceptance criteria attached (diagram 1, lower tiers):

  • schema + validation for the field selector
  • three format transformers (fanned out in parallel)
  • the delivery-target adapter
  • the end-to-end wiring and the test harness
The feature's task-decomposition tree — architect plan at the root (two killed branches marked), orchestrator's 6 scoped tasks, Sonnet leaf tasks, with the parallel transformers and the quality gate.

Workers took the leaf tasks. The three format transformers ran in parallel — the moment that makes the wall-clock number look the way it does.

The trace, end to end

The whole run, front to back (diagram 2, the timeline):

  1. Research + Plan (architect) — fuzzy intent in, scoped plan out, two branches killed. [ ~40 min]
  2. Decompose (orchestrator) — plan into 6 scoped tasks with acceptance criteria. [ ~15 min]
  3. Implement (workers, parallel) — leaf tasks, three transformers concurrently. [ ~90 min wall-clock]
  4. Quality gate (reviewer, one tier up) — output checked against the plan's intent, not just "does it run." Two tasks bounced back and re-ran. [ ~30 min]
End-to-end timeline through R→P→I→Q, with the parallel-worker span called out and the ~3h-vs-~4-day comparison.

Same-model self-review was not allowed at the gate — the reviewer sat a tier up, checking against intent. That's the discipline the forthcoming book chapter, "Quality at Machine Speed," is built around, and it's the part I'll spend the most time on at CAST26.

The numbers

Here's what I'm comfortable sharing (diagram 3, the metrics panel). All placeholders in the right shape:

Metrics panel — wall-clock vs. hand-built estimate, rework avoided, tests passing, token spend by tier. Update figures to match the real numbers before publishing.
  • Wall-clock: ~ 3 hours end-to-end, vs. a ~4 day hand-built estimate. The parallel workers are most of the delta.
  • Rework avoided: 2 branches killed at the plan gate that I'd otherwise have built and thrown away — call it a day of avoided work.
  • Tests: [confirm: 100%] of the generated test harness passing at the gate, after [confirm: 2] tasks bounced and re-ran.
  • Token spend: of which the architect tier was ~15% — the expensive tier touched the cheapest slice of the work, exactly the cost-per-leverage logic says it should.

The shape of that last number is the whole thesis in one line: the premium tier ran for 40 minutes on the part that decided everything, and the cheap tier ran for hours on the part that decided nothing. That's not an accident of this feature. That's the stack working as designed.

What last week's caveat buys you here

Last week I spent 1,200 words on where this stack is overkill. This is the other half of the ledger — and the honesty is what makes the win legible. BowSmith cleared the filter: uncertain shape, real leverage, branches worth killing before they got built. That's the profile where three tiers stop being theater and start being the cheapest way to ship the right thing. Get the filter right and you get both — no ceremony on the config fixes, full orchestration on the features that carry risk.

See the full breakdown live

I'm walking through this exact feature — the decomposition, the two killed branches, the gate that bounced two tasks, every number behind the panel — on stage at CAST 2026, August 3–5, Cocoa Beach, FL. If your title has "quality" or "test" in it, this is the one talk this year built specifically for you. Come pull on the numbers in person; I'll have the ones I can't put in a blog post.

If you're testing Fable / Opus Max too, where did it land for you? Especially: has the full stack ever paid off the way the estimate said it would — or did the hand-off overhead eat the win? Bring your receipts to Cocoa Beach.