M1-Parallel: Optimizing Multi-Agent Systems

• M1-Parallel is a framework that concurrently launches multiple LLM-based agent teams using diverse high-level plans to optimize multi-step reasoning.
• It implements an asynchronous event-driven communication model to reduce latency and handle varying execution times across complex tasks.
• The framework supports both early-stop and aggregation modes, balancing speed and reliability in applications like GAIA-level problem solving.

Searching arXiv for the specified paper and closely related context. M1-Parallel, short for “Magentic-One Parallel,” is a framework for optimizing sequential multi-step reasoning tasks in LLM-based multi-agent systems by running multiple multi-agent teams concurrently on distinct plans and then selecting or combining their outputs (Zhang et al., 11 Jul 2025). It is designed for settings in which complex tasks require repeated cycles of plan, act, observe, and reflect, and in which alternative valid solution paths differ substantially in step count, tool-use pattern, latency, and failure mode. The framework uses an event-driven communication model with asynchronous messaging to exploit this plan diversity either for lower end-to-end latency through early termination or for higher task completion rates through aggregation (Zhang et al., 11 Jul 2025).

1. Concept and problem formulation

M1-Parallel addresses a latency bottleneck in sequential multi-step reasoning. In the underlying task setting, complex problems such as GAIA level-3 queries require 10–20 steps of “plan → act → observe → reflect,” with each step involving one or more LLM calls plus tool invocation and network delays (Zhang et al., 11 Jul 2025). Because each step depends on the previous one, total user-perceived time grows linearly with the number of steps. The reported GAIA example includes tasks that took 13 minutes and still failed (Zhang et al., 11 Jul 2025).

The framework is motivated by the observation that real-world problems often admit multiple distinct, correct solution paths. These alternative plans can differ widely in the number of steps and in the tools they invoke, which induces substantial latency variation even when several plans are correct (Zhang et al., 11 Jul 2025). M1-Parallel therefore replaces a single sequential multi-agent execution with concurrent execution of multiple teams, each initialized with a different high-level plan. This permits two operating modes. In “early-stop,” all remaining teams are terminated once any team succeeds. In “aggregation,” the system waits for $k$ successful teams and then combines their answers (Zhang et al., 11 Jul 2025).

This design targets a specific systems-level inefficiency rather than proposing a new single-agent reasoning mechanism. A plausible implication is that the main optimization target is the variance of plan execution trajectories, especially the long tail of slow or failing runs, rather than only the average per-step cost.

2. System architecture

M1-Parallel is implemented as a wrapper around a standard Magentic-One multi-agent team (Zhang et al., 11 Jul 2025). Its top-level control element is a Central Manager, also described as an “Orchestrator-of-Orchestrators,” which performs four functions: it generates $n$ distinct plans via a Plan Generator LLM; launches $n$ independent Magentic-One teams; receives asynchronous messages from each team about step progress, success or failure, logs, and costs; and applies either early-stop or aggregation logic to select the final answer (Zhang et al., 11 Jul 2025).

Each launched team contains one Orchestrator together with the specialized agents WebSurfer, FileSurfer, Coder, and ComputerTerminal (Zhang et al., 11 Jul 2025). The teams are independent after launch. This matters because the framework does not require fine-grained synchronization across teams during execution; instead, communication is event-driven and asynchronous.

At the team level, specialized agents communicate back to their local Orchestrator via message queues. When a team finishes, either by success or by irrecoverable failure, it emits a terminal event $(s_i, a_i, l_i, c_i)$, where $s_i\in\{0,1\}$, $a_i$ is the answer if $s_i=1$, $l_i$ is the textual log of all reasoning steps, and $c_i$ is the cumulative cost so far (Zhang et al., 11 Jul 2025). The Central Manager listens for these events in parallel, with no blocking on other teams.

The architectural emphasis on asynchronous terminal events makes M1-Parallel lightweight in the sense stated by the source: it is a drop-in orchestration layer around an LLM-based multi-agent system such as Magentic-One rather than a replacement for the internal agent stack (Zhang et al., 11 Jul 2025). This suggests that its applicability depends primarily on whether the underlying system can externalize plans, maintain per-team logs, and expose completion or failure events.

3. Execution model and algorithm

