Building a Multi-Agent System from Scratch: Architecture Patterns

Nov 5, 2026•kadharmfn•View Original

TL;DR Highlight

Splitting work across agents adds coordination problems, so enforce hard limits in code.

Who Should Read

Backend developer splitting work across multiple agents who must choose an architecture and worry about infinite loops and runaway cost in production

Core Mechanics

Three patterns
- Orchestrator-worker, blackboard, and pipeline.
- More than one agent adds a coordination problem on top of the reasoning problem.
Pick by whether you can write the decomposition down
- If it fits a checklist, use a pipeline.
- If the decomposition is known but details depend on input, use orchestrator-worker; if the solution path is unknown, use a blackboard.
Pipelines are easiest to test
- Each stage has an input/output contract, so you can test and version agents independently.
- If steps must loop back, ad hoc branching turns it into an orchestrator.
Blackboards are hard to debug
- The plan lives nowhere, so you reconstruct the read/write sequence after the fact.
- It is closer to debugging a race condition than a call stack.
Four failures you won't see in a demo
- Infinite delegation loops, runaway cost from re-invocation, conflicting concurrent writes, and error propagation between agents.
- A hallucination from Agent A looks like a verified fact to Agent B and gets compounded.
Limits come from code, not prompts
- Cap delegation depth, typically 3 to 5 hops in the author's experience.
- Track a token or cost budget per task centrally, and escalate to a human when a cap is hit.
Multi-agent doesn't buy correctness
- Five agents each hallucinating 5% of the time compound rather than average out.
- The evaluation harness and guardrails decide whether it is safe for users.

Community Reactions

Experience separating code review into its own Claude session
- A commenter runs 4-5 parallel sessions on one branch, coordinating via a shared queue checked every 30 seconds.
- A commit script allows only one session's staged changes to be committed at a time.
- They report 4,454 verdicts on 4,471 commits, with about four in five first reviews finding something and about half requesting changes.
Opinion that sub-agents beat multi-agents
- The commenter suggests wrapping a nested prompt in a tool call invoked by the caller prompt.
- They say concurrent agents won't beat a well-designed hierarchical agent system.
- They propose a global counter increment benchmark for MAS.
Reaction that the post reads as Claude-written
- Several commenters say they close pages with phrases like 'The Honest Summary'.
- Another says they close sites with the default Claude Code theme.
Recommendation of Stanford CS146S lecture
- It covers always-on agents.
- The commenter notes it isn't necessarily about multi-agent systems.

How to Apply

Ask Claude which pattern fits your workflow
- Paste your agent workflow into Claude today and ask whether pipeline, orchestrator-worker, or blackboard fits.
- Use the prompt in the code example.
Add a delegation depth cap and per-task budget
- Put a hop counter in your agent call wrapper and refuse delegation beyond 3-5 hops.
- Sum tokens or cost centrally by task ID and stop without retry at the ceiling.
Build a human escalation path
- When a cap is hit or confidence is low, send the partial state to a ticket or Slack.
- Block quiet retries that present a confident-looking answer.
Add a verification step against hallucination propagation
- Insert a fact-check stage before hand-off between agents and define input/output contracts to test each separately.

Try It

copy & run

# Paste into Claude or ChatGPT (simplified version of the article's method)

You are a multi-agent architecture reviewer. Read the workflow below, pick one of three patterns, and justify it.
- Pipeline: decomposition can be written as a checklist up front and is repeatable
- Orchestrator-worker: decomposition is known but specifics depend on input
- Blackboard: the solution path is unknown until agents start discovering things

