"Multi-agent system" gets thrown around like it means one thing. It doesn't. Wire the same set of agents together three different ways and you get three systems with completely different failure modes, latency, and (the part that actually matters in compliance) three different stories you can tell a regulator about how a decision got made.
So the architecture isn't a detail you settle later. It's the decision. Here are the three shapes I keep coming back to, what each is genuinely good at, and where each one bites you.
Pattern 1: The sequential pipeline
The simplest one, and don't let anyone make you feel basic for reaching for it. Agent A does its narrow job and hands off to Agent B, which hands off to Agent C. Each agent owns one stage and nothing else.
What I love about this pattern is that it's honest. Every handoff is a checkpoint you can inspect, validate, and gate. You can stop the line between any two stages, look at exactly what passed through, and either approve it or kick it back. For anything that's already a process in the real world (document intake, clinical trial reporting, getting a regulatory filing ready), this maps cleanly onto how the work already flows.
Reach for it when the work has obvious stages with clear gates between them.
It bites you when you need things to happen at once. The pipeline is a single lane. One stage stalls and everything behind it waits. And if stage three discovers stage one made a bad call, you're paying to walk the whole thing back.
Pattern 2: Orchestrator and specialists
Now there's a brain in the middle. An orchestrator takes the goal, breaks it into pieces, hands each piece to a specialist agent, and decides when it has enough to call it. The specialists don't know about each other. They just answer the orchestrator.
This is the pattern for decisions that need several kinds of evidence pulled together before anyone can rule. Think AML alert triage: you want transaction history, the customer's risk profile, and known typologies all gathered and weighed before a recommendation lands. The orchestrator is the thing that knows which questions to ask and when the answer is complete.
Reach for it when the decision is a synthesis problem: many signals, gathered in parallel, reconciled into one call.
It bites you when the orchestrator becomes the whole system's center of gravity. All the hard judgment now lives in one place, which means all the risk does too. Get its prompting or its fallback logic wrong and every downstream decision inherits the mistake. This is the pattern that most rewards careful engineering and most punishes hand-waving.
Pattern 3: Collaborative review
Stop handing work down a line. Give the same input to several independent agents, let each form its own view, then reconcile. A panel, not an assembly line.
The point here is to not trust any single model's judgment on something that matters. When the stakes are high enough (model risk review, fraud adjudication, a prior-authorization decision that affects someone's care), you want more than one read, and you want disagreement to be visible rather than averaged away. If three agents land in the same place, that's signal. If they split, that's exactly the case a human should see.
Reach for it when one model's verdict isn't good enough and consensus (or the lack of it) is itself the useful output.
It bites you when you cut corners on the reconciliation. The synthesis layer can't be another fuzzy model that vibes its way to an answer; then you've just added a fourth opinion. It has to be deterministic, because in regulated work you have to be able to explain precisely why the panel's split became a final decision. And running several agents over the same input costs several times the compute. You're buying confidence, and confidence isn't cheap.
So which one?
Don't pick by which sounds most sophisticated. Pick by the shape of the problem.
Three questions get me most of the way there. How reversible are the downstream actions: can you afford to be wrong and fix it, or does a wrong move ship? How much latency can you tolerate: is this real-time, or overnight batch? And how complex is the decision: a clean handoff, a synthesis, or a genuine judgment call?
In practice I almost always start a new client on the sequential pipeline. Not because it's the most capable, but because it's the easiest to validate end to end and the easiest to defend. You can prove it works, stage by stage, before you trust it with anything. Then, as the team's confidence grows and the limits show up, you layer in orchestration where you need parallelism and judgment, and reach for collaborative review on the handful of decisions that genuinely can't ride on a single model.
The mistake is starting with the fanciest architecture because it's exciting. The right move is starting with the one you can stand behind, and earning your way up to the rest.