If your multi-agent LangGraph system doesn’t beat a well-prompted single agent with tools on a real eval, it’s architecture theater. That’s the argument a top post on r/LangChain makes this week.
The post identifies three costs that real orchestration adds:
- Latency — each agent hop is another round trip to the model
- Cost — more calls, more tokens, higher bill
- Failure modes — every handoff between agents is a new failure point
The “multi-agent” label gets applied loosely. A common LangGraph pattern — a self-reflecting generator plus reflector — often runs the same LLM with different prompts. Two roles, one model, one call chain dressed up as collaboration.
NOTE
LangGraph’s own multi-agent docs describe two runtime patterns: one equivalent to the AgentExecutor in LangChain, and a second with cycles. The “multi-agent” label covers both, including single-agent loops.
With MCP servers giving a single agent access to dozens of tools, the gap between one agent with good tools and five agents talking to each other keeps shrinking. The orchestration tax has to buy real eval gains to justify itself.
The test before you ship: run the same task through one well-prompted agent with MCP tools or function calling. If it matches or beats your multi-agent graph on eval, delete the graph.