Multi-agent systems are trendy right now, but most tasks do not need them. Here's the decision framework I use before splitting a workflow into multiple agents.
Everyone wants to build a multi-agent system before they have proven that a single agent could not have done the job. I made this mistake myself, more than once, and it always cost me the same way: more complexity, more failure points, and no measurable improvement in output.
Running 50 agents in production taught me that multi-agent is not a maturity level. It is a tool for a specific class of problem, and most problems are not that class.
Before deciding on architecture, I ask one question: does this task require genuinely different expertise at different stages, or does it just have multiple steps?
Multiple steps is not the same as multiple roles. A task that reads an email, extracts three fields, and drafts a reply has multiple steps but one job. A single agent with a well-structured prompt handles that fine. A task that requires researching a topic, writing long-form content in a specific voice, and then optimizing that content for search intent involves three genuinely different skill sets, each of which benefits from a focused prompt and its own context window.
The exact architecture, memory layers, and delegation patterns I use to run 50 agents across two businesses.
Get the AI Agent Blueprint →The task fits comfortably in one context window. If the agent never needs to hold more information than a single well-designed prompt and a reasonable amount of retrieved context can provide, splitting it into multiple agents just adds coordination overhead for no benefit.
The steps are sequential and dependent, not specialized. Step two always needs step one’s output, and neither step calls for a separate skill set. This describes most operational automations: onboarding a client, generating an invoice, triaging an inbox. One agent, one clear prompt, one clean chain of tool calls.
Latency matters. Every hop between agents adds time. If the task is customer-facing and needs to respond quickly, a single well-tuned agent will almost always outperform a relay of three agents passing context back and forth, even if the multi-agent version is theoretically more capable.
The task needs specialized reasoning at each stage. My content pipeline uses separate agents for research, drafting, and editing because each of those genuinely benefits from a prompt tuned to that one job. A research agent optimized for source verification writes worse first drafts than a drafting agent optimized for narrative flow, and vice versa.
Parallel execution saves real time. If three independent pieces of research can happen simultaneously instead of sequentially, splitting them into three agents running in parallel is a meaningful speed gain, not just an architectural preference.
One agent’s failure should not block the whole task. In my error handling setup, isolating agents by responsibility means a failure in the research stage does not corrupt the drafting stage’s state. A monolithic agent handling everything in one context makes failures harder to isolate and recover from.
The task benefits from a reviewer role. Some of my most reliable pipelines have a dedicated agent whose only job is checking another agent’s output against a rubric before it moves forward. That adversarial-ish structure catches errors a single self-reviewing agent tends to miss, because the same model reviewing its own work inherits its own blind spots.
Multi-agent systems are more expensive to build, harder to debug, and slower to iterate on than most people expect going in. Every additional agent is another prompt to maintain, another set of failure modes to handle, and another handoff where context can get lost or misinterpreted.
I do not reach for multi-agent because it sounds more sophisticated. I reach for it when a single agent has demonstrably hit a ceiling, either on quality, latency, or fault isolation, that a better prompt cannot fix.
Start with one agent. Prove it is not enough before you build a second.
The newsletter breaks down real architecture decisions from Ayla OS, including the ones where I split an agent and immediately regretted it.
Subscribe to The Signal
One issue per week. The biggest AI build of the week, the top five videos worth your time, and an operator's read on what actually matters. For builders who ship, not dreamers who scroll.
No spam. Unsubscribe anytime. Just The Signal.