Review date: 2026-07-25 Review author: Zhongzhu Zhou Paper reviewed: When Do Multi-Agent Systems Help? An Information Bottleneck Perspective Paper authors: Wendi Yu, Lianhao Zhou, Xiangjue Dong, Sai Sudarshan Barath, Declan Staunton, Byung-Jun Yoon, Xiaoning Qian, James Caverlee, Shuiwang Ji (Texas A&M University; Brookhaven National Laboratory) arXiv: 2607.16133 Status: Preprint, submitted 17 July 2026
Short Answer
If you’ve ever wired up a multi-agent LLM pipeline and watched it underperform a single well-prompted agent, this paper explains exactly why, with a formal mechanism rather than a shrug. The authors’ core observation is deceptively simple: a single-agent system (SAS) keeps one growing shared context across the whole task, while a multi-agent system (MAS) splits the task across isolated workers that only talk to each other through short “relay” messages. They first prove that if those relay messages could carry unlimited information, a MAS could always simulate a SAS exactly — so any real advantage or disadvantage of MAS must come from the fact that relays are bandwidth-limited and therefore lossy. They then model each relay as an information bottleneck: it should throw away context that is irrelevant to the downstream worker’s task while keeping everything relevant. This yields a clean decomposition of “MAS gain” into two competing terms — the benefit of removing noisy upstream context, and the cost of losing information the next worker actually needed — with the balance point controlled by an effective parameter β that increases with the downstream model’s capability. Across 18 controlled experiments spanning five agentic benchmarks (ALFWorld, WebShop, WorkBench, WideSearch, TravelPlanner) and three model scales (Qwen2.5-7B, GPT-4o-mini, Qwen3.5-27B), the predicted pattern holds up: MAS reliably wins when the task’s relays can be short and still sufficient (context reduction dominates), and MAS gains shrink or even flip negative as either the task demands richer cross-step context or the base model becomes strong enough to exploit that context itself. This turns “should I use multi-agent or single-agent for this task?” from a matter of taste into a question you can reason about structurally, before you’ve spent a single API dollar on an ablation.
Key Takeaways
- The paper’s headline theoretical result, Proposition 3.1, shows that under unbounded relay bandwidth, a MAS can always exactly reproduce any SAS’s output — meaning the entire empirical debate about “does splitting into multiple agents help” is really a debate about bounded-bandwidth relay compression, not about decomposition itself.
- Theorem 4.1 decomposes local “MAS gain” at any single relay interface into two competing, named quantities: upstream context reduction (a benefit) and relay information loss weighted by capability (a cost) — MAS wins locally exactly when .
- The capability-dependent is the paper’s most practically useful idea: stronger downstream models are hurt more by relay compression (because they could have used the full context productively) and helped less by noise removal (because they’re already good at ignoring irrelevant context), so the same MAS design that helps a 7B model can actively hurt a 27B model on the same task.
- A carefully designed three-way controlled comparison (SAS vs. SAS-contextflow vs. MAS) isolates why MAS helps: SAS-contextflow uses the identical planner-induced sub-task decomposition as MAS but keeps one shared context, so any residual gap between SAS-contextflow and MAS is attributable purely to relay-induced context isolation, not to task decomposition.
- The empirical results split cleanly along the paper’s own predicted relay-complexity axis : benchmarks with compact sufficient relays (ALFWorld, WideSearch, TravelPlanner-CS, all ) show MAS beating SAS-contextflow consistently across all three models, while benchmarks needing detailed cross-step evidence (WorkBench, ) show MAS losing to SAS-contextflow at every model scale.
- A causal ablation (Table 4 of the paper) directly manipulates relay sufficiency by deliberately deleting downstream-needed fields from the relay message (e.g., stripping price and navigation history from a WebShop relay) and shows performance drops monotonically as designed information loss increases — this is the paper’s strongest evidence that is a real causal lever, not just a descriptive post-hoc quantity.
Prerequisites: What You Need to Know First
This paper sits at the intersection of three areas: LLM-based multi-agent systems, information theory (specifically the information bottleneck framework), and empirical agent benchmarking. To follow the derivations without hand-waving, you need five pieces of background, which I build up one at a time below: what an LLM agent’s “context” actually is and how it accumulates, what distinguishes a single-agent from a multi-agent architecture at the level of information flow (not just the number of API calls), what mutual information and conditional mutual information mean and how to read expressions like , what the classical information bottleneck principle is trying to optimize, and what a Markov relation asserts about a system.
What “Context” Means for an LLM Agent
When an LLM is used as an autonomous agent — solving a multi-step task like navigating a simulated household (ALFWorld) or completing a purchase on a mock e-commerce site (WebShop) — it doesn’t see the whole task at once. It operates in a loop: observe the current state of the world in text form, decide on an action, receive a new observation reflecting the consequence of that action, and repeat. The context at any point in time is the accumulated transcript of everything the agent has seen and done so far: prior observations, its own intermediate reasoning (“thoughts”), and the actions it took. This context is what actually gets fed back into the LLM at every step — it is functionally the agent’s entire “memory” of the episode, since the underlying LLM itself has no persistent state between calls. A key practical fact worth internalizing: as an episode gets longer, this context grows, and everything in it competes for the LLM’s limited attention and context window. This is the seed of the entire paper’s argument — a shared, ever-growing context is exactly what a single-agent system relies on, and exactly what a multi-agent system deliberately gives up in exchange for isolation.
Single-Agent vs. Multi-Agent: The Real Structural Difference
The intuitive story about multi-agent systems (MAS) is “specialization” — a planner agent, a coder agent, a critic agent, each good at one thing. But the paper argues the deeper structural difference is about information flow, not division of labor. A single-agent system (SAS) is one agent that carries one shared, monotonically growing context through the entire task: every subtask’s outcome, every intermediate observation, stays visible to every later step. A multi-agent system (MAS), by contrast, assigns different phases of the task to different “workers,” each of which starts with a fresh, isolated context — it only receives its own sub-instruction plus a short relay message summarizing whatever the previous worker decided was worth passing forward. Crucially, this means a MAS worker cannot see the raw history that produced the relay message — only the compressed summary. This is the structural fact the whole paper is built on: MAS isn’t “SAS plus specialization,” it’s “SAS with the shared context replaced by a lossy, bottlenecked communication channel between isolated workers.”
Mutual Information and Conditional Mutual Information
The paper’s formal machinery is built entirely out of mutual information, , which measures (in bits, or nats) how much knowing the value of random variable reduces your uncertainty about random variable . Formally, , where is Shannon entropy (a measure of uncertainty) and is the conditional entropy — the remaining uncertainty about once is known. If and are completely independent, : knowing tells you nothing new about . If is a deterministic function of , : knowing tells you everything about . The paper also uses conditional mutual information, , which measures how much tells you about after already conditioning on (i.e., given) . This is the quantity that appears throughout Section 4: expressions like ask “how much does the relay message tell us about the downstream target , once we already know the downstream sub-instruction ?” — i.e., the additional, non-redundant predictive value of the relay, above and beyond what the sub-instruction itself already implies.
The Information Bottleneck Principle
The information bottleneck (IB) framework, originally due to Tishby, Pereira, and Bialek, formalizes a very general compression problem: given an input and a target variable you care about predicting, find a compressed representation of that keeps as much information about as possible while discarding as much irrelevant information about as possible. This is stated as an optimization problem,
where (how much of survives into ) is being minimized — you want a small, compressed — while (how predictive still is of ) is being maximized, with a Lagrange multiplier controlling the trade-off between the two competing goals. When is small, the objective favors aggressive compression even if it costs some predictive power; when is large, the objective favors preserving predictive information even at the cost of a less-compressed representation. This exact template — minimize how much upstream information survives, while maximizing how much of it is useful for a downstream target — is what the paper transplants directly onto the design of a MAS relay message: the relay plays the role of the compressed representation , the worker’s full context plays the role of the input , and the next worker’s target plays the role of the prediction target.
Markov Relations: What Means
A Markov chain (or Markov relation) asserts that and are conditionally independent given : once you know , learning gives you no additional information about , and vice versa. Formally, . Intuitively, is a “sufficient intermediary” between and — all of the influence has on must flow through . This becomes important in Section 4.1 of the paper, which establishes the Markov relation : the relay is derived from (compressed from) the full context , and cannot contain information about the downstream target that isn’t already present in itself. This is what licenses treating the relay-design problem as a bottleneck problem in the first place — the relay can only ever be as informative as its source, never more.
Notation Reference Table
Because Section 4’s derivations introduce a number of subscripted symbols in quick succession, here is a single table to refer back to while reading the method section below.
| Symbol | Meaning |
|---|---|
| a full task instance | |
| planner-induced sub-instances assigned to workers | |
| the worker-specific target variable for sub-instance | |
| worker ‘s full accumulated context | |
| the relay message worker sends forward, | |
| inter-worker relay bandwidth, | |
| Shannon entropy | |
| mutual information | |
| conditional mutual information | |
| IB trade-off weight, interpreted as downstream model capability | |
| relay information loss at interface (Definition 4.1) | |
| the MAS/SAS local IB objective values | |
| local MAS gain, | |
| estimated relay complexity of a benchmark (minimum sufficient relay description length) |
The Method: Formalizing MAS as Bounded-Bandwidth Relay Compression
Setting Up the Formal Objects
The paper first defines a common abstraction, a basic agent, that both SAS and MAS are built from: an agent is a tuple , where is a “thought” space (intermediate natural-language reasoning), is the context/memory space, and are policies that produce thoughts and actions respectively given the current context, and is an aggregation function that produces the final output from the terminal context. Given a task instance and initial observation , the agent’s context evolves as — at every step, the current thought, action, and resulting observation get appended to the running context, exactly mirroring the “growing transcript” intuition from the prerequisites section above.
A single-agent system (SAS) is simply one basic agent that runs this loop over the whole task, producing one continuous context and a final output .
A multi-agent system (MAS) introduces a planner that first splits the task instance into an ordered sequence of sub-instances , each inducing a worker-specific target variable (the task-relevant thing worker is supposed to figure out or produce). Each worker is a separate basic agent operating only on ; when worker finishes, it produces a relay message — a compressed summary of its own full context — which gets handed to worker . Worker ‘s initial context is then : its own sub-instruction plus whatever the previous worker chose to pass along, but crucially not worker ‘s full context . A system-level aggregator combines all workers’ terminal contexts into the final MAS output.
The single most important structural fact buried in these definitions is this: worker literally cannot see . It only ever sees . Whatever worker forgot to include in the relay message is permanently lost to every downstream worker — there is no way to “go back and check” the original context. This is the concrete mechanical reason a bounded relay can hurt performance, and it’s worth holding onto as intuition for everything that follows.
Step-by-Step: The Infinite-Bandwidth MAS-SAS Equivalence Proof
Before getting to the bottleneck formulation, the paper proves a foundational sanity-check result, Proposition 3.1: as relay bandwidth , for any SAS there exists a MAS that produces exactly the same output. This matters because it establishes that MAS’s structural differences (planning + relay communication) are not inherently limiting — any performance gap must come from the bandwidth constraint, not from having multiple workers per se. The construction, spelled out as a numbered proof in Appendix A.1 of the paper, works as follows. I unpack it as an explicit algorithm:
Algorithm 1: Constructing a MAS that simulates a given SAS exactly (unbounded relay bandwidth)
- Input: A SAS with context trajectory and final output , and an arbitrary time partition .
- Planner assignment: Set (the whole task) and for every (all later sub-instances are empty — this construction doesn’t actually decompose the task at all, it just re-labels time intervals as “workers”).
- Policy reuse: Give every worker the same thought and action policies as the original SAS. Worker is responsible for reproducing exactly the SAS’s own updates from time to .
- Identity relay: Set the aggregator to be the identity map, so the relay handed forward is the worker’s entire terminal context: (no compression at all).
- Bandwidth check: Because the SAS context has finite entropy at every step (an assumption), each relay also has finite entropy. So for any , every relay satisfies — the construction becomes feasible in the limit .
- Inductive equivalence: By induction on : worker 1 starts from the same initial state as the SAS () and, using identical policies and the identical task kernels, reproduces the SAS’s trajectory exactly up to , so . For the inductive step, worker receives the full relay (by the inductive hypothesis) and its initial context becomes information-equivalent to the SAS’s context at that point in time, so it, too, reproduces the SAS exactly up to .
- Conclusion: Taking gives , so the MAS’s final aggregated output equals exactly.
The takeaway from this construction is almost anticlimactic by design: if you’re allowed to pass the entire upstream context forward as the “relay message,” a MAS is just a SAS wearing a disguise. Nothing interesting happens — no gain, no loss — until you’re forced to actually compress down to something smaller than . That’s exactly the regime real deployed systems operate in, since LLM context windows and communication budgets are always finite in practice, and it’s exactly the regime the rest of the paper studies.
Formalizing Relay Design as an Information Bottleneck
Given that bounded relay bandwidth is where all the interesting behavior lives, Section 4 sets up the relay-design problem explicitly as an IB objective. First, the Markov relation from the prerequisites section is established formally (proved in Appendix A.2 by noting that the relay ‘s randomness, if any, is independent of given and ):
This licenses writing the relay-design objective in the standard IB form:
where the first term measures how much of the upstream context “survives” into the relay (to be minimized — a good relay should be short and free of irrelevant detail), and the second term measures how much downstream-relevant information about the relay preserves given the next sub-instruction (to be maximized — a good relay should still let the next worker do its job). is, as before, the trade-off weight, but the paper gives it a very concrete practical interpretation here: represents the downstream LLM’s capability. A weaker model is more easily confused by noisy, irrelevant leftover context, so it implicitly “prefers” a small (favoring aggressive compression); a stronger model can productively use rich context and therefore implicitly “prefers” a large (favoring information preservation over compression). This single design choice — reframing an abstract Lagrange multiplier as “how good is the model reading this relay” — is what turns an information-theoretic curiosity into a testable, falsifiable empirical prediction, which is exactly what the experiments in the paper go on to test.
Deriving the SAS-as-No-Compression Special Case
An elegant consistency check the paper performs: what happens if you plug the uncompressed relay, , into the IB objective? Substituting into Eq. (2):
Here I(M_i; m_i) collapses to (mutual information between something and an identical copy of itself equals its own entropy), and the second term becomes the maximum possible predictive information the context could ever provide about , since nothing has been thrown away. This shows algebraically what was intuitively obvious from Proposition 3.1: SAS is the no-compression point in the space of possible relay designs. MAS, by construction, always corresponds to some compressed point in that same space. This reframing is what lets the paper make an apples-to-apples comparison between SAS and MAS purely as different points along one shared axis — the amount of relay compression — rather than as two unrelated architectures.
Deriving the MAS Gain Decomposition (Theorem 4.1)
This is the paper’s central theoretical contribution, and it’s worth deriving in full rather than just quoting. First, define the relay information loss:
Definition 4.1 (Relay Information Loss). The information loss induced by relay is
This is simply “how much downstream-relevant information about was available in the full context , minus how much of that information actually survived into the compressed relay .” By the Markov relation in Eq. (1), a compressed can never carry more target-relevant information than the source it was compressed from, so always. When , the relay is called sufficient — it lost nothing the next worker needed. When , it’s insufficient, and larger values mean more severe, more damaging compression.
Substituting Definition 4.1 back into the general IB objective (Eq. 2), after rearranging the terms (I is expanding and distributing the ):
The last term doesn’t depend on the relay design at all — it’s a fixed property of the task and decomposition — so it drops out of any comparison between two different relay choices for the same worker interface.
Now define the MAS gain relative to the SAS (no-compression) baseline: (gain is defined as reduction in the loss objective — remember the IB objective is something we want small, so a smaller than is a genuine improvement). Subtracting Eq. (5) from Eq. (3) and simplifying (the shared term cancels exactly, and while by definition of conditional entropy) gives the paper’s headline result:
Theorem 4.1 (MAS Gain Decomposition).
Every symbol here has a concrete, checkable meaning. is the residual uncertainty about the full context once you only know the compressed relay — intuitively, “how much noisy, irrelevant clutter did the relay successfully strip away?” This is the benefit term, and it’s always non-negative (you can’t lose entropy you didn’t have). is the capability-weighted cost of whatever downstream-relevant signal got thrown away along with the noise. MAS is locally beneficial at this interface exactly when
This single inequality is the entire empirical claim of the paper, compressed into one line: context reduction has to outpace capability-weighted information loss. Because increases with downstream model capability, the same relay design and the same task can sit on either side of this inequality depending purely on which model is reading the relay — which is exactly the “MAS helps weak models, hurts strong models” pattern the experiments go on to confirm.
Why “Design Choice X” Was Made This Way — Discussion
Why frame as capability rather than estimate it directly? The obvious alternative would be to try to estimate empirically for a given model (e.g., by fitting it to observed performance data), turning the framework into a predictive, quantitative tool rather than a qualitative, explanatory one. The paper explicitly declines to do this and instead treats as a monotonically-increasing-with-capability qualitative parameter. This is a real limitation the paper itself flags (see Limitations below): it means Theorem 4.1 explains why a pattern should hold and predicts its direction, but cannot tell you in advance, for a brand-new task and model pair, exactly where the crossover point is. The upside of the qualitative choice is generality — you don’t need a costly calibration procedure per model/task pair to get directional predictions — but the cost is that the framework is explanatory rather than a deployable a-priori sizing tool.
Why use relay information loss rather than simply relay length (number of tokens) as the design lever? A shorter relay isn’t necessarily a worse one, and a longer relay isn’t necessarily a better one — what matters is whether the specific bits that got kept are the ones the downstream worker needs. The paper’s Table 4 ablation makes this distinction concrete and causal: they construct “insufficient” relay variants that are not shorter in some crude sense but are specifically stripped of fields known to be downstream-relevant (e.g., dropping object location from an ALFWorld relay, or dropping price/attributes/navigation history from a WebShop relay), and show performance drops as a direct consequence — establishing that it’s the content, not the length, that drives the trade-off. The obvious alternative (using token count as a cheap proxy for relay quality) would have been much easier to measure automatically, but the paper correctly identifies that token count and information sufficiency are only loosely correlated, and a length-based metric would have missed exactly the causal mechanism they wanted to isolate.
Why decompose the task the same way for SAS-contextflow and MAS, rather than compare MAS against an ordinary, non-decomposed SAS directly? This is arguably the paper’s most important experimental-design choice, and it’s worth pausing on why a naive MAS-vs-SAS comparison would have been scientifically weaker. If you only compare MAS against plain SAS, any observed gain is confounded: it could come from the task decomposition itself (breaking a hard problem into easier sub-problems, independent of any context isolation) or from the relay-based context isolation the paper’s theory is actually about. By introducing SAS-contextflow — a single agent that follows the identical planner-induced sub-task sequence as MAS but keeps one shared, uncompressed context throughout — the paper creates a controlled condition that differs from MAS in exactly one variable: whether the shared context is replaced by lossy relays. Any residual gap between SAS-contextflow and MAS is now cleanly attributable to relay compression, not decomposition. This is the paper’s version of a proper ablation, and Section 6’s separate “Does Planning Structure Alone Explain MAS Gains?” experiment (Table 3 of the paper, using a related SAS-Plan variant) directly confirms that decomposition alone, without context isolation, does not reproduce MAS’s gains — SAS-Plan actually performs consistently worse than plain SAS on ALFWorld across all three models, underscoring that the isolation mechanism, not the sub-task structure, is doing the real work.
Where does this design choice fail? The controlled three-prototype comparison (SAS / SAS-contextflow / MAS) is clean for isolating relay compression as a mechanism, but it necessarily fixes the planner’s decomposition strategy across both SAS-contextflow and MAS. If a different decomposition (different subtask boundaries, different assignment of responsibilities to workers) would have produced a more relay-friendly structure — for instance, redesigning WorkBench’s decomposition so that cross-domain evidence-gathering and write-actions are handled by the same worker rather than split across a relay boundary — the paper’s framework doesn’t tell us how to find that better decomposition; it only diagnoses how good or bad a given decomposition’s relays are. The paper acknowledges a version of this limitation implicitly in its “Implications” discussion, which frames “jointly optimizing the relay encoder with the downstream task” as future work, rather than a solved problem.
A Practical Algorithm: Deciding Whether to Use MAS or SAS for a New Task
While the paper itself doesn’t present this as a numbered algorithm, Theorem 4.1 and the five-benchmark taxonomy together imply a concrete, actionable decision procedure that a practitioner could follow before committing engineering effort to a multi-agent architecture. I make this explicit as pseudocode, since clause-15-style unpacking of “how would I actually use this” is exactly the kind of design-level detail the paper’s theory section leaves implicit.
Algorithm 2: Structural triage for MAS vs. SAS on a new task
- Input: A candidate task, a planner-induced sub-task decomposition , and a candidate downstream model with informally known capability tier (weak / medium / strong).
- Estimate relay complexity for each worker interface by asking: does the next worker’s target require exact, hard-to-summarize evidence from the upstream worker (object IDs, timestamps, running totals, global constraints) or can it be satisfied by a compact, natural-language summary? If the former, assign ; if the latter, ; intermediate cases (partial evidence needed, e.g. product attributes but not full navigation history) get .
- If at every interface: favor MAS. Context isolation will strip irrelevant upstream clutter with low risk of losing anything the next worker needs, so dominates for essentially any .
- If at any interface and the downstream model is strong: favor SAS (or SAS-contextflow if you still want the sub-task structure for other reasons, e.g. tool-use scoping). A strong model’s large effective means even a small gets amplified into a large cost term, and a strong model is precisely the one best equipped to productively use the full shared context anyway.
- If (intermediate) and the downstream model is weak-to-medium: MAS is likely still net-positive, since is small enough that even nontrivial information loss doesn’t outweigh the context-reduction benefit — but treat this as the regime most likely to flip as you upgrade the base model, and re-run the triage after any model swap.
- In all cases, prefer designing relays that are content-selective rather than merely short: per the Table 4 causal ablation, deliberately dropping specific downstream-required fields (not just truncating length) is what drives the measured performance cost, so relay design effort is best spent on “what specific facts does the next worker need” rather than “how can I compress this transcript.”
- Output: a structural recommendation (MAS / SAS / SAS-contextflow) per interface, to be validated empirically before committing to production, since the triage above is directional guidance derived from a qualitative framework, not a guaranteed prediction (see Limitations).
This triage procedure is, in effect, a compressed operational summary of everything Theorem 4.1 says formally — and making it explicit this way also exposes exactly where the theory’s qualitative nature (step 2’s informal assignment, and the “weak/medium/strong” capability tiering rather than a measured ) leaves a practitioner needing to fall back on judgment calls rather than a computed threshold.
Figures
Figure 1 (paper Fig.1): The paper’s own conceptual summary of its central prediction — MAS gain as a function of relay regime and model capability. Green regions indicate where context-reduction benefit dominates (MAS helps); red/negative regions indicate where relay information loss dominates (MAS hurts), with stronger models shifting the balance toward the loss side.

