Articles
Stop Mindless Fan-out: A Practical 4-Layer Orchestration Architecture with Claude Haiku 5.5
Claude Haiku 5.5 is fast and cheap, but throwing every task at it in parallel only amplifies misjudgments, reviewer bias, and Supply Chain risks. This article breaks down a layered architecture—Fable for judgment, Opus for orchestration, Sonnet and Haiku for implementation, CI for verification, and Opus for acceptance—and explores which tasks actually warrant a Fan-out.
· 6 min read
Claude Haiku 5.5 was released on October 7, 2026. For prompts within 100,000 tokens, its price is one-twentieth that of Sonnet 5.5, and its latency is the fastest among the current generation of Claude models.
Being both cheap and fast, it's tempting to think: why not break down every coding task and fan them out across a swarm of Haiku instances in parallel, call it a day?
For prototyping, that might fly. In a production engineering environment, however, you quickly run into three problems:
- Small models struggle with ambiguity. Haiku 5.5 is officially positioned for high-volume, low-latency workloads like classification, extraction, routing, and subagent tasks. When requirements carry business ambiguity and require full-system context, it often delivers results that look complete on the surface but guess in entirely the wrong direction.
- Having models pick answers introduces reviewer bias. Feeding dozens of outputs to a large model tends to make it favor versions with "pretty architecture" rather than implementations that are logically and operationally correct.
- Privileges scale with the number of Workers. If parallel subagents are allowed to install packages or edit configuration files automatically, spinning up N Workers creates N potential entry points for malicious packages.
That is why I switched to Hierarchical Orchestration: each layer does only what it excels at, and Haiku's parallel capabilities are reserved strictly for where they are genuinely needed.
The bottom line first: Fable thinks things through, Opus orchestrates and signs off, Sonnet handles core implementation, and Haiku handles mechanical tasks and search-oriented tasks that can be validated automatically. Candidate solutions must pass CI before any model evaluates them.
The 4-Layer Architecture: Judgment, Orchestration, Verification, Acceptance#
Requirements Input
│
▼
[Judgment Layer] Fable: Architectural decisions, task decomposition, Acceptance Criteria
│
▼
[Orchestration Layer] Opus Main Session: Dispatch only, no redecomposition
├─► Path A: Complex but well-bounded ──► Sonnet implementation
├─► Path B: Mechanical tasks ──► Single Haiku
├─► Path C: Search-oriented, multiple approaches ──► Multiple Haiku, each in a separate Git Worktree
│
▼
[Verification Layer] Build, Type Check, Test, Benchmark (Path C keeps only top 2–3)
│
▼
[Acceptance Layer] Opus converges against Acceptance Criteria
Escalation on failure: Haiku retries 2x then fails ➔ Sonnet ➔ Fall back to Opus
Where each model sits is determined by its official positioning and pricing. Below are the figures from Anthropic's official documentation as of October 8, 2026, with prices in USD per million tokens:
| Model |
Official Positioning |
Latency |
Input / Output Price |
| Claude Fable 5.1 |
Advanced reasoning and long-running agentic workloads |
Slower |
$10 / $50 |
| Claude Opus 5.5 |
Sustained agentic coding and knowledge work |
Moderate |
$4 / $20 |
| Claude Sonnet 5.5 |
The sweet spot of speed and capability |
Fast |
$2 / $10 |
| Claude Haiku 5.5 |
High-volume, low-latency classification, extraction, routing, and subagent tasks |
Fastest |
From $0.10 / $0.50 |
Haiku 5.5 pricing has two tiers: when the prompt exceeds 100,000 tokens, the rate shifts to $0.50 / $2.50.
Judgment Layer: Fable Owns Architectural Decisions and Acceptance Criteria#
Not every requirement needs Fable. It is the most expensive and slowest layer, so I only invoke it when requirements are ambiguous, involve cross-system integrations, or demand core architectural decisions.
Fable must deliver three things:
- Proposed solution design
- Task breakdown
- Acceptance Criteria for each subtask that can be validated via tests
Reasoning and task decomposition must happen in the same layer. Only the layer that thoroughly understands the system's blind spots can carve out subtasks with clean boundaries; handing architecture to A and decomposition to B almost inevitably blurs interface definitions.
Security tasks are an exception. The current generation of Claude models includes safety classifiers that return stop_reason: "refusal" when requests are flagged, which can lead to false positives on legitimate security work. Fable 5.1's classifier covers a broad range of security content, as it is officially not designed for the security domain; Opus 5.5, by contrast, permits identifying vulnerabilities in source code. Therefore, for tasks like security vulnerability remediation, I hand the upfront analysis directly to Opus.
Orchestration Layer: Opus Dispatches Without Redecomposing#
Opus acts as the Main Session, responsible for routing and dispatching work. This layer does not overturn architectural decisions or perform a second round of decomposition.
- Path A, complex but well-bounded: Tasks with complex logic but clearly defined interface boundaries go to Sonnet. It is the workhorse for implementation.
- Path B, purely mechanical tasks: Boilerplate code, variable renaming, simple unit tests, and documentation are handled by a single Haiku.
- Path C, search-oriented and optimization tasks: Performance tuning, exploring multiple implementations for complex SQL or Regex, and triaging Flaky Tests are when Fan-out is triggered: multiple Haiku instances are dispatched, each exploring distinct approaches within an isolated Git Worktree.
Regardless of which path a task takes, its output must flow into the verification layer.
Verification Layer: Machines First, Models Second#
A common anti-pattern is taking all code generated in parallel and dumping it directly into Opus or Sonnet for review via prompt.
The problem is that when models read code, they are easily swayed by neatly formatted code and exhaustive type annotations—neither of which guarantees edge cases are handled. Candidate solutions must clear automated gates first:
- Build and Type Check: Compiles successfully with sound typing
- Unit / Integration Tests: Passes unit and integration test suites
- Benchmark / Profiling: Evaluates performance and memory footprint
Anything failing automated checks is discarded immediately. For Path C candidates, Opus reviews only the top 2–3 solutions that passed all checks with the best metrics, saving both context window and token overhead.
Acceptance Layer: Opus Converges, Escalating on Failure#
Finally, Opus evaluates and accepts results against the Acceptance Criteria defined by the judgment layer. When a Worker gets stuck, it follows a structured Escalation Path:
- Haiku fails: After 2 automated fix attempts without passing, retries stop.
- Sonnet takes over to remediate.
- If Sonnet also fails acceptance, it usually signals a contradiction in the task breakdown or underlying assumptions. The task falls back to Opus, which decides whether to route it back to Fable for redecomposition.
Three Rules Before Moving to Production#
Never Fan-out Blindly#
Simple tasks do not warrant multiple Workers, and small models cannot untangle high-ambiguity problems. Fan-out across multiple Haiku instances is only justified for search-oriented tasks featuring a vast solution space paired with rapid, automated validation.
Isolate Environments, Lock Down the Lockfile#
A Git Worktree isolates code changes so parallel Workers don't overwrite each other's files; it does not restrict network access or file system boundaries. Defending against Supply Chain Attacks requires running inside a sandbox while forbidding Workers from installing unvetted packages or modifying the Lockfile. Freely handing out installation privileges is an open invitation for Agents to introduce unverified packages and scripts into your codebase.
Verify with Concrete Metrics, Not Model Critique#
Test results, test coverage, memory usage, and latency are reproducible, comparable benchmarks. Qualitative text evaluations from models can provide context, but they should never serve as the criteria for accepting production code.
Put Cheap Models Where They Belong#
Haiku 5.5 makes running in parallel cheap, but parallelism alone does not make outputs correct. Separate judgment, orchestration, verification, and acceptance first—only then do speed and low cost translate into a genuine engineering edge.
This tiered system is, in essence, the Graph I discussed in AI Agents Are Literally an Agile Team: who works first, where work is handed off, and where issues escalate when things break.