The only three orchestration patterns that survive contact with production.

This is the default, and it should stay the default until you have a specific reason to leave it. One agent, one context window, a scoped set of tools it calls in a loop. No handoffs, no shared state between agents, because there's only one agent. Most support workflows, most internal copilots, and most document-processing tasks fit here without strain.

The failure mode people worry about, "the agent gets confused with too many tools," is usually a tool design problem, not an orchestration problem. Twelve well-scoped, well-named tools with typed inputs beat four agents each holding three tools and passing messages between them. You avoid an entire class of bugs, message-passing bugs, state-sync bugs, ordering bugs, by staying in one loop.

We reach for a second agent only when one of three things is true: the subtask needs a materially different context (a long document the main loop shouldn't carry around), the subtask needs a different model for cost or capability reasons, or the subtask needs an isolated failure boundary so a crash there can't take down the main loop. Absent one of those three, stay single-agent. Read more on when to size the stack up in our take on agents vs agentic AI.

This pattern earns its complexity when the job decomposes cleanly into independent subtasks. An orchestrator agent (often just deterministic code, not even a model call) breaks the job into N well-defined pieces, dispatches each to a worker agent or worker process, and reassembles the results. Research fan-out, bulk document extraction, and parallel API enrichment are the classic fits.

The rule that keeps this pattern from collapsing: workers must not need to talk to each other, and they must not share mutable state. Each worker gets its own input, does its own job, returns its own output. The orchestrator merges. The moment a worker needs to know what another worker is doing, you've actually built pattern three and should redesign it as one.

The checklist we run before shipping an orchestrator-worker system:

1. Every subtask can be fully specified before dispatch. No worker needs to ask the orchestrator a follow-up question mid-run.
2. Workers are idempotent. Re-running a worker on the same input produces the same output, so retries are safe.
3. The orchestrator has a timeout and a partial-completion path. If 8 of 10 workers finish, you ship a reduced result rather than hanging.
4. Cost per worker is capped, and the sum is capped, before the job starts, not measured after the invoice arrives.
5. Failures are logged per worker, not just at the orchestrator level, so you can tell which subtask type is actually failing.

This is the pattern for workflows where judgment changes hands, not just data. One agent (or a human) does intake and triage, decides the case needs a specialist, and hands it off with full context. A second agent (or human) picks it up, does the specialized work, and either resolves it or hands it further. The key property: only one party owns the case at a time. There is no moment where two agents are both allowed to act on the same object.

This is the pattern behind our escalation designs, and we've written the full playbook on the triggers that should force a handoff in when to hand an agent back to a human. The same logic applies agent-to-agent as it does agent-to-human: define reversibility, blast radius, and confidence thresholds up front, and make the handoff payload explicit rather than implied.

• Explicit ownership transfer. A status field or queue entry that says who owns the case right now. No implicit "both agents are working on it."
• Full context in the payload. The receiving agent gets the conversation history, the decisions already made, and the reason for the handoff, not just the raw ticket.
• A supervisor that can reclaim. If the receiving agent stalls or times out, a supervisor process reclaims the case rather than leaving it orphaned.

The popular take this year is that autonomous multi-agent swarms are the natural end state, that as models get better, coordination overhead disappears and you can throw a dozen loosely-specified agents at a problem and let them figure it out. Several frameworks are built entirely around this premise, with dynamic agent spawning and free-form message passing between peers.

It's incomplete because it treats coordination failure as a model-capability problem, and it isn't. It's a systems problem. Even a perfect model can't avoid a race condition when two agents both read a stale value and both write, or resolve a deadlock when two agents are each waiting on the other's output. Better models make individual agents smarter; they do not remove the need for explicit ownership of shared state. We've watched teams upgrade the underlying model and still hit the exact same production incident, because the bug was in the coordination graph, not the reasoning.

The honest version of the 2026 story is narrower: swarms work well for a specific shape of problem, independent parallel search over a large space with no shared state, like scanning thousands of documents for a pattern. They work badly for the shape most B2B workflows actually have, which is a small number of steps over shared, mutable business state where order and ownership matter. Pick the pattern for your problem's shape, not for the shape of the demo you saw.

Run this decision sequence before writing any orchestration code:

1. Can one agent with a good tool set do the whole job? If yes, stop here. This resolves the large majority of internal requests we get.
2. Does the job decompose into fully independent subtasks? If yes, orchestrator-worker. If the subtasks need to negotiate with each other, this is a red flag, not a feature request.
3. Does ownership of the case need to change hands based on judgment? If yes, supervised handoff, with an explicit ownership field and a reclaim path.
4. Does none of the above fit? Before building something custom, revisit whether the task is actually agentic at all, or whether a deterministic pipeline with one LLM call inside it would do the job with far less surface area to secure and monitor.

This sequencing matters because every pattern beyond single-agent adds a coordination surface, and coordination surfaces are where incidents happen at 2am, not where they happen in a demo at 2pm. If you want a second opinion on which pattern fits your actual workflow, that diagnostic is exactly what we run in the $1,000 AI Audit, before any code gets written.

Teams pick orchestration patterns based on how elegant the architecture looks in a design doc. The variable that actually matters in production is failure isolation: when one part breaks, how much of the system keeps working, and how fast can you tell which part broke?

Single-agent systems have trivial failure isolation because there's only one thing to isolate; when it fails, everything stops, and you have one log to read. Orchestrator-worker systems isolate failure per worker, which is why the partial-completion path in the checklist above matters so much; a single stuck worker should never take down the whole batch. Supervised handoff isolates failure per case, which is why explicit ownership and a reclaim path are non-negotiable; an orphaned case with no owner is a silent failure that nobody notices until a customer complains.

Whichever pattern you choose, instrument it so a failure in one part is visible without reading every log in the system. That's the difference between a five-minute incident and a five-hour one. Our agent observability field notes cover the trace format we use to make that distinction easy to see at 2am.

If your current architecture diagram has more than three agent types on it, or has agents that both read and write the same object, that's worth a second look before you scale traffic into it. Most of the multi-agent incidents we get called in to fix trace back to a coordination decision made in week one, when the demo mattered more than the failure graph.

The fix is rarely "add more agents to handle the edge cases." It's almost always "collapse back to the simplest pattern that does the job, then add complexity only where the failure graph forces it." If you're evaluating whether your current agent architecture will hold under real production load, our orchestration guide walks through the tradeoffs in more depth, and our MCP server development work is often the piece that makes single-agent viable for longer than teams expect.