The multi-agent story has been told relentlessly since 2024. Two years on, the market has had enough time to separate genuine deployments from demoware. Worth a fresh look at where the technology actually works in production.

Three patterns are quietly succeeding.

The first is research-and-summarise pipelines. An orchestrator agent breaks a research question into sub-tasks, dispatches each to a specialist agent (web search, document retrieval, structured data lookup), and recomposes the results. This pattern works because the failure modes are obvious — incomplete information, contradictory sources, hallucinated citations — and there’s a human in the loop reviewing the output. The orchestration adds genuine speed without creating new categories of risk.

The second is internal-tools automation. Customer service workflows where one agent triages, another retrieves account context, and a third drafts responses for human approval. The supervisor pattern keeps the latency tolerable and the audit trail clean. Done well, this delivers measurable productivity gains. Done badly, it adds latency and confusion without much benefit.

The third is data engineering pipelines where agents handle schema mapping, transformation logic generation, and quality validation. This is the most narrowly scoped of the three and the most reliable. The work is structured enough that agent outputs can be validated programmatically, and the cost of failure is bounded.

Where it falls over

Open-ended autonomous agent systems — the “set a goal, walk away” pattern — still don’t work for anything consequential. The accumulating-error problem hasn’t been solved. Long agent chains amplify small mistakes into large ones, and the more interesting the task, the more degrees of freedom there are for things to go subtly wrong.

The vendors who claimed in 2024 that this would be solved within 18 months were wrong, and the people who pushed back are now mostly vindicated. The interesting research is happening, but production deployments of fully autonomous multi-agent systems remain rare and high-risk.

The other failure pattern is over-orchestrated systems that should have been single agents. A surprising number of “multi-agent” deployments would work better as a single agent with good tool calling. The architecture is more complex than the problem requires, debugging is harder, and the latency overhead is real.

What teams shipping this are actually doing

The teams that have multi-agent systems in production share a few habits.

They keep agent counts low. Two to four agents in a workflow is typical. Anything more usually fails at integration testing.

They specify clear handoff conditions. Every agent has a defined output schema and the orchestrator validates it before passing forward. When validation fails, the system has a recovery path that doesn’t involve another LLM call.

They invest heavily in observability. Tracing, logging and replay tooling for multi-agent systems is substantially more complicated than for single-agent systems, and the teams that didn’t build this early are debugging blind.

They have human checkpoints at consequential decisions. The agents handle the assembly work; humans approve anything that ships externally or affects production data.

The market dynamics

Vendor positioning has matured. The frameworks that were aggressively marketing autonomous multi-agent capabilities in 2024 have mostly walked back to “supervised agent workflows” as the primary use case. That’s an honest pivot to where the actual demand is.

Pricing has settled. Token costs for multi-agent workflows are real but predictable; teams can model unit economics with reasonable accuracy. The early-2025 fears that runaway agent loops would create open-ended cost exposure have been managed by sensible orchestration design and rate limits.

The interesting question for the back half of 2026 is whether we see genuine breakthroughs in long-horizon reasoning that change the autonomy story, or whether the field continues to mature within the supervised orchestration pattern. I’d bet on the latter, but I’d also bet there’s a real shift in the next 24 months. The current architecture is too constrained to be the final answer.

What I’d tell a team starting now

Build a single-agent prototype first. If you genuinely need orchestration, the limitations of the single-agent version will become obvious. If they don’t, you don’t need multi-agent. Most teams that build multi-agent first end up with systems that are harder to debug, more expensive to run, and not measurably better at the task.

When you do go multi-agent, treat it as a software architecture problem first and an AI problem second. The hard parts are the boring parts: schemas, error handling, observability, recovery. Those are the same skills that make any distributed system work, and the AI angle doesn’t change them.