@yibie: Recommended: A multi-agent system design guide by LangChain CEO Harrison Chase. The core argument is extremely simple but rarely made clear: multi-agent systems can be divided into "reading" and "writing" — reading is easy to parallelize, writing is prone to conflicts. That's why Anthropic's res…

Recommend this guide on multi-agent system design by LangChain CEO Harrison Chase. The core thesis is extremely simple but rarely explained clearly: multi-agent systems are divided into “reading” and “writing” — reading is easy to parallelize, writing often leads to conflicts. That’s why Anthropic’s research agent uses multiple agents for research (reading), but lets a single agent do synthesis (writing). If you’re considering a multi-agent architecture, this article will help you avoid the most common design mistakes.

How and when to build multi-agent systems

There’s a classic line in Anthropic’s blog post:

“Multi-agent research systems excel especially for breadth-first queries — that is, tasks that involve pursuing multiple independent directions simultaneously.”

“Multi-agent systems work mainly because they help spend enough tokens to solve the problem… Multi-agent architectures effectively scale token usage for tasks that exceed the limits of single agents.”

“For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.”

“Some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.”

Core principle: “reading” is simpler than “writing”

The most important distinction in multi-agent systems: “reading” tasks are easier to parallelize than “writing” tasks.

This insight comes from comparing two well-known multi-agent systems — Cognition’s coding system and Anthropic’s research system.

• Read operations are naturally parallel. Multiple agents can simultaneously search, read, and evaluate different information sources without conflict.
• Write operations introduce conflicts. When multiple agents write code or content simultaneously, their decisions can produce incompatible outputs. As Cognition’s blog puts it: “Actions carry implicit decisions, and conflicting decisions carry bad results.”

Anthropic’s Claude Research is the best example of this principle. The multi-agent architecture in this system mainly handles the research (reading) component. The actual writing — synthesizing findings into a coherent report — is deliberately handled by a single main agent in a unified call. This design choice acknowledges that collaborative writing introduces the core challenges of multi-agent writing.

When multi-agent is appropriate

Suitable:

• Breadth-first exploration (pursuing multiple independent threads simultaneously)
• Total information exceeds a single context window
• Scenarios requiring extensive interaction with numerous complex tools
• Tasks with high enough value to justify the increased cost of multiple agents

Not suitable:

• Domains where all agents need to share the same context
• Many dependencies between agents
• Collaborative tasks involving significant “writing” operations
• Tasks that cannot economically support the extra token consumption of multiple agents

Engineering requirements

Durable execution. When errors occur, we can’t restart from scratch every time — that’s expensive and frustrating for users. You need a system that can resume from where the agent got stuck. This is the core idea behind LangGraph: all long-lived agents need built-in persistence.

Observability and debugging. Agents are harder to debug than traditional software. You need to know: was the search query bad? Did it choose a poor source? Did a tool call fail? Full production tracing lets you systematically diagnose why agents fail.

Evaluation. Start with a small eval set — even ~20 data points is enough — but start early. Agent evaluation is harder than traditional ML evaluation because the output space is larger and “success” is harder to define.

Conclusion

There’s no “one-size-fits-all” answer for building agent systems. Start with a single agent, and only add multiple agents when they bring a clear, defensible increase in value. Any framework should let you slide freely along this spectrum — from single agent to simple multi-agent to full swarm.

Source: Harrison Chase / LangChain, “How and when to build multi-agent systems” https://langchain.com/blog/how-and-when-to-build-multi-agent-systems

#MultiAgent #AgentEngineering #SystemDesign