There's a temptation in AI architecture right now to throw multiple agents at every problem, because multi-agent systems sound more sophisticated and, frankly, demo better. We've turned down requests to build five-agent systems for problems that genuinely needed one well-designed agent, because adding agents adds complexity, and complexity in a regulated environment is something you should only pay for when it's actually buying you something.
When you genuinely need more than one agent
The honest answer is: when a workflow has distinct phases that require fundamentally different skills, and where having one phase double-check another phase's work adds real value. KYC onboarding is a good example. One agent extracts and structures data from a submitted document. A second, separate agent validates that extracted data against your compliance rules and existing customer records. A third handles the actual drafting of any communication back to the customer if something's missing.
Could one agent do all three? Sometimes. But there's a real argument for separation here that has nothing to do with making the architecture diagram look more impressive — it's about not letting the same agent both extract data and grade its own extraction. A validation agent that's independent from the extraction agent functions like a second pair of eyes, which is exactly the dual-control pattern banks already use for human-run processes. We're not inventing a new control concept. We're applying an old one to a new kind of worker.
The actual failure mode of multi-agent systems
Here's what goes wrong when multi-agent systems are built carelessly: nobody can say, after the fact, which agent actually made the decision that mattered. Agent one passes something to agent two, who passes it to agent three, who takes an action — and if that action turns out to be wrong, the postmortem becomes an archaeology project. Was it bad data from agent one? A misjudged threshold in agent two? A reasonable decision by agent three given flawed inputs? If the handoffs between agents aren't logged as rigorously as the actions themselves, you've built something that's worse for accountability than a single agent would have been, because now there's a chain of custody nobody can actually trace.
How we think about handoffs
Every handoff between agents in a system we build gets logged with the same rigour as an action taken against a live system — what was passed, what confidence score came with it, and what the receiving agent did with that input. This sounds like an obvious thing to do until you've seen a system that doesn't do it, at which point a six-month-old decision becomes genuinely unexplainable, and "the AI made an error somewhere in the pipeline" is the only postmortem anyone can offer a regulator.
One accountable owner, regardless of how many agents are involved
The principle that matters most, no matter how many agents are in the pipeline, is that there's still one human owner accountable for the whole workflow's output. Multi-agent doesn't mean multi-accountability. It means more moving parts that all still answer, ultimately, to the same person, the same audit trail, and the same override switch. If a vendor's multi-agent pitch can't tell you who that person is, the complexity they've added is a liability dressed up as sophistication.
A simple rule of thumb
Before adding a second agent to any workflow, ask what specific failure mode it prevents that a single, well-designed agent with good validation logic couldn't prevent on its own. If there's a real answer — usually something about independent verification or a genuinely different skill requirement — build it. If the honest answer is "it sounds more advanced," don't. Your future audit trail will thank you.