[Workflow description]
{{your service's agent workflow}}

[Instructions]
1. Decide which criterion applies.
2. Pick the likely failures: infinite delegation loops, runaway re-invocation cost, conflicting concurrent writes, error propagation between agents.
3. Propose concrete code-level limits for each (delegation depth cap, per-task budget, human escalation).

Next: ask it to turn the proposed limits into call-wrapper code.

Terminology

Orchestrator-workerA manager splits the task, hands pieces to specialists, and gathers results. Workers talk only to the manager.

BlackboardA shared whiteboard where agents write hypotheses and facts and jump in when useful. No single agent owns the plan.

PipelineA conveyor belt where a fixed sequence of agents passes output to the next stage.

Delegation depth capA limit on how many times a task can be handed to another agent. It breaks ping-pong loops.

Evaluation harnessA test setup that runs the agent system repeatedly to measure quality.

Related Resources

Building a Multi-Agent System from Scratch: Architecture Patterns

Nov 5, 2026•kadharmfn•View Original

TL;DR Highlight

Splitting work across agents adds coordination problems, so enforce hard limits in code.

Who Should Read

Backend developer splitting work across multiple agents who must choose an architecture and worry about infinite loops and runaway cost in production

Core Mechanics

Three patterns
- Orchestrator-worker, blackboard, and pipeline.
- More than one agent adds a coordination problem on top of the reasoning problem.
Pick by whether you can write the decomposition down
- If it fits a checklist, use a pipeline.
- If the decomposition is known but details depend on input, use orchestrator-worker; if the solution path is unknown, use a blackboard.
Pipelines are easiest to test
- Each stage has an input/output contract, so you can test and version agents independently.
- If steps must loop back, ad hoc branching turns it into an orchestrator.
Blackboards are hard to debug
- The plan lives nowhere, so you reconstruct the read/write sequence after the fact.
- It is closer to debugging a race condition than a call stack.
Four failures you won't see in a demo
- Infinite delegation loops, runaway cost from re-invocation, conflicting concurrent writes, and error propagation between agents.
- A hallucination from Agent A looks like a verified fact to Agent B and gets compounded.
Limits come from code, not prompts
- Cap delegation depth, typically 3 to 5 hops in the author's experience.
- Track a token or cost budget per task centrally, and escalate to a human when a cap is hit.
Multi-agent doesn't buy correctness
- Five agents each hallucinating 5% of the time compound rather than average out.
- The evaluation harness and guardrails decide whether it is safe for users.

Community Reactions

Experience separating code review into its own Claude session
- A commenter runs 4-5 parallel sessions on one branch, coordinating via a shared queue checked every 30 seconds.
- A commit script allows only one session's staged changes to be committed at a time.
- They report 4,454 verdicts on 4,471 commits, with about four in five first reviews finding something and about half requesting changes.
Opinion that sub-agents beat multi-agents
- The commenter suggests wrapping a nested prompt in a tool call invoked by the caller prompt.
- They say concurrent agents won't beat a well-designed hierarchical agent system.
- They propose a global counter increment benchmark for MAS.
Reaction that the post reads as Claude-written
- Several commenters say they close pages with phrases like 'The Honest Summary'.
- Another says they close sites with the default Claude Code theme.
Recommendation of Stanford CS146S lecture
- It covers always-on agents.
- The commenter notes it isn't necessarily about multi-agent systems.

How to Apply

Ask Claude which pattern fits your workflow
- Paste your agent workflow into Claude today and ask whether pipeline, orchestrator-worker, or blackboard fits.
- Use the prompt in the code example.
Add a delegation depth cap and per-task budget
- Put a hop counter in your agent call wrapper and refuse delegation beyond 3-5 hops.
- Sum tokens or cost centrally by task ID and stop without retry at the ceiling.
Build a human escalation path
- When a cap is hit or confidence is low, send the partial state to a ticket or Slack.
- Block quiet retries that present a confident-looking answer.
Add a verification step against hallucination propagation
- Insert a fact-check stage before hand-off between agents and define input/output contracts to test each separately.

Try It

copy & run

# Paste into Claude or ChatGPT (simplified version of the article's method)

You are a multi-agent architecture reviewer. Read the workflow below, pick one of three patterns, and justify it.
- Pipeline: decomposition can be written as a checklist up front and is repeatable
- Orchestrator-worker: decomposition is known but specifics depend on input
- Blackboard: the solution path is unknown until agents start discovering things

[Workflow description]
{{your service's agent workflow}}

[Instructions]
1. Decide which criterion applies.
2. Pick the likely failures: infinite delegation loops, runaway re-invocation cost, conflicting concurrent writes, error propagation between agents.
3. Propose concrete code-level limits for each (delegation depth cap, per-task budget, human escalation).

Next: ask it to turn the proposed limits into call-wrapper code.

Terminology

Orchestrator-workerA manager splits the task, hands pieces to specialists, and gathers results. Workers talk only to the manager.

BlackboardA shared whiteboard where agents write hypotheses and facts and jump in when useful. No single agent owns the plan.

PipelineA conveyor belt where a fixed sequence of agents passes output to the next stage.

Delegation depth capA limit on how many times a task can be handed to another agent. It breaks ping-pong loops.

Evaluation harnessA test setup that runs the agent system repeatedly to measure quality.

Building a Multi-Agent System from Scratch: Architecture Patterns

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

Related Papers

Related Resources

Building a Multi-Agent System from Scratch: Architecture Patterns

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

Related Papers

Related Resources