What I Got Wrong About Claude Orchestration (and What 14 Months of Cleanup Taught Me)
The clean architecture that looks intentional in a diagram is what survived fourteen months of mistakes that had to be made, named, and replaced.
About nine months in, sitting in front of a transcript at 11pm, I realized I’d been refining the wrong architecture for half a year.
Not refining badly. Refining well. The system worked — briefs got written, artifacts got shipped, the daily routine ran. The problem was that the thing I was making better was structurally off. I was tightening bolts on the wrong machine.
That moment is what eventually became this article series. The clean version of what I do now — dispatch-only orchestrator, six workers, role boundaries, file-based memory, brief contracts — looks intentional in a diagram. It isn’t. It’s what survived a year-plus of mistakes I had to undo. Each mistake had to be made, named, and replaced before the next layer of the architecture could even become visible.
What follows is the catalog. Seven mistakes, what each cost, and the version that survived.
Mistake 1: Treating the orchestrator like a worker
Earlier this spring I burned roughly 800,000 tokens on a single daily routine — for the orchestrator alone, before any worker produced anything. The orchestrator was reading sandbox configs, brand references, photo libraries, prior content examples, all “to remember worker context.” It was studying the workers in order to dispatch them. That’s not orchestration. That’s a worker that happens to also write briefs.
The fix was a role boundary. The orchestrator dispatches. Workers build. Crossing the boundary is the bug, not the feature. Article 1 in this series is the full version of that story.
What this mistake cost: most of the token burn, most of the time, most of the cognitive load. What survived: the dispatch-only orchestrator.
Mistake 2: One CLAUDE.md doing three jobs
For most of the first year, every project I touched had a single CLAUDE.md trying to do everything. Identity (who Claude is in this project), routing (which files to load for which task), and state (what’s currently shipped, what’s next). One file, three jobs, three different read patterns, three different reasons to reload.
The result: CLAUDE.md grew without bound. The session loaded all of it on every cold start, including state that should have been recomputed and routing that should have been task-specific. The file became a cache of cache-misses.
The fix was splitting it into three: CLAUDE.md (entry, identity, what this project is), CONTEXT.md (routing, what to load per task), STATUS.md (state, what’s shipped and what’s next). Three files, three update cadences. Article 3 walks through that split.
What this mistake cost: bloated session starts and constant manual pruning of a file that didn’t want to be one file. What survived: the three-file pattern.
Mistake 3: Spawning subagents to feel productive
There was a stretch where I dispatched parallel subagents for almost every multi-step task. It felt efficient. Two subagents in parallel, half the wall-clock time. The math was obvious.
The math was wrong. Each parallel subagent paid the full context-load cost. The “parallel” speedup was usually less than the overhead of spinning two of them up. Worse, the two outputs needed integration — which I had to do myself, sequentially, because the parallel work had produced two slightly different interpretations of the same input.
The fix was a four-condition test for spawning a subagent: locked spec, parallelizable units, isolated-context requirement, and no integration follow-up. If any of the four fails, you don’t parallelize. Article 4 in this series is the full breakdown.
What this mistake cost: token spend for the illusion of speed, plus integration debt every session. What survived: the four-condition subagent test.
Mistake 4: Verifying file existence instead of content
The defect class that hurt the most. A worker would ship; the verify step would check that the expected files existed; the brief would close as shipped; the artifact would be silently wrong. File present, content wrong. Every downstream stage treated the bad content as if it were good, because the gate had passed.
I caught the first one by accident — a preview HTML rendered fine but the embedded caption was from the wrong source MD. Then I caught a second. Then a third. The pattern: existence checks pass while content silently rots.
The fix was cross-stage trace verification, drawn from ICM (Internal Coherence Maximization, from Jake Van Clief’s work) § 6.2. The verify step doesn’t just check that the file exists; it checks that the content downstream matches the content upstream. Article 5 is the deep dive.
What this mistake cost: the worst kind of defect — invisible until something else breaks. What survived: verify-handoff as a standard verify step.
Mistake 5: Treating Claude as the whole stack instead of the 10%
This one took the longest to see, because it didn’t show up as a defect — it showed up as a vague feeling that everything cost too much for what it produced. I was using Claude for parsing calendar files, looking up rows, deriving routing decisions, and generating output. Four jobs, one bill.
Van Clief’s 60-30-10 (ICM) names the layers: Infrastructure (60%) / Orchestration (30%) / AI (10%). AI is the smallest layer. Most of the value lives in infrastructure and orchestration — things that already work without Claude. I was paying Claude to do work that ten lines of bash or a static rule file could do for free.
The fix was migrating the 60% (file parsing, row lookup) toward tiny scripts and the 30% (routing decisions, worker boundaries) toward declarative rule files. Claude handles the 10%: generation. Article 6 audits three workflows through the layers.
What this mistake cost: paying premium model rates for infrastructure work. What survived: the 60-30-10 layer separation as a design constraint.
Mistake 6: Asking Claude to remember instead of giving it memory
Six months of telling Claude “remember our convention is X” produced zero accumulated knowledge. Every session started cold. Every correction landed in the same place the last one had landed. I had treated memory as a feature (“remember this”) instead of a system (files on disk, indexed, loaded at session start).
The fix was a memory/ folder, scoped by role, typed by purpose (user / feedback / project / reference), with a flat MEMORY.md index loaded every session. Plus the discipline of what not to save — code patterns derivable from current files, git history, ephemeral state. Article 7 covers the system.
What this mistake cost: every correction had to be re-discovered every session. Drift compounded silently. What survived: file-based memory with a typed taxonomy.
Mistake 7: Driving Claude session-to-session instead of briefing it
The last one to break. For too long, I free-form drove sessions — typing, reading, correcting, retyping. It felt natural; it was how I’d worked with people for years. With Claude it produced one-hour artifacts that should have taken fifteen minutes, because I was the loop, and the loop was slow.
The fix was the brief-as-contract pattern. Six sections: Purpose / Inputs / Outputs / Constraints / References / Verify. A worker reads the brief cold and executes; if it has to ask, the brief is incomplete. The session ends when Verify passes, not when I get tired. Article 8 is the deep dive.
What this mistake cost: every session required me to be present for every decision. There was no leverage. What survived: the six-section brief.
What survived
After the cleanup, what’s left is small: role boundaries (orchestrator dispatches, workers build — the boundary is the architecture); the three-file pattern (CLAUDE.md / CONTEXT.md / STATUS.md — entry, routing, state); the four-condition subagent test (parallelism has to earn its overhead); verify-handoff (content match, not file existence); 60-30-10 layer separation (AI is the 10%, the rest is infrastructure and orchestration); file-based memory (typed, scoped, indexed); brief-as-contract (cold-start the worker).
Seven patterns. Each one earned its place by being the version that survived after several wrong versions got tried and pruned. None of them is novel. All of them are load-bearing.
The meta-lesson
Building an AI system is more pruning than building.
The visible architecture — a diagram with clean arrows between an orchestrator and three workers — is what’s left after the experiments that didn’t work got deleted. The diagram doesn’t show the always-on assistant pattern I tried for six weeks. It doesn’t show the per-day MD logs I maintained for two months before noticing nobody read them. It doesn’t show the over-prescribed brief templates that grew faster than they were used. Those got cut. The diagram is the residue.
A teammate looking at the current setup might assume it was designed. It wasn’t. The current setup is what showed up once enough wrong things had been removed.
Article 11 in this series is the companion to this one — instead of mistakes that got fixed, it’s experiments that got cut entirely. Different category, same meta-lesson: your system is what survives the cuts.
What I’m giving you, and what I’m not
You have the catalog: seven specific mistakes, each named, each with what it cost.
The seven surviving patterns, each linked to a dedicated article.
The meta-lesson on pruning.
What I’m not giving you: the rejected experiments themselves. Article 11 handles those. And I’m not giving you my actual filled briefs, rule files, or memory entries — those are shaped to my work. The mistakes catalog travels. The contents don’t.
If you’re somewhere in year one of building a Claude-based system, you’ll recognize at least three of these mistakes in your own setup. That’s the value of writing them down: the mistakes are common. The fixes are too.