Multi-agent systems are everywhere right now, every framework demo, every conference deck, every blog post. The implicit message: more agents mean more capability. After building both single-agent and multi-agent systems in regulated enterprise settings across banking, healthcare, and insurance, we've come to a different conclusion. Most production agentic systems should start with one well-designed agent and only split into multiple agents when they hit specific, concrete limits.
This session is a practitioner's field guide to making that decision. We'll look at where single agents genuinely outperform multi-agent setups (latency, cost, debuggability, context coherence), where multi-agent is the right call (true isolation boundaries, parallel subtasks, role-specific models), and the failure modes of each. We'll share real examples from .NET modernization work and a compliance-driven multi-agent workflow in insurance, including what broke in production and what we learned.
You'll leave with a five-signal decision framework, a checklist of multi-agent anti-patterns to avoid, and a clearer view of when the simpler answer is the right one. This is a deliberately contrarian take on a hype-heavy topic, grounded in working systems rather than framework demos.