Figure 2 (paper Fig.2): The three controlled prototypes side by side — SAS (single shared context), SAS-contextflow (same planner-induced decomposition, still one shared context), and MAS (same decomposition, but isolated worker contexts connected only by compressed relays ). This is the experimental design that isolates relay compression as the causal mechanism, described in the design-choice discussion above.

Figure 3: A self-drawn diagram of the information flow inside a single MAS relay interface, matching Eqs. (1)-(7): worker ‘s full context is compressed by into relay , which alone (not ) is visible to worker , whose performance on target depends on how much of survived compression.
flowchart LR
subgraph WorkerI["Worker i"]
Mi["Full context M_i<br/>(all thoughts, actions, observations)"]
Aggi["Aggregator Agg_i<br/>(compression / summarization)"]
Mi --> Aggi
end
Aggi --> mi["Relay message m_i<br/>(bounded bandwidth B_sys)"]
subgraph WorkerI1["Worker i+1"]
Xi1["Sub-instruction X_(i+1)"]
M0["Initial context M_0^(i+1) = (X_(i+1), o_0) ⊕ m_i"]
Yi1["Downstream target Y_(i+1)"]
Xi1 --> M0
mi --> M0
M0 -.affects.-> Yi1
end
Mi -. "cannot be seen by Worker i+1<br/>(only m_i is visible)" .-> WorkerI1
Figure 4 (paper Fig.3): Main empirical results across all five benchmarks and three model scales (Qwen2.5-7B, GPT-4o-mini, Qwen3.5-27B), with green/red shading showing where MAS outperforms or underperforms SAS-contextflow. This is the primary evidence for the paper’s central claim, discussed benchmark-by-benchmark in the Experiments section below.

