Multi-agent automations in client work: when does it actually pay off vs. add complexity?

Most agent builds I see fall into one of two shapes:

(A) Single agent with tools. One LLM, function-calling loop, does the planning + execution + transforms in one place.

(B) Multi-agent with sub-agents. A planner dispatches to specialist agents, hands off to a coordinator, sometimes a reviewer at the end. Shows up in CrewAI, LangGraph, AutoGen, and increasingly in n8n / Make / Zapier flows that chain multiple LLM nodes.

For people running automations in production, especially in client / agency work:

  1. When did you actually NEED to split into multiple agents instead of giving one agent more tools?
  2. What's a realistic upper bound on agent count before things get unstable? 3? 5? 10?
  3. What's the most common failure mode you've hit? Infinite loops? Bad handoffs? Token cost blowing up? Agents disagreeing with each other?
  4. If you bill clients per workflow run or per outcome, has multi-agent helped or hurt your margins?

Trying to figure out if multi-agent is genuinely the future of automation, or if "one agent with 30 tools" is the production-stable choice and multi-agent is mostly a demo aesthetic that costs you on the bill.

Real workflow stories preferred. Specific tool names and approximate agent counts even better.

(Disclosure: building AgentSonar, a coordination observability tool for multi-agent systems. Trying to calibrate what's actually shipping vs what's marketing copy.)

Posted May 6, 2026, 9:36 PM UTC

11
Loading comments…