12.1 Why Run Agents in Parallel

A single agent iterates one artifact at a time. It generates, you review, it revises. That loop works perfectly for a single polished output. But there are tasks where you don't want one good answer---you want ten options fast: hero treatments, copy variants, motion pacing alternatives, color-scheme explorations. That's the moment agents as a team become worth the overhead.

Open Design's daemon is a Node 24 Express server with SSE streaming (covered in Chapter 02). It accepts concurrent requests over separate SSE channels and stores each artifact independently in the .od/projects/<id>/ layout. As of September 2026, the daemon does not enforce a concurrency ceiling at the application layer---it relies on the underlying Node event loop and your provider's rate limits. That means you can connect multiple agent CLIs to the same project simultaneously.

The practical benefit: layout exploration that would take three sequential loops in a solo session---generate, review, repeat---can run in one round when three agents fan out in parallel. The coordination cost is real: you write a clear brief for each role, wait for the slower agent to finish, and then do a merge pass. That cost is low when you have seven variations to produce. It's high when you have one.

There's also a quality argument for the variation case specifically. When you run one agent through three hero options sequentially, each option is influenced by the previous one---the agent anchors on what it just made. When three agents each produce one option independently, you get genuine divergence. That divergence is the product; it's why you parallelized in the first place.

12.2 Assigning Roles

Before you open a terminal, define the roles. A role has three parts: a name, a responsibility boundary, and an artifact target. The boundaries matter because agents don't coordinate with each other---they only read the brief you gave them. If two roles overlap, you'll get two artifacts solving the same problem and a harder merge.

Here's the role framework I use for visual design goals. It maps to the artifact types Open Design generates natively (web prototypes, motion graphics, copy layers), so each role produces something the preview can render independently.

The Orchestrator role doesn't have to be an agent. In most runs I play orchestrator myself: I write the goal brief, paste role-specific sub-briefs into each agent CLI, and do the review pass manually. Automating the orchestrator step is possible---you could use Claude Code as an agent-of-agents, delegating sub-briefs programmatically via MCP---but it adds a layer of indirection that usually slows down small teams more than it helps. The value of a human orchestrator is judgment at merge time: knowing that Variation-B fits better than Variation-A for reasons no brief could specify.

12.3 Routing Roles to Agents

Chapter 11 covers the full agent comparison. The routing logic for multi-agent design work follows one principle: use capable proprietary agents for work that requires the most context-holding and the highest quality ceiling; use cheap or open agents for work that needs volume. This isn't a permanent hierarchy---agent capabilities and pricing churn monthly, and the table below will age. It reflects the best routing I've found as of September 2026.

12.4 Running the Team

The walkthrough below runs the Layout, Variations, and Copy roles in parallel against one design goal: a landing page for a local-first design tool. All three agents connect to the same Open Design project via MCP (Model Context Protocol), which was covered in Chapter 10. Each agent generates into a separate artifact within the project.

$ od project new "Landing Page - Local-First Tool"
# Output: project created at .od/projects/lp-local-first-001/

# Shared goal brief (paste into every role agent first)
Goal: a landing page for a local-first design tool.
Brand: use Open Design's own DESIGN.md (load from project).
Constraints: single-page HTML, no external dependencies,
  self-contained artifact, dark theme.

# Layout agent brief
Role: Layout.
Your job: page structure and hero section only.
Deliver: one single-page HTML prototype with
  structural sections (hero, features, CTA, footer)
  and placeholder content. No copy, no motion.

# Variations agent brief
Role: Variations.
Your job: three alternative hero section treatments.
Deliver: three separate HTML fragments, each a
  standalone hero section. Label them Variation-A,
  Variation-B, Variation-C.

# Copy agent brief
Role: Copy.
Your job: headline, subheading, CTA, and feature
  copy options.
Deliver: a Markdown document with three sets of
  headline + subheading + CTA. Label them Copy-1,
  Copy-2, Copy-3.

# Terminal 1: Layout agent (Claude Code)
$ od mcp install claude-code
# Paste shared goal brief + layout brief, submit

# Terminal 2: Variations agent (OpenCode) — start 5-10s later
$ od mcp install opencode
# Paste shared goal brief + variations brief, submit

# Terminal 3: Copy agent (Cursor) — start 5-10s later
$ od mcp install cursor
# Paste shared goal brief + copy brief, submit

4

Monitor the SSE streams. Each agent's generation streams into a separate artifact in the Open Design preview. Watch the project artifact list in the UI: you should see three artifacts populating in near-parallel. The Layout artifact will likely finish last because it's the most complex; the Copy artifact (Markdown) will finish first.

12.5 Merging and Reviewing

The merge step operates as an editorial design review because Open Design lacks a built-in artifact merge tool as of September 2026. You open each artifact in the sandboxed preview, decide which structural choices from Layout to keep, which hero treatment from Variations fits best, and which copy set from Copy to apply, then instruct one agent (typically the Layout agent, which maintains the structural artifact) to integrate the selected copy and hero treatment. The merge executes as a prompt instructing an agent rather than an automated file operation.

# Round 2 prompt to Layout agent
Keep the current page structure.
Replace the hero section with Variation-B
  (the split layout with the terminal screenshot).
Apply Copy-2 (headline: "Design on your machine").
Export the merged artifact as a self-contained HTML file.

# Asking a fresh agent to "merge" three artifacts
Here are three HTML files. Combine them into
  one landing page.
[paste Variation-A, Variation-B, Variation-C, Layout, Copy-1...]
# Result: agent produces a fourth artifact that
# misses the point of all three

The effective merge uses the Layout agent as the owner of the final artifact and treats the other outputs as references it incorporates via a clear revision prompt. The ineffective merge hands the merge problem to a new agent with too much context and no clear decision.

12.7 When Not to Use a Team

Multi-agent design isn't always the right call. The coordination cost is real: writing per-role briefs, managing multiple terminal sessions, staggering starts, and doing a deliberate merge pass. That overhead is worth it when you're exploring a wide design space. It isn't worth it in these cases:

• Single-artifact outputs. If the deliverable is one polished landing page, one reviewed deck, or one branded email, a single capable agent iterated through the four-beat loop will outperform a three-agent fan-out on quality and time.
• Tight feedback loops. If you're iterating every five minutes on a detail, switching between three CLI sessions kills the flow. Stay in one agent.
• Unclear role boundaries. If you can't write clean, non-overlapping role briefs in under ten minutes, the task isn't structured enough to parallelize. Clarify the goal first.
• Provider-limited environments. If your BYOK setup is rate-limited or you're on a single low-quota API key, the contention overhead makes multi-agent slower than sequential.

The test is simple: could you review all the outputs side by side in one sitting and pick a winner in under thirty minutes? If yes, parallelism earns its overhead. If the outputs require reconciliation, context-sharing, or sequential refinement before any of them are reviewable, you've added coordination for negative gain. Go back to one agent, define the goal more tightly, and run the generate-preview-iterate-export loop from Chapter 03.

As of September 2026, multi-agent design orchestration in Open Design functions primarily as an operational practice rather than a packaged product feature. While the platform does not include an orchestration UI, agent scheduler, merge tool, or artifact diff viewer, it provides a daemon supporting concurrent generation, a project model where multiple artifacts coexist inside a single .od/projects/<id>/ directory, and a hosted Team Workspace (introduced in 0.18.0) where reviewers share a unified studio. The orchestration layer---briefing agents, staggering runs, and evaluating outcomes---remains under your direct procedural control.