ManagerWorker Pipeline
- ManagerWorker is a dual-agent pipeline that pairs a strong text-only manager for reasoning and planning with a weak worker for execution.
- It efficiently separates analysis, exploration, and implementation phases, achieving a 62% success rate on complex software tasks.
- The design emphasizes deliberate capability asymmetry and phase-bound iteration to reduce expensive strong-model token usage.
ManagerWorker is a two-agent pipeline for software engineering tasks in which an expensive “manager” model operates in text-only mode and a cheap “worker” model has full repository and tool access. The manager analyzes issues, dispatches exploration tasks, synthesizes findings into an implementation plan, and reviews patches, while the worker explores the codebase, carries out code edits, runs commands and tests, and produces patches and natural-language reports. Introduced on 200 instances from SWE-bench Lite, the system was designed around a deliberate capability asymmetry: a strong manager directing a weak worker. In that setting, ManagerWorker reached 124/200 = 62%, while a strong single agent reached 120/200 = 60%, and the strong-manager configuration used approximately one-fifth of the strong-model tokens of the strong single-agent baseline (Liu, 27 Mar 2026).
1. Definition and design rationale
ManagerWorker is a structured manager–worker pipeline for SWE tasks centered on a separation between reasoning and execution (Liu, 27 Mar 2026). The manager is a strong, expensive LLM used in text-only mode with no repository access and no tool execution. The worker is a weak, cheap LLM with full repository and tool access. The design pushes high-leverage reasoning—analysis, planning, and review—to the strong model, and pushes tool-heavy execution—file reading and editing, running commands, and testing—to the cheap model.
The intended capability gap is central rather than incidental. The pipeline is designed to be productive only when there is a genuine capability gap, namely a strong manager directing a weak worker. The reported central question is whether an expensive model can effectively direct a cheap one to solve SWE tasks. The positive result was conditional rather than universal: strong manager plus weak worker was effective, whereas weak manager plus weak worker was not (Liu, 27 Mar 2026).
The architecture is also explicitly motivated by training-distribution considerations. The paper argues that current LLMs are trained as monolithic agents, with entangled reasoning and execution within one session. ManagerWorker therefore keeps each model close to its trained mode: the manager writes structured text, and the worker uses tools within a scoped task. Organizational structure—phase boundaries, round limits, and prompt-strategy switching—is externalized to pipeline code rather than delegated to the models themselves (Liu, 27 Mar 2026).
2. Pipeline structure, phases, and communication protocol
The workflow is phased, iterative, and bounded. Phase 1 is analysis by the manager. It reads the issue and produces 2–3 focused exploration tasks capped at 3, each framed as a precise, atomic instruction. Phases 2–3 are iterative exploration, for up to 3 rounds. Workers execute exploration tasks in parallel on the repository and return natural-language reports rather than raw file dumps. The manager reviews those reports and either proposes 1–3 new exploration tasks or proceeds to write a detailed implementation plan. By the final exploration round, it must produce a plan (Liu, 27 Mar 2026).
That implementation plan includes four required elements: the root cause with evidence, target files and locations, exact changes such as find/replace or patch sketch, and what not to change. Phases 4–5 then handle iterative implementation, again for up to 3 rounds. In round 1, described as guided autonomy, the worker receives the full issue and the manager plan and is told to “use your judgment” on the exact implementation. In round 2 and beyond, if the patch fails or is rejected, the manager writes precise corrective instructions and the worker must “follow these EXACTLY.” After each implementation round, the manager returns either APPROVE or REVISE (Liu, 27 Mar 2026).
The communication protocol is intentionally narrow. Exploration tasks are emitted as lines prefixed with TASK:. Worker outputs are concise natural-language reports summarizing code facts so that they fit the manager’s context window. In implementation, the worker is instructed not to modify tests, to keep changes minimal, and to output a git diff. When the manager issues a REVISE verdict, the pipeline converts that feedback into strict worker instructions automatically (Liu, 27 Mar 2026).
A notable architectural constraint is that the manager must rely on worker reports to “see” code facts. It does not inspect files directly. This is not merely an interface choice. The director-access ablation reported that a manager with repo access regressed (0–1/5), hallucinating that the “fix is already applied,” whereas forcing text-only improved to 2/5, and text-only plus iterative exploration improved to 3/5 on the toy-5 set (Liu, 27 Mar 2026).
3. Empirical performance and cost profile
The evaluation used SWE-bench Lite with 200 instances sampled from approximately 300 GitHub issues across Python repositories including Django, Flask, Matplotlib, Scikit-learn, Sphinx, and Sympy. Each task required a patch that turned FAIL_TO_PASS and PASS_TO_PASS tests green under the project’s Dockerized harness. Success was measured as resolve rate, with additional tracking of empty patch rate and evaluation error rate (Liu, 27 Mar 2026).
| Configuration | Setup | Success rate |
|---|---|---|
| ManagerWorker | full 5-phase pipeline; Claude Sonnet 4.6 → GPT-5-mini | 124/200 = 62% |
| Strong Direct | single strong agent with full agentic access | 120/200 = 60% |
| Simple Loop | review-only loop; Claude Sonnet 4.6 → GPT-5-mini | 106/199 ≈ 53% |
| Weak Direct | single weak agent with full agentic access | 101/200 = 51% |
| Weak→Weak | GPT-5-mini → GPT-5-mini; 50-instance subset | 21/50 = 42% |
These results support two specific claims. First, a strong manager directing a weak worker matched a strong single agent at a fraction of the strong-model token usage. Second, a weak manager directing a weak worker performed worse than the weak agent alone, showing that structure without a genuine capability gap is overhead rather than leverage (Liu, 27 Mar 2026).
The token budget analysis is equally central. ManagerWorker used approximately 6.6K strong-model tokens and 60K weak-model tokens per instance, for a total of approximately 67K. Strong Direct used approximately 30K strong-model tokens. This yielded a strong-model token ratio of approximately , or approximately fewer strong tokens. Strong tokens per success were approximately 10.6K for ManagerWorker versus approximately 50K for Strong Direct, a reduction of approximately in scarce strong tokens, even though ManagerWorker used more total tokens per success (Liu, 27 Mar 2026).
The paper also reported stability and complementarity. The full pipeline remained stable across sample sizes, with 64% at and , and 62% at . On the 50-instance subset, ManagerWorker reached 64%, Strong Direct reached 58%, and the union reached 66%. Four instances were solved only by ManagerWorker, associated with multi-file exploration benefits from structured direction, and one only by Strong Direct, associated with deep iterative debugging favoring autonomous exploration. This suggests complementarity rather than simple dominance (Liu, 27 Mar 2026).
4. Why active direction matters
A central finding is that the manager’s value lies in directing, not merely reviewing. The Simple Loop baseline, characterized as a minimal review-only loop in which the worker executes freely and the manager only reviews, improved by only approximately +2 percentage points over Weak Direct, moving from 51% to 53%. By contrast, the full structured pipeline improved by approximately +11 percentage points, from 51% to 62%. The paper therefore attributes most of the gain to structured exploration, planning, and guided-then-strict implementation rather than to review alone (Liu, 27 Mar 2026).
The communication-strategy ablation sharpens this point. On the 50-instance ablation, strict-only reached 52% and produced many empty patches because the worker could not adapt to the manager’s wrong assumptions. Guided-only reached 54% but allowed the worker to drift beyond scope. Guided-then-strict reached 64%, combining initial adaptation with precise corrections on retries. The reported interpretation is that mode switching is not ancillary; it is one of the mechanism’s critical components (Liu, 27 Mar 2026).
This section of the study also directly counters a common misconception that more centralization automatically helps. Allowing the manager to read the repository did not improve direction; it regressed. Similarly, adding a manager without a capability gap did not improve results; weak→weak reached 42% versus 44% for Weak Direct on the 50-instance subset. The paper’s diagnosis is that current models revert to trained monolithic behavior when given access patterns that blur director and executor roles (Liu, 27 Mar 2026).
The harder-batch analysis reinforces the same interpretation. The Simple Loop degraded markedly on the hardest batch, dropping from 63% on instances 100–150 to 36% on instances 150–200, while the full pipeline remained comparatively stable. This was presented as evidence for a ceiling on “review without direction” (Liu, 27 Mar 2026).
5. Failure modes and the training-limitation diagnosis
The paper identifies several characteristic failure modes. A manager with repo access can revert to trained monolithic behavior, read files directly, form premature conclusions, and under-delegate. A worker can narrate intent instead of executing, over-comply or under-comply depending on prompt strictness, drift when guidance is too loose, or fail silently when guidance is too strict and the manager’s assumptions are wrong. A planning gap also persists: the manager plans from summaries, so unknown unknowns may surface only during implementation. In addition, the system exhibits non-determinism, including small-run variance across identical setups (Liu, 27 Mar 2026).
These behaviors are traced to a single root cause: current models are trained as monolithic agents, and splitting them into director and worker roles fights their training distribution. The pipeline succeeds by designing around that mismatch. The manager remains text-only and writes analyses, plans, and reviews. The worker remains a scoped tool-using executor. Phase transitions, round caps, and prompt-strategy switching are enforced by code rather than by the models (Liu, 27 Mar 2026).
The diagnosis yields three explicit training gaps. The first is delegation: producing actionable, correctly scoped task briefs, specifications, and reviews for others to execute. The second is scoped execution: following instructions, staying within boundaries, and reporting results without editorializing. The third is mode switching: recognizing when to explore autonomously and when to follow precise corrective instructions. The paper recommends training on manager–worker transcripts, code review threads, and technical specifications; on instruction–execution pairs emphasizing scope fidelity and clean reporting; and on curricula for phase-aware behavior and mode switching (Liu, 27 Mar 2026).
A plausible implication is that ManagerWorker is not primarily a proof that general multi-agent decomposition is universally beneficial. Rather, it is a probe into what present-day models are missing. That implication is consistent with the title’s framing of organizational structure as a probe into training limitations (Liu, 27 Mar 2026).
6. Broader manager–worker context and related architectures
ManagerWorker belongs to a wider family of manager–worker systems, but its specific novelty lies in a deliberately asymmetric pairing, a text-only manager, and externalized organizational structure. In high-performance computing, METAQ and mpi_jm realize a Manager–Worker pattern by turning a single large batch allocation into many dynamically scheduled computational tasks, with the manager discovering tasks, tracking allocation state, making resource-fit decisions, and launching or monitoring them (Berkowitz et al., 2017). In distributed optimization, DAP-SGD also adopts a manager–worker system, but its defining move is to off-load the majority of computation tasks from the master to workers and leave the master to conduct simple addition operations (Li et al., 2016).
In recent LLM multi-agent systems, related decompositions appear with different emphases. Workforce decouples strategic planning from specialized execution through a domain-agnostic Planner, a Coordinator, and specialized Workers, and trains only the Planner with Optimized Workforce Learning (Hu et al., 29 May 2025). WorkTeam frames NL2Workflow as a manager–worker paradigm in which a supervisor plans and monitors while an orchestrator and a filler execute focused subtasks using dedicated tools (Liu et al., 28 Mar 2025). The MCP Workflow Engine separates intelligence from execution by having an agent produce a declarative workflow blueprint once and a deterministic engine execute it many times with zero agent involvement at run time (Parmar, 13 Mar 2026).
Compared with those architectures, ManagerWorker is narrower in domain and more diagnostic in purpose. The paper’s own stated novelty, relative to prior multi-agent systems emphasizing role specialization or routing, is threefold: a deliberate capability asymmetry, a text-only manager to prevent reversion to monolithic tool-use behavior, and externalizing organizational structure—phases, loops, and prompt strategies—into code to keep each model near its trained mode (Liu, 27 Mar 2026).
7. Practical deployment and limitations
The paper gives concrete guidance for building ManagerWorker-like systems. The manager should be enforced as text-only and should not be allowed to read files. Exploration tasks should be capped at 3 per round and run in parallel. Worker reports should be concise summaries with exact file and line anchors rather than raw dumps. The manager’s plan should specify root cause, files and locations, exact changes, and what not to touch. The implementation loop should use guided autonomy on the first attempt and strict, manager-authored corrections on retries. Phase changes and iteration limits—up to 3 exploration rounds and up to 3 implementation rounds—should be externalized to code (Liu, 27 Mar 2026).
The paper also recommends maintaining a clear capability gap, pairing a strong manager with a weaker worker, and avoiding weak→weak unless for analysis only. For measurement and budgeting, it recommends tracking resolve rate, empty patch rate, and evaluation error rate, and separately tracking strong tokens and weak tokens. The design goal is to minimize strong-model calls by keeping them short and text-only, while shifting exploration, edits, and testing to the cheap worker (Liu, 27 Mar 2026).
The limitations are equally explicit. Overhead without a capability gap is a real risk, as weak→weak dropped to 42% versus 44% for the weak single-agent baseline. Hard, highly iterative debugging tasks may favor single-agent autonomy. The planning gap remains, because the manager plans from summaries rather than direct inspection. Non-determinism introduces brittleness, and the paper advises multi-run evaluation (Liu, 27 Mar 2026).
Taken together, these findings position ManagerWorker as a specific and empirically grounded manager–worker architecture for software engineering: a strong director can substitute for strong execution, but only when the directing relationship is backed by genuine capability asymmetry, structured exploration, explicit phase control, and a careful effort to keep each model near its trained mode (Liu, 27 Mar 2026).