Figure 5 (paper Table 3, rendered as a figure): The SAS-Plan ablation, isolating whether planning structure alone (without context isolation) can explain MAS’s gains. SAS-Plan uses the same decomposed sub-instructions as MAS but keeps a single shared context, and it consistently underperforms plain SAS — direct evidence that decomposition alone is not the mechanism.

Figure 6 (paper Table 4, rendered as a figure): The causal relay-sufficiency ablation on ALFWorld and WebShop, comparing a normal (“sufficient”) relay against a deliberately information-stripped (“insufficient”) relay at matched decomposition — the paper’s strongest causal evidence that operates as a genuine performance cost.

Experiments: Testing the Theory Against Five Benchmarks
Experimental Setup
The paper evaluates three controlled prototypes — SAS, SAS-contextflow, MAS — across three model scales spanning a real capability range: Qwen2.5-7B-Instruct (served locally via vLLM in bfloat16), GPT-4o-mini (via the OpenAI API), and Qwen3.5-27B using an AWQ 4-bit quantized checkpoint (also served locally via vLLM). All prototypes use greedy decoding (temperature 0.0) and are matched on total step budget per benchmark, so that MAS’s decomposition into multiple workers doesn’t get an unfair “more total compute” advantage over SAS.
Five benchmarks are chosen specifically to span a range of what the paper calls relay complexity, — informally, the minimum description length of a relay message that would be sufficient (i.e., ) for the downstream worker. ALFWorld (household navigation and manipulation tasks) and WideSearch (structured, mostly-independent information retrieval subqueries) are assigned : their natural task structure means a short relay (e.g., “the object is on the shelf”) really can carry everything the next worker needs. WorkBench (multi-domain office-software tasks requiring exact prior read results like object IDs and timestamps before executing write actions) is assigned : a bounded relay essentially cannot preserve everything a downstream write action needs. WebShop (search-then-purchase e-commerce) and TravelPlanner’s hard-constraint checks (global itinerary consistency, e.g., total budget across all days) sit in between, at . TravelPlanner is treated specially as a mixed-regime benchmark: its commonsense checks (local feasibility of a single day’s plan) are , while its hard constraints (global budget, cross-day consistency) are — reported as separate CS-macro and HC-macro metrics.
Main Results: The Predicted Split Holds
Table 2 of the paper (not reproduced in full here, but summarized) groups all benchmarks by their assigned regime and reports MAS’s gain over SAS-contextflow at each of the three model scales. The pattern is remarkably clean:
For the low-complexity-relay benchmarks (): ALFWorld shows MAS beating SAS-contextflow by +0.194, +0.157, and +0.023 (Qwen2.5-7B, GPT-4o-mini, Qwen3.5-27B respectively) — consistently positive, but shrinking as capability increases, exactly as Eq. (7) predicts (the same benefit gets increasingly outweighed by a growing , even when itself stays small). WideSearch shows the same qualitative pattern: +0.079, +0.063, +0.028 on Item F1. TravelPlanner-CS: +0.011, +0.183, +0.028.
For the high-complexity-relay benchmarks ( or ): WorkBench shows MAS losing to SAS-contextflow at every single model scale (-0.005, -0.086, -0.014) — the relay simply cannot preserve the exact object IDs, timestamps, and prior read results that downstream write actions require, so dominates regardless of model capability. WebShop and TravelPlanner-HC show the paper’s sharpest and most interesting pattern: a capability-dependent sign flip. WebShop goes from +0.080 and +0.086 (weak and medium models, where MAS still helps) to -0.003 on Qwen3.5-27B (where MAS starts to hurt). TravelPlanner-HC shows an even more dramatic flip: +0.017 and +0.161 for the two weaker models, collapsing to -0.233 for Qwen3.5-27B. This is precisely the qualitative signature Eq. (7) predicts: as grows with capability, the crossover point where can be crossed entirely, flipping the sign of the gain.
A Concrete Case Study: Watching the Sign Flip Happen
The paper includes a worked example (TravelPlanner task tp_1: a 3-day Oakland-to-Tucson itinerary under a hard \beta\beta1,400 cap throughout its long shared context and stays within budget, while MAS’s compressed relays lose the explicit budget figure by the final day and produce a \beta$ across the crossover point in Eq. (7).
Ablation Studies: Isolating the Causal Mechanisms
Two further ablations sharpen the causal story. First, the planning-structure ablation (SAS-Plan, discussed above) shows decomposition alone, without context isolation, doesn’t explain MAS’s gains — SAS-Plan underperforms plain SAS on ALFWorld across all three models (-0.068, -0.059, -0.194), ruling out “breaking the problem into easier pieces” as the operative mechanism. Second, the relay-sufficiency ablation (Table 4) constructs “insufficient” relay variants by deliberately deleting downstream-required fields — object location and state for ALFWorld, price/attributes/navigation for WebShop — while holding the MAS decomposition otherwise fixed, and shows performance drops consistently across all model scales (e.g., ALFWorld SR drops by 0.015, 0.015, and 0.052 for the three models as relay sufficiency is degraded). This is the paper’s best direct evidence that isn’t just a mathematically convenient quantity that happens to correlate with performance — deliberately manipulating it causes the predicted performance change.
A Worked Numerical Sanity Check on the Gain Decomposition
It helps to plug in toy numbers to make Theorem 4.1 feel concrete rather than purely symbolic. Suppose, for a single relay interface, the full upstream context has entropy bits, and a candidate relay retains only bits of that (so bits in the best case, i.e., the relay is a deterministic function of , which is the typical case for a compressed summary). Then the upstream context reduction term is bits: seven bits’ worth of upstream clutter has been successfully stripped away. Now suppose the maximum possible downstream-relevant information available in is bits, and the compressed relay manages to preserve bits of that — so by Definition 4.1, bits of downstream-relevant information were lost. Plugging into Eq. (7): MAS is beneficial at this interface exactly when , i.e., when . If the downstream model is weak enough that its effective sits well below 14 (it can’t exploit rich context anyway, so it doesn’t miss the lost 0.5 bits much), MAS wins comfortably. If the downstream model is capable enough that its effective climbs above 14 (it could have used that missing 0.5 bits productively), the same relay design flips to a net loss — this is the exact mechanism behind the WebShop and TravelPlanner-HC sign flips reported in the experiments, just with illustrative rather than measured numbers, since (as discussed in Limitations below) the paper does not actually estimate these bit quantities empirically.
Putting the Experimental Numbers in Perspective
It’s worth explicitly contrasting the magnitude of the gains and losses reported across regimes, since the raw numbers alone can undersell how sharp the qualitative pattern is. In the regime, MAS’s advantage over SAS-contextflow is positive in all 9 reported cells (3 benchmarks × 3 models: ALFWorld, WideSearch, TravelPlanner-CS), with a mean gain across those cells of roughly +0.096 — a meaningful, double-digit-percentage-point improvement in several cases (e.g., +0.194 on ALFWorld with the weakest model). In the / regime, the picture inverts: WorkBench is negative in all 3 cells, and WebShop/TravelPlanner-HC together contribute 4 positive and 2 negative cells, with the 2 negative cells both occurring at the strongest model (Qwen3.5-27B) — exactly the models×benchmarks combination the theory says should be most exposed to relay information loss. This asymmetry (uniformly positive in the sufficient-relay regime, systematically flipping negative precisely at high capability in the insufficient-relay regime) is the paper’s strongest single piece of quantitative evidence, and it is considerably more convincing than looking at any individual benchmark’s numbers in isolation.
Reading the Case Study’s Table Carefully: What Actually Changed Between the Two Models
It is worth re-reading the TravelPlanner tp_1 case study (summarized above) once more, slowly, because it is easy to skim past exactly what changed between the GPT-4o-mini run and the Qwen3.5-27B run. The sub-task specifications handed to every worker (transport, accommodation, dining, attraction) are held fixed across both model runs — identical code-defined sub-specs, identical decomposition, identical relay boundaries. The only two things that differ are (a) which base model is doing the reasoning inside each worker, and (b) whether that specific model’s SAS-contextflow run happens to notice and retain the plan-level global budget figure of 1,400 figure survives clearly in the long shared SAS-contextflow context (a stronger model is simply better at retaining and using a single salient number across a long context), while MAS’s relay-based workers lose track of the exact number by the final day and overshoot to \beta$ isn’t some mysterious latent trait — it cashes out concretely as “how good is this specific model at holding onto and using one important number across a long shared transcript,” a very down-to-earth capability that varies predictably with model scale and post-training quality.
Limitations
The authors are candid about several boundaries of their own framework, and it’s worth reading these carefully rather than skimming past them. First, is treated qualitatively, not quantitatively estimated — the paper never actually measures a numeric for any of the three models; it only asserts (and empirically confirms) that increases monotonically with capability. This means Theorem 4.1 gives you the direction of an effect but not a way to compute, in advance, exactly where the crossover point sits for a new task/model pair you haven’t yet tested. Second, relay complexity is assigned by qualitative task-structure analysis, not measured: the paper’s own five-benchmark taxonomy (, , ) is derived from the authors’ domain reasoning about what information each task’s downstream steps require, not from an automated or principled quantitative estimator. Third, the theory as stated is fundamentally a local, single-relay-interface result (Theorem 4.1 concerns one interface between worker and worker ); the paper’s own Section 4.2 “Local-to-Downstream Sufficiency” discussion shows that local sufficiency for the immediate next target does not automatically imply sufficiency for later downstream targets unless additional structural conditions (mediated dependence, non-interference) hold — meaning long chains of workers could have hidden long-range dependency failures the local theorem cannot catch by itself. Fourth, the model roster is limited to three specific checkpoints (Qwen2.5-7B, GPT-4o-mini, Qwen3.5-27B-AWQ-4bit) at a single point on each model’s release timeline — it’s an open question whether the capability- relationship generalizes smoothly across model families and post-training regimes, or whether some models could show non-monotonic behavior. Fifth, all relays and decompositions in the experiments are produced by fixed, hand-designed prompts (Appendix D), not learned or optimized relay encoders — the paper explicitly frames “jointly optimizing the relay with the downstream task” as future work rather than something it has already validated.
Critical Analysis
Weaknesses and flaws specific to this paper. The most significant technical gap is that the entire empirical validation rests on a qualitative proxy for the paper’s central quantitative claim. Theorem 4.1’s inequality, , is a precise, checkable statement about specific information-theoretic quantities — but the paper never actually estimates , , or numerically for any real experiment. Instead, the empirical validation substitutes a rough five-level -regime taxonomy (assigned by the authors’ own judgment about task structure) and an implicit, unmeasured assumption that “capability” and "" move together. This is a real risk: the theory could be perfectly correct while the empirical support for it is closer to “a plausible qualitative story that fits the observed pattern” than to “a quantitatively validated causal model.” A more rigorous version of this paper would attempt to estimate mutual information terms directly — even crude estimators (e.g., using a smaller proxy model to compute conditional entropy over context/relay pairs, or using variational mutual information estimators like MINE or CLUB) would let the authors check whether the magnitudes of and actually track the observed performance gaps quantitatively, not just directionally.
Limitations the authors understate or omit. The paper’s discussion of -regime assignment reads as more principled than it actually is upon close inspection — for instance, TravelPlanner is explicitly split into a “CS” () and “HC” () component, but this binary split is itself a judgment call about what counts as “local” versus “global” information, and a different, equally reasonable decomposition of the same task could plausibly be assigned differently. More importantly, the paper doesn’t seriously grapple with the possibility that its own controlled prototypes (SAS, SAS-contextflow, MAS) are not the only three interesting points in the design space — real production multi-agent systems often use hybrid designs (e.g., MAS workers that can request additional context on demand, or hierarchical designs where some workers share context and others don’t), and the paper’s clean three-way taxonomy doesn’t obviously extend to characterize these intermediate designs, even though they are arguably more representative of how MAS is actually deployed in practice. The paper’s Section 7 “Implications” gestures at “adaptive relays” as future work but doesn’t discuss what specific mechanism (learned compression? retrieval-augmented relays? on-demand context requests?) would actually move a design from one side of the crossover inequality to the other in a controllable way.
Concrete, specific improvement suggestions. (1) Add a direct, even approximate, estimation of the mutual-information quantities in Theorem 4.1 for at least one benchmark/model pair — for example, using a masked-language-model-based conditional entropy estimator over the actual context/relay text pairs collected during the WorkBench experiments, to check whether the sign and rough magnitude of actually track the observed MAS-vs-SAS-contextflow performance gap, rather than relying solely on the qualitative -regime taxonomy. (2) Extend the three-prototype comparison with at least one adaptive/hybrid relay design — e.g., a MAS variant where a worker can issue a follow-up query back to the previous worker if it detects that its relay was insufficient — to test whether the framework’s predictions extend cleanly to designs beyond the fixed, one-shot relay setting studied here. (3) Report an explicit estimate of relay message length (in tokens) alongside the -regime taxonomy for every benchmark, so readers can distinguish cases where MAS gains are being driven by genuine content-selection quality (the paper’s central claim) from cases where they might be confounded by simply “MAS relays happen to be shorter and thus less distracting,” which is a related but conceptually distinct effect the paper’s own Table 4 ablation gestures at but doesn’t fully disentangle from length effects. (4) Test at least one additional “in-between” capability point (e.g., a model between GPT-4o-mini and Qwen3.5-27B in raw capability) to check whether the crossover in WebShop and TravelPlanner-HC happens gradually (as Eq. 7’s smooth -dependence would predict) or more abruptly, which would materially affect how practitioners should reason about “is my model strong enough that MAS will start hurting me on this task.”
Connecting This to Prior MAS-vs-SAS Debates
The paper explicitly positions itself against a growing body of empirical work reporting that MAS gains “diminish as base model capability improves” (citing, among others, prior findings on multi-hop reasoning where a single strong agent matched or beat a multi-agent pipeline under equal thinking-token budgets). What this paper adds beyond that prior empirical literature is a mechanistic account of why that diminishing-returns pattern should occur, rather than just observing it. The key distinguishing move is decomposing the single empirical quantity “MAS gain” into two separately named, oppositely-signed components (upstream context reduction and capability-weighted relay loss), so that a diminishing MAS gain isn’t just an unexplained trend line but a predictable consequence of growing while and stay comparatively fixed properties of the task’s relay design. This reframing also explains a detail prior empirical work left unresolved: why the diminishing-returns pattern isn’t universal — on the low-complexity-relay benchmarks (ALFWorld, WideSearch, TravelPlanner-CS) the paper’s own results show MAS gains shrinking with capability but never actually crossing zero within the tested range, while on the higher-complexity benchmarks the same shrinking trend does cross zero. Under the paper’s framework this is exactly what you’d expect: the crossover point in Eq. (7) depends on both and , and only when is large enough to begin with does a realistic amount of capability growth actually push past .
Conclusion
This paper answers a question that has been debated mostly with anecdote and vibes — “does splitting an LLM task across multiple agents actually help?” — with a genuinely mechanistic, checkable answer: it depends on whether your relay messages compress away noise faster than they discard signal, and that balance point shifts as your base model gets stronger. The theoretical core (Proposition 3.1’s equivalence result and Theorem 4.1’s gain decomposition) is elegant and, more importantly, directly falsifiable — the paper puts it through 18 controlled experiments and the predicted pattern holds up cleanly across benchmarks and model scales, including the striking capability-dependent sign flips on WebShop and TravelPlanner-HC. The most immediately useful practical upshot for anyone building agentic systems today: before reaching for a multi-agent architecture, ask whether the task’s natural decomposition would allow short, local, still-sufficient relay messages between workers — if downstream steps genuinely need detailed upstream evidence that’s expensive to summarize (like WorkBench’s exact object IDs and timestamps), a single agent with full shared context, especially if it’s already a strong model, may well outperform a fleet of specialized ones. The framework’s remaining gaps — no quantitative estimation of the theory’s own key terms, and no exploration of adaptive or hybrid relay designs — are exactly the directions that would turn this from a compelling explanatory lens into a practical, a-priori design tool.
A Note on Terminology: “Gain” vs. “Advantage” vs. “Improvement”
One small but genuinely useful clarification for readers coming from the broader multi-agent literature: the paper’s technical term “MAS gain” () is a local, IB-objective-space quantity defined precisely by Eq. (6) — it is not the same thing as “the empirical performance improvement of MAS over SAS on benchmark X,” even though the two are closely related and the paper’s experiments treat the empirical success-rate delta as an observable proxy for the theoretical gain. This distinction matters because the theoretical is defined per-interface (i.e., local to one relay boundary between two specific consecutive workers), while the reported benchmark numbers (Table 2, Figure 3) are end-to-end task success rates that aggregate the effects of potentially several relay interfaces chained together (e.g., TravelPlanner’s five-phase decomposition in Table 5 has four relay interfaces in sequence). The paper’s Section 4.2 “Local-to-Downstream Sufficiency” discussion is precisely about this gap: a relay that is locally sufficient for the immediate next worker’s target is not automatically sufficient for a later worker’s target further down the chain, unless the specific mediated-dependence and non-interference conditions given in Appendix A.3 hold. Readers who want to map the paper’s clean theoretical story onto a real multi-hop MAS pipeline with more than two workers should keep this local-vs-global distinction in mind rather than assuming the single-interface theorem directly explains end-to-end multi-worker outcomes without further argument.
Reproducibility Notes
The paper reports a public GitHub repository (https://github.com/divelab/MAS-SAS) containing the experimental code. Model access requires either local vLLM deployment (for Qwen2.5-7B-Instruct and the Qwen3.5-27B-AWQ-4bit checkpoint, each runnable on a single NVIDIA RTX A6000 GPU per the paper’s Appendix B.2) or an OpenAI API key (for GPT-4o-mini). All five benchmarks used (ALFWorld, WebShop, WorkBench, WideSearch, TravelPlanner) are themselves public, previously released benchmarks with existing open-source harnesses, which should make re-running the core comparisons (with the paper’s own prompts, reproduced in Appendix D) feasible without needing to re-implement any bespoke evaluation infrastructure. One practical note for anyone attempting to reproduce results exactly: greedy decoding (temperature 0.0) is used throughout, which reduces run-to-run variance, but WideSearch specifically depends on a live DuckDuckGo web-search backend rather than an offline environment, meaning results on that specific benchmark may drift over time as underlying web content changes, unlike the other four benchmarks’ offline simulators/sandboxes.