The framework is defined by an explicit algorithmic interface. Its inputs are a user query $q$, the number of teams $n$0, an aggregation threshold $n$1 with $n$2 for early-stop, a plan generator $n$3, and an aggregator $n$4. Its outputs are the final answer $n$5, latency $n$6, and cost $n$7 (Zhang et al., 11 Jul 2025).

The execution proceeds in three stages. First, the system performs plan generation by invoking $n$8 repeatedly for $n$9, using either high-temperature LLM sampling or a “diverse” prompt, producing a plan set $n$0 (Zhang et al., 11 Jul 2025). Second, for each $n$1, it spawns a team $n$2 in parallel, runs Magentic-One with plan $n$3 and query $n$4, and emits $n$5 on completion or failure (Zhang et al., 11 Jul 2025). Third, it enters an event loop that waits until $n$6 is no longer true, where $n$7 is the set of successful completions. Successful events append $n$8 to $n$9. Failed events may trigger optional failure recovery through re-plan and retry by recording $(s_i, a_i, l_i, c_i)$0, generating $(s_i, a_i, l_i, c_i)$1, and relaunching $(s_i, a_i, l_i, c_i)$2 with the new plan (Zhang et al., 11 Jul 2025).

The final latency is defined as

$(s_i, a_i, l_i, c_i)$3

where $(s_i, a_i, l_i, c_i)$4 is the completion time of the $(s_i, a_i, l_i, c_i)$5-th successful team relative to the start time (Zhang et al., 11 Jul 2025). The total cost is the cumulative cost incurred by all teams up to that stopping time,

$(s_i, a_i, l_i, c_i)$6

The final answer is

$(s_i, a_i, l_i, c_i)$7

where the aggregator consumes the successful answers and their logs (Zhang et al., 11 Jul 2025).

The paper defines speedup as

$(s_i, a_i, l_i, c_i)$8

where $(s_i, a_i, l_i, c_i)$9 is Magentic-One’s latency and $s_i\in\{0,1\}$0 (Zhang et al., 11 Jul 2025). For early-stop, $s_i\in\{0,1\}$1, so $s_i\in\{0,1\}$2, $s_i\in\{0,1\}$3, and $s_i\in\{0,1\}$4 (Zhang et al., 11 Jul 2025). For aggregation, $s_i\in\{0,1\}$5, and latency and cost are accumulated analogously (Zhang et al., 11 Jul 2025).

A central feature of this algorithm is that it treats parallel runs as alternative executions of the same query rather than as decomposition into jointly coordinated subtasks. That distinction separates M1-Parallel from many multi-agent coordination schemes whose principal complexity lies in inter-agent collaboration within a single plan.

4. Plan diversity, early stopping, and aggregation

The framework evaluates two plan-generation modes. The first is repeated sampling, in which $s_i\in\{0,1\}$6 is invoked $s_i\in\{0,1\}$7 times with high temperature. The second is “diverse” prompting, in which for plan $s_i\in\{0,1\}$8 the prompt is augmented with “Make this plan different from $s_i\in\{0,1\}$9” (Zhang et al., 11 Jul 2025). The empirical finding is that repeated sampling sufficed. Figure 1 in the source shows that “Repeated” slightly outperforms “Diverse” in latency, cost, and success rate (Zhang et al., 11 Jul 2025). The paper’s hypothesis is that forcing diversity often introduces unnecessary, suboptimal steps (Zhang et al., 11 Jul 2025).

The decision between early termination and aggregation is the principal operating trade-off.

Mode	Mechanism	Reported use case
Early-stop	Set $a_i$0 and choose the fastest successful result	Latency-critical settings
Aggregation	Wait for $a_i$1 successful teams and combine answers	High-reliability settings

Early-stop is recommended for latency-critical settings such as real-time agents, where the goal is to choose the fastest result with minimal accuracy hit (Zhang et al., 11 Jul 2025). Aggregation is recommended for high-reliability settings such as medical QA, where one sets $a_i$2 and accepts extra latency and cost for higher completion (Zhang et al., 11 Jul 2025).

The paper also compares aggregation strategies. It evaluates majority voting, an LLM-based aggregator that prompts logs and answers into GPT-4o, and an oracle “best-of-k” upper bound (Zhang et al., 11 Jul 2025). The reported result is that the LLM-based aggregator outperforms majority voting but remains substantially below the oracle best-of-k bound (Zhang et al., 11 Jul 2025). This suggests that answer combination is a nontrivial inference problem and that much of the residual headroom lies in better aggregation rather than only in generating more candidate runs.

