Full flow of a multi-agent request

From request to response

Between the moment you send your request and the moment the response appears, far more happens than with a standard LLM call. Following this path step by step will help you when you need to interpret unusual latency, an overly general response, or a surprising token bill.

Step 1: receiving and analyzing the request

When your request reaches the grok-4.20-multi-agent-0309 model, the lead agent starts by analyzing it. It determines the nature of the task—factual research, comparative analysis, synthesis—assesses how many facets to explore, identifies the tools it may need, and settles on its strategy for delegating to sub-agents.

You don’t see this initial analysis: it’s part of the lead agent’s billed reasoning and never appears in the response. It’s also the point where ambiguous wording does the most damage, because everything that follows builds on that first reading.

Step 2: launching the sub-agents

The lead agent then delegates the subtasks. Each sub-agent receives a specific directive and gets to work in parallel with the others. For the request about European cloud strategies mentioned earlier, the split would look like this: one agent researches recent provider announcements, a second analyzes regulatory aspects (GDPR, AI Act), a third compares pricing tiers, and a fourth examines technical documentation.

With 16 agents, the breakdown gets finer and covers more angles: each provider can get its own researcher, and regulatory aspects can split across several jurisdictions.

Step 3: research and discussion

Sub-agents don’t work in isolation. They use the built-in tools—web_search, x_search, code_execution, and others—exchange information with each other to avoid duplicates and refine their leads, and flag unexpected findings to the lead agent that deserve further exploration. This internal conversation is what sets multi-agent apart from a simple parallel call: an agent that finds information contradicting a colleague’s can redirect the research.

It’s also the longest phase and by far the most expensive, because each agent generates its own input, output, and reasoning tokens. When a request runs for a minute with no text appearing, this is where that time goes.

Step 4: synthesis by the lead agent

Once the sub-agents finish, or the reasoning budget is reached, the lead agent takes over and always runs the same sequence. It first collects all the results, then removes duplicates—for the cloud request, three agents will probably have surfaced the same regional availability announcement, and it should appear only once. It then structures the information in the format you requested, cites sources where relevant, and finally produces the final response.

This is where the perceived quality of the result is decided: with the same research, you’ll get either a catch-all paragraph or a readable comparison table, depending on how precisely you described the deliverable you expected.

What you receive

The response contains the text written by the lead agent—its synthesis—the tool calls made by all the agents, including the lead agent, and, if you enabled use_encrypted_content=True, an encrypted content block. These tool calls are your only window into the work actually done behind the scenes.

The rest never reaches you: not the sub-agents’ internal reasoning in plain text, not the exchanges they had with each other, not the details of the delegation strategy the lead agent chose. So there’s no point building a monitoring tool around these elements—they never leave the model.

Streaming

In streaming mode, you see the lead agent’s response build up progressively. The verbose_streaming parameter goes further and also sends you tool calls as they happen, which gives you a direct view of agent activity.

The benefit is real on long requests: you can watch web searches fire one after another while the agents work, and show your user something other than a static loading spinner.

Latency implications

Multi-agent is inherently slower than a standard call, for three cumulative reasons: the sub-agents do work in parallel, but coordination has a cost, the lead agent must wait for all the results before synthesizing, and latency grows with the number of agents involved.

That gives you a simple design rule. For interactive use—a chatbot, a search bar—stay at 4 agents. Reserve the 16 agents for asynchronous tasks: a report generated in the background, an overnight monitoring job, an analysis whose result the user will review later.

Key takeaways

• The flow follows 4 steps: analysis → delegation → research → synthesis
• Sub-agents work in parallel and exchange information with each other
• You receive only the lead agent’s response and the tool calls
• Streaming with verbose_streaming lets you follow activity in real time
• Latency is higher than a standard call, especially with 16 agents