The Gartner 1,445% number: a surge in multi-agent inquiries, not adoption

“Every team is building their first multi-agent system. We are about to generate a massive dataset of production failures.”

TL;DR

Gartner’s 1,445% growth in multi-agent inquiries signals interest, not adoption or success. The real data: hub-and-spoke is the default architecture, failures cluster at handoffs, and cost explosions hit when orchestrators retry without limits. Deer-Flow (about 37K stars) and gstack (over 20K in its first week), both as of March 2026, show what abstractions practitioners want. For the technical foundations of multi-agent coordination, see multi-agent architectures.

What does the 1,445% number actually mean?

Gartner tracks client inquiry volume: how often its clients ask its analysts about a technology category. Gartner reported a 1,445% surge in multiagent system inquiries from Q1 2024 to Q2 2025 (Gartner). That puts inquiry volume at about 15.5 times its starting level. It counts questions, not companies, and certainly not deployments.

This is a demand signal. It measures curiosity and exploration, not deployment. The distinction matters because the gap between “exploring multi-agent” and “running multi-agent in production” is enormous. Most teams that explore will build a prototype, hit unexpected failure modes, and either simplify back to single-agent or invest months in production hardening.

The GitHub data tells a parallel story. ByteDance’s Deer-Flow (a SuperAgent harness for research, coding, and task execution) had passed 37,000 stars by late March 2026. It provides sandboxes, memory, tools, skills, subagents, and message gateways in a structured framework. YC president and CEO Garry Tan’s gstack, a set of Claude Code skills released in March 2026, passed 20,000 stars within about a week, offering an opinionated configuration-over-code approach with bundled skills for planning, review, shipping, and QA.

Both gained traction because they reduce the distance from “I want multi-agent” to “I have a working multi-agent system.” The demand is real. The engineering cost of going from demo to production is what the Gartner number does not capture.

What do early production deployments look like?

Three patterns come up repeatedly in public write-ups from teams that have moved past prototyping.

Hub-and-spoke is the default. One orchestrator agent receives all requests, decides which specialist agents to invoke, collects their outputs, and synthesizes a response. This is the multi-agent equivalent of a monolithic API gateway: all traffic flows through one point. Teams choose it because it is the easiest to debug, monitor, and explain. When something fails, you check the orchestrator’s logs and trace which sub-agent caused the problem.

The limitation is predictable: the orchestrator becomes a throughput bottleneck and a single point of failure. But for teams processing hundreds of requests per day (not thousands), this constraint does not bind. Many early adopters are in that range.

Heterogeneous model selection is common. A common pattern is to use expensive frontier models for complex reasoning tasks and cheaper models for high-frequency execution tasks (formatting, validation, classification). This is a natural optimization: route each sub-task to the cheapest model that handles it reliably. How much it saves depends on how much traffic stays on the frontier model. With illustrative prices of $15 per million tokens for the frontier model on 30% of tokens and $0.15 per million for a small model on the other 70%, the blended price is about $4.61 per million, roughly 3.3 times cheaper than sending everything to the frontier model. A 10x saving needs the frontier share down to about 9%.

Use cases cluster in two domains. Customer service (routing, knowledge retrieval, response generation as separate agents) and document processing (extraction, validation, classification, summarization as a pipeline). These are the use cases where the multi-agent decomposition maps naturally to the task structure. More ambitious applications (multi-agent research, autonomous software engineering, creative collaboration) exist in prototypes but rarely in production.

graph TD
    A[User Request] --> B[Orchestrator Agent<br/>Frontier model, reasoning]
    B --> C[Classifier Agent<br/>Small model, fast]
    B --> D[Retrieval Agent<br/>Medium model, RAG]
    B --> E[Response Agent<br/>Frontier model, generation]
    C --> B
    D --> B
    E --> B
    B --> F[Response to User]

    G[Illustrative cost breakdown:<br/>Orchestrator: 20% of calls, 60% of cost<br/>Specialist: 80% of calls, 40% of cost]

Where do the failures cluster?

Three failure modes appear consistently in production multi-agent systems. All are engineering problems, not research problems.

Handoff failures. When one agent passes work to another, context is lost or corrupted. The first agent’s long output gets cut or summarized to fit the second agent’s input budget, and the second agent proceeds with partial information. The result looks correct at a glance (the second agent generates confident output) but misses details from the truncation. These failures are silent and discovered only when a human reviews the output or a downstream system rejects it.

Context bleed. In systems where agents share memory or message buses, information from one task leaks into another agent’s context. A customer service agent processing User A’s complaint picks up context from User B’s conversation because both used the same retrieval agent and the retrieval results were not properly scoped. Context bleed is the multi-agent equivalent of a race condition: it appears intermittently and is hard to reproduce.

Cost explosions. An orchestrator sends a task to a specialist agent. The specialist fails. The orchestrator retries. The specialist fails again. Without a retry budget, the orchestrator retries indefinitely. Each retry costs API tokens. A single stuck task can generate hundreds of dollars in inference costs before anyone notices. The fix is simple (circuit breakers and retry budgets) but teams often discover the need through a surprisingly large cloud bill.

The MAST taxonomy (Cemri et al., arXiv 2503.13657) identified 14 failure modes in three categories: system design issues (5 modes), inter-agent misalignment (6) and task verification (3). In its annotated traces, system design issues account for the largest share of failures (about 44% when you sum the per-mode rates), with inter-agent misalignment, the category closest to handoff failures, at about 32%.

When should you use multi-agent versus single-agent?

The decision tree is simpler than most framework documentation suggests.

Use a single agent when:

• One system prompt covers the full task
• Tool calls are sequential, not parallel
• The task fits in one model’s context window
• Debugging transparency matters more than modularity

Add agents when you have a concrete reason:

• Different sub-tasks require fundamentally different system prompts (a coding agent and a review agent need different instructions, temperature, and tools)
• Independent sub-tasks can run in parallel (searching three databases simultaneously)
• Different tasks need different model sizes (frontier for reasoning, small for formatting)
• The task structure is genuinely a pipeline where each stage transforms the output

The anti-pattern: splitting a task into agents because it looks clean on an architecture diagram, not because it solves a real problem. Every agent boundary is a potential handoff failure, a serialization/deserialization step, and a cost multiplication. Add them when the benefit outweighs these costs.

If you do add agents, the multi-agent SDK wars compares what each vendor’s SDK commits you to, and the multi-agent tax shows single agents holding their own when thinking budgets are equal.

Key takeaways

• 1,445% measures curiosity, not success. Gartner tracks inquiries. Production deployments are a fraction of the interest.
• Hub-and-spoke is the default architecture. Easiest to debug. Orchestrator bottleneck matters only at scale most teams have not reached.
• Failures cluster at handoffs. Context loss, context bleed, and cost explosions. All engineering problems with known solutions.
• Heterogeneous model routing cuts cost, by an amount set by the mix. With 30% of tokens on a frontier model, expect about 3x; 10x needs the frontier share under about 10%. Route by task complexity.
• Start single-agent. Add agents only for concrete reasons: parallel execution, different system prompts, different model sizes. Multi-agent for its own sake is complexity without benefit.
• Deer-Flow and gstack show what practitioners want. Structured frameworks that reduce the distance from prototype to production. Configuration over code.

Further reading

• Multi-agent architectures: technical patterns for multi-agent coordination
• Scaling multi-agent systems: what changes when you go from demo to production scale
• Agent orchestration: orchestration patterns for multi-agent systems
• Cost management for agents: FinOps for preventing cost explosions