5. Empirical evaluation

The experimental evaluation uses the GAIA validation set, with level 1 containing 53 tasks, level 2 containing 86 tasks, and level 3 containing 26 tasks (Zhang et al., 11 Jul 2025). The reported metrics are wall-clock latency from submission to final answer, accuracy or completion measured as the number of tasks solved correctly, and monetary cost defined as $a_i$32.5/1\text{M} + \text{LLM output} \times $a_i$4 (Zhang et al., 11 Jul 2025).

With three teams and early-stop, M1-Parallel yields 1.6×–1.8× speedup at all levels while preserving accuracy (Zhang et al., 11 Jul 2025). Cost rises by only approximately 1.7×–1.8× rather than 3× because of early termination (Zhang et al., 11 Jul 2025). With three teams and aggregation using $a_i$5 and an LLM-based aggregator, solved tasks increase by +3 at level 1, +5 at level 2, and +1 at level 3, with latency approximately baseline × 1.2–1.5 (Zhang et al., 11 Jul 2025).

Increasing the number of teams to five raises early-stop speedup to 1.8×–2.2×, though the paper describes the gains over three teams as marginal (Zhang et al., 11 Jul 2025). With five teams and aggregation, completion improves further, including +7 tasks at level 2 (Zhang et al., 11 Jul 2025). The reported rule of thumb is that 3–5 teams provide the majority of the speedup benefit, with diminishing returns beyond 5 teams (Zhang et al., 11 Jul 2025).

Several ablations characterize why the system works. Figure 2 shows that early-stop reduces latency for both solved and failed tasks, eliminating long-tail failures (Zhang et al., 11 Jul 2025). Figure 3 and Table 1 show a large spread in team latencies per task; the first team averages about 125 s at level 1, whereas the third averages about 301 s (Zhang et al., 11 Jul 2025). This variance is structurally important: without it, parallel plan execution would have little opportunity to reduce latency.

The paper also reports results with local models. Qwen3-32B is used for teams and or the aggregator (Zhang et al., 11 Jul 2025). Early-stop still yields up to 2.2× speedup, described as an ideal parallelized estimate (Zhang et al., 11 Jul 2025). Using GPT-4o as the aggregator recovers most accuracy gains, whereas a local-only aggregator suffers from verbose traces (Zhang et al., 11 Jul 2025).

6. Operational considerations and research directions

M1-Parallel is presented as an orchestration strategy with concrete deployment implications. Its event-driven, asynchronous messaging ensures no blocking across teams (Zhang et al., 11 Jul 2025). The aggregator model can differ from the team model, enabling deployments that use smaller models for teams and a larger LLM for final merging (Zhang et al., 11 Jul 2025). This decoupling is operationally significant because it separates search over plans from adjudication across outputs.

The number of teams is constrained by hardware and serving topology. The source notes that local GPUs may serialize requests, whereas full concurrency is possible on multi-GPU or cloud systems (Zhang et al., 11 Jul 2025). Consequently, the benefits of M1-Parallel depend not only on reasoning diversity but also on whether parallel execution is physically realizable by the serving stack.

The framework also includes an explicit, though optional, failure-recovery pathway through re-plan and retry (Zhang et al., 11 Jul 2025). In the reported discussion, future directions include smarter diversity mechanisms such as plan-graph coverage and latency prediction, adaptive team spawning in which new plans are launched only if earlier ones remain slow, and better failure recovery and plan refinement across teams (Zhang et al., 11 Jul 2025).

A common misconception would be to treat forced plan diversity as inherently beneficial. The reported experiments do not support that claim: repeated sampling outperforms the tested “diverse” prompting strategy in latency, cost, and success rate (Zhang et al., 11 Jul 2025). Another misconception would be to assume that parallelizing $a_i$6 teams implies an $a_i$7 cost increase. Under early termination, the empirical cost increase is substantially smaller than the number of teams because many runs are cut off before completion (Zhang et al., 11 Jul 2025).

In summary, M1-Parallel formalizes parallel plan execution as a systems method for LLM-based multi-agent reasoning. Its central claim is not that parallel agents reason differently at the token level, but that multiple independent teams, launched from distinct high-level plans and coordinated through asynchronous terminal events, can exploit natural plan diversity to improve latency or completion on high-complexity tasks (Zhang et al., 11 Jul 2025).