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:
- When did you actually NEED to split into multiple agents instead of giving one agent more tools?
- What's a realistic upper bound on agent count before things get unstable? 3? 5? 10?
- What's the most common failure mode you've hit? Infinite loops? Bad handoffs? Token cost blowing up? Agents disagreeing with each other?
- 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