If you've been living under a rock, the Anthropic Agent SDK is the real deal for orchestrating multi-step work. The insight most people miss: you don't need one giant Claude Opus doing everything. You need one Opus orchestrator directing 3–6 parallel Haiku workers, each writing one blog post independently, outputs flowing back into a commit batch.
This post is the real architecture. No tutorials. I'll walk through the pattern we use for Aidxn blog production: how to split work, brief templates, quality gates, cost ($0.40 per 1800w post), and the exact KPIs that matter.
Why Orchestrator + Workers Beats Single-Agent Write
The naive approach: one call to Claude Opus, "write 6 blog posts". You'll get a slow, expensive, context-thrashing mess. Opus drowns in the cumulative context of six separate voice briefs, templates, research links, and internal links. Token overhead kills you.
The better way: one Opus instance reads your brief index, parses instructions, then dispatches 3–6 Haiku instances in parallel. Each Haiku gets a tight brief (200–300 tokens): post slug, title, angle, internal links, voice rules, template reference. Haiku writes the 1800w post independently. Main agent collects outputs, does QA, stages commits in batch. Throughput: 6 posts per hour, cost: $2.40 total ($0.40 per post). Quality: higher because each worker's context is tight, no bloat.
The token math: one Opus orchestration call (~50K context read, ~200 token output) costs roughly $0.50. Six Haiku posts at ~6K input tokens each (brief + template + reference) and ~2K output tokens (1800 words) = ~50K input, ~12K output = ~$0.20 total. Add batch QA review + commit: another $0.30 Opus. Total: $1 per batch of six posts, or ~$0.17 per post. Reality: you'll run more like 3–4 batches per active hour when iterating, so budget $0.40–$0.50 per final shipped post.
Architecture: The Three Layers
Layer 1: Orchestrator (Claude Opus, context-window: 200K). Reads the blog index (titles, angles, voice rules), validates each brief for completeness, prints the dispatch list, then calls the Agent SDK run_in_background to spawn workers. Opus waits for all workers to finish, collects outputs, does a 60-second QA scan (checks for voice voice consistency, word count, internal link presence, title accuracy). If 2+ posts fail QA, ask Aiden before staging commits. Otherwise: auto-stage + auto-commit in batches of 3.
Layer 2: Worker (Claude Haiku, context: 200K). Gets a single brief: {slug, title, angle, internal_links: [url1, url2], brand_voice, template_path, topic_bank}. No fat. Reads the template once, checks voice rules (Fireship-style, 350–600 words, 2–3 sentence paragraphs, code-first, strong opinion). Writes the post to a temp buffer, stages it, reports back stdout with {slug, word_count, internal_links_used, quality_score}. If write fails (context limit, validation error), worker logs and exits; orchestrator retries with Opus (the expensive fallback).
Layer 3: Batch Commit (Local Git, triggered by Orchestrator). After all workers finish and QA passes, orchestrator calls git add, git commit -m "docs(blog): batch post drop — 6 posts · orchestrated with Haiku", git push origin main. Commit message includes the post slugs and word count summary. Deploy happens via Netlify webhook on push.
The Brief Template (What Haiku Actually Gets)
{`{
slug: "aider-sub-agent-patterns-parallel-haiku",
title: "Parallel Haiku Sub-Agents — Shipping 6+ Blog Posts Per Hour",
smlTitle: "Orchestrator + Workers Pattern for Content Scale",
angle: "Real meta-story: how Aiden uses Claude Code's main agent (Fable / Opus) to direct parallel Haiku sub-agents for blog production. Each sub-agent gets a tight brief + template reference + voice rules → writes one ~1800w post → main agent commits in batches. Throughput: 6-12 posts per active hour.",
category: "AI Engineering",
internalLinks: [
{ url: "/pricing", anchor: "pricing" },
{ url: "/blog/anthropic-api-cost-optimization-velocity-x-brain", anchor: "api-cost-optimization" }
],
brandVoice: "Aidxn Design: confident, polished, design-engineering forward. Premium feel. Audience: developers, agency owners, decision-makers.",
templatePath: "src/pages/blog/working-with-claude-code-on-production-website.astro",
voiceRules: "Fireship-style. 350–600w. 2–3 sentence paragraphs. Self-aware tech humour. Code-first (1–3 blocks). Concrete numbers. Strong opinions.",
topicBank: "~/.claude/aidxn-blog-keywords.md"
}`}This fits in ~500 tokens. Haiku reads it once, reads the template (another 300 tokens), and writes. No ambiguity. No "I'm not sure what voice to use" — the brief is the voice.
Quality Control Gates
After all workers finish, orchestrator does a 60-second automated QA pass. Check for: (1) internal links present + formatted correctly, (2) word count between 350–600, (3) title matches brief, (4) slug matches filename, (5) H2 / H3 hierarchy (no single H2, no H3 before H2). If any post fails 3+ checks, flag it for review. If 2+ posts fail, dump the batch and ask Aiden. Otherwise ship.
Real-world regressions caught this way: Haiku once wrote "500 words" but actually shipped 280. Another time, voice drifted to overly formal (ChatGPT tutorial energy instead of Aiden's take). The QA gates catch both before they hit production.
Why This Beats Outsourcing or Hiring
Hiring a full-time blog writer costs $50K–$80K annually (loaded). A contractor: $30–$60/hour. This pattern costs $0.40 per post at scale, so roughly $8/post. At 30 posts/month = $240/month. Amortized: $2,880/year vs. $50K employment. Even at $50/post (including all overhead + Opus QA + commits), you're still under $4K/month. The voice is controlled (no off-brand drift), the quality is repeatable, and the throughput is locked in. Plot twist: the real win isn't cost — it's that you can ship 6 posts before lunch and still iterate each one live on your preview URL before merging.
Scaling Beyond Six Posts
Dispatch 12 workers? The main agent's context gets groggy juggling 12 outputs. Better pattern: orchestrator spawns a "batch supervisor" (second Opus) after 6 workers finish. Supervisor collects the next 6, does QA, reports back. This keeps any single Opus context under 150K after the batch-collect phase. For 50+ posts per session, dispatch multiple supervisors and have one "head orchestrator" wait for all supervisors to finish, then do a final consistency check (no duplicate topics, voice consistent across the batch, internal link mesh is sound). Behold: a content pipeline that scales to 100 posts before hitting context limits or cost cliffs.
Frequently Asked Questions
Won't Haiku miss nuance that Opus would catch?
Not if the brief is specific. Haiku is 90% as capable as Opus on well-defined tasks — and "write a blog post given a title, angle, and voice rules" is well-defined. Where Haiku struggles: open-ended creative work ("write something interesting about AI"). Where Haiku shines: templated work with explicit constraints. This is templated work.
What about consistency across the batch?
That's what the orchestrator QA is for. Orchestrator reads all 6 posts at once and checks for tone drift, repeated phrases, shared misconceptions. One post shipped with "AI is a superintelligence", another with "AI is a language model" — orchestrator flags the contradiction before ship. Costs a second Opus call, but it's batch-level, not per-post.
Can I use this pattern for other content?
Absolutely. Newsletter issues, product changelog entries, Twitter threads, documentation pages. Anything templated with explicit voice rules scales this way. Where it breaks: bespoke creative pieces where the angle is discovered during writing. Templates + constraints = Haiku wins.
What about SEO?
Internal link mesh (orchestrator validates all posts link to each other + key hub pages like /pricing), keyword presence (brief mentions target keyword + topic bank), and meta descriptions (orchestrator generates these from post summaries). This pattern doesn't replace keyword research — brief preparation does. But once you have the angle, Haiku respects the SEO brief just as well as Opus does.
What model versions work here?
Orchestrator: Claude 4.5 Opus or Claude 4 Opus. Workers: Claude 3.5 Haiku or Claude 3 Haiku (avoid 3.0 — context window too small). Why Haiku for workers? Cost and latency. Haiku's 200K context is overkill for a single 1800w blog post, but it's the right size for the brief + template + reference + output. Opus would be wasteful.
The Bottom Line
Orchestrator + Workers isn't a new idea (MapReduce, anyone?). But the Agent SDK makes it trivial to implement for content production. One Opus instance, 6 Haiku instances, 20 lines of dispatch logic. Six finished blog posts, ready to review on preview URLs, within an hour. Yes really.