Why Claude Code's Parallel Subagents Disagree on Design
By The WAALEE Team · · 5 min read
Fan out three Claude Code subagents to build a five-page site, one on marketing pages, one on the dashboard, one on settings, and you'll get the pages fast. You'll also get three different button radii, two shades of the same blue, and a navbar that quietly resets its spacing between page two and page three. Nobody wrote a bad prompt. The agents just never agreed on what the design was in the first place.
Subagents don't share a brain, by design
A Claude Code subagent starts in a fresh context window: its own task prompt, a minimal system prompt, and basic environment details. No shared memory with the agent running next to it, no lateral communication, no inherited sense of what the other subagent already decided about color or type. One explainer of how subagents actually work is blunt about this: isolation is the feature, not a bug, because it keeps each subagent's context clean for its own task. That's great for splitting backend and frontend work. It's a problem the moment two subagents are both making visual decisions.
Run that same setup as three subagents against five pages and you can watch it happen directly. A walkthrough of a Claude Code agent team building a five-page site with three parallel subagents specifically flags checking that navigation stays consistent across pages as a manual step, and recommends rewinding to before the point an agent invented its own color scheme and re-prompting from there. That's not a workflow tip, that's a workaround for the fact that nothing stopped the drift from happening.
The two fixes people are actually trying
- A reviewer subagent. Some teams add a "creative director" agent whose only job is to re-read every page's layout, color, typography and spacing and flag mismatches after the builders are done. It catches drift after the fact, which means the fix always happens on the second pass, never the first.
- A written design spec file. Point every subagent at the same markdown file of rules before it starts. This helps, but a paragraph of adjectives ("clean, modern, blue accent") still leaves each subagent to pick its own hex value and radius from scratch, independently, every time.
- Neither fixes the root cause: subagents aren't short on instructions, they're short on a single source of truth they're all reading the exact same values from.
Fixed tokens are the one thing that travels across the isolation
A reviewer agent and a style doc both still ask each subagent to interpret something. The only input that doesn't get reinterpreted is a value. If every subagent's task prompt includes the literal token file, your real primary blue as a hex code, your real button radius in pixels, your real type scale, there's nothing left to invent. Agent one and agent three can run in total isolation from each other and still land on the same button, because they're not deciding the button, they're reading it.
This is a smaller ask than it sounds. You don't need to write that token file from a brand brief or a memory of what your site looks like. If you already have a live site, its deployed CSS is the token file, it's already been decided, you just haven't pulled it into a shape a subagent's prompt can carry. Extract it once, hand every subagent the same short, literal reference, and the context isolation that caused the drift stops mattering.
Where the parallel-agent design-drift problem is actually documented, and where the fix lives:
- Claude Code subagents explainer: Lays out exactly why subagents don't share context or memory by default, including a sample creative-director reviewer agent definition.
- MindStudio agent-team walkthrough: Real example of three parallel subagents building a five-page site, with the manual rewind-and-reprompt fix for color drift spelled out.
- WAALEE: Extracts your live site's actual tokens once, so every subagent's prompt carries the same fixed values instead of each one guessing independently.
Fan out the work, not the decisions
Parallel subagents are a real speedup, splitting a site across three workers genuinely is faster than one agent doing it in sequence. The mistake is letting that split include design decisions that should have been made once, upfront, and handed to every worker as a fixed value. Make the palette and the type scale non-negotiable inputs instead of open questions, and isolation stops being the thing that breaks your design.