Minimal-Toolset Leader-Worker Architecture

• Minimal-Toolset Leader-Worker Architecture is an organizational pattern where a leader handles planning and coordination while workers perform specialized tasks with a limited toolset.
• It reduces per-call token overhead by up to 73% by restricting tool exposure, thereby optimizing execution cost and improving system efficiency.
• The architecture is pivotal in autonomous experimentation, enforcing bounded state management and disciplined control to enhance long-horizon coordination.

Searching arXiv for the cited papers and closely related work to ground the article in current literature. arXiv search query: "Minimal-Toolset Leader-Worker Architecture Deep Researcher Agent (Zhang, 7 Apr 2026)" Minimal-Toolset Leader-Worker Architecture denotes an organizational pattern in which a strategic “leader” retains only the capabilities needed for planning, routing, and state management, while delegating bounded subtasks to specialized “worker” components that each expose only the tools strictly necessary for their role. In the literature, the term is stated most explicitly in Deep Researcher Agent, where it refers to a multi-agent design in which each worker agent is equipped with only 3–5 tools, reducing per-call token overhead by up to 73\% (Zhang, 7 Apr 2026). Across adjacent areas, closely related architectures appear under different names—manager-worker pipelines, hierarchical toolset agentization, holonic control, or partial white-box/black-box optimization—but they share a common systems principle: concentrate high-level control, localize specialized capabilities, and avoid exposing every component to the full global toolset (Liu, 27 Mar 2026).

1. Concept and defining properties

The central idea is not merely multi-agent decomposition, but selective capability exposure. In Deep Researcher Agent, “minimal-toolset” means that each agent is given only the few tools strictly necessary for its function, rather than a large shared toolbox for every agent (Zhang, 7 Apr 2026). The architecture is therefore defined by three coupled properties: role specialization, tool specialization, and bounded interaction. The leader holds the strategic thread of execution, while workers are differentiated by the tasks they perform and by the exact subset of tools they may invoke.

This pattern is clearest in long-running autonomous experimentation. Deep Researcher Agent instantiates a repeated Think $\rightarrow$ Execute $\rightarrow$ Reflect loop, within which a Leader makes strategic decisions, dispatches tasks to specialized workers, and integrates outputs back into compact memory artifacts (Zhang, 7 Apr 2026). The Leader is the central decision-maker, maintains a persistent conversation within each cycle for coherent multi-step reasoning, and resets its conversation between cycles to avoid unbounded context growth. The workers are specialized for literature search and hypothesis formation, experiment implementation and execution, or report generation, and their specialization is reflected directly in tool access.

A closely related but differently framed principle appears in “Can AI Models Direct Each Other? Organizational Structure as a Probe into Training Limitations,” which argues that the most effective split is to keep each model close to its trained mode: the manager is text-only, while the worker holds full repository/tool access (Liu, 27 Mar 2026). This suggests a broader definition of minimality: not simply minimizing the number of tools globally, but minimizing each component’s capability surface relative to its function. The same idea appears again in “HTAA: Enhancing LLM Planning via Hybrid Toolset Agentization & Adaptation,” where a high-level planner acts over a reduced hybrid action space consisting of basic tools and higher-level agent tools, rather than the full flat tool set (Huang et al., 13 Apr 2026).

In this sense, Minimal-Toolset Leader-Worker Architecture is best understood as a constrained control architecture. The leader owns planning, decomposition, state continuity, and final decision authority; workers own localized execution; and the interface between them is intentionally narrow. A plausible implication is that minimality is not an aesthetic preference but a mechanism for reducing coordination burden, token overhead, and behavioral ambiguity.

2. Canonical instantiation in autonomous experimentation

Deep Researcher Agent provides the most explicit and fully specified formulation of the architecture (Zhang, 7 Apr 2026). The system operates over a repeated cycle: $plan_t \leftarrow Think(B, M_{t-1}, d)$ then, unless the decision is to wait,

$result_t \leftarrow Execute(plan_t)$

and after training or monitoring,

$$M_t \leftarrow Reflect(B, M_{t-1}, result_t, logs_t).$$

Within this loop, the Leader is deliberately constrained to three tools: log_memory, write_file, and read_file (Zhang, 7 Apr 2026). It does not directly search papers, execute code, or browse repository structure. Instead, it dispatches tasks to three specialized workers. The Idea Agent, for literature search and hypothesis formation, has four tools: search_papers, get_paper, write_file, and read_file. The Code Agent, for implementation and execution, has five tools: run_shell, launch_experiment, write_file, read_file, and list_files. The Writing Agent, for report and analysis generation, has three tools: write_file, read_file, and list_files.

The paper is explicit that different worker types have different tool subsets; they are not identical shells with different prompts (Zhang, 7 Apr 2026). Only one worker runs at a time, and the Leader dispatches at most 3 worker tasks per cycle. This produces a bounded, sequential decomposition rather than massively parallel orchestration. The Code Agent prompt further fixes an execution template: understand the Leader’s task, implement code or configuration changes, perform a mandatory dry-run, launch via launch_experiment, and report PID and log file path.

The architecture is tightly integrated with two other mechanisms: Zero-Cost Monitoring and Two-Tier Constant-Size Memory (Zhang, 7 Apr 2026). Monitoring during long training runs uses only process-level checks and log-file reads, with no LLM calls. Memory is bounded by

$$|M_t| \leq |B|_{\max} + |L|_{\max} = 3000 + 2000 = 5000 \text{ chars}, \quad \forall t,$$

so continuity across cycles is preserved through compact artifacts rather than ever-growing chat history. This arrangement reinforces the leader-worker split: the Leader consumes bounded global state, while workers operate on bounded, task-local context.

3. Tool minimization as a systems optimization principle

The strongest explicit quantitative rationale for minimal tool exposure comes from token accounting in Deep Researcher Agent (Zhang, 7 Apr 2026). The paper states that each tool definition adds approximately 200 tokens to every API call because of the tool’s name, description, and parameter schema. A conventional richer-tool framework might expose 15+ tools, creating roughly

$15 \times 200 \approx 3000 \text{ tokens}$

of per-call tool-schema overhead. In the minimal-toolset design, the average is about 4 tools: $4 \times 200 \approx 800 \text{ tokens}.$ The reduction is therefore

$\frac{3000 - 800}{3000} \approx 73\%,$

which matches the paper’s claim of a 73\% reduction in per-call token overhead (Zhang, 7 Apr 2026).

The paper continues that over 100 API calls per day, this saves about 220K tokens: $$100 \times (3000 - 800) = 220{,}000 \text{ tokens}.$$ Minimal tool sets are presented as one of eight first-class efficiency mechanisms, alongside prompt caching, state trimming, constant-size memory, and single-worker execution (Zhang, 7 Apr 2026). The strongest explicit claim is therefore about token overhead and cost efficiency; implications for simpler behavior and reduced unnecessary tool exposure are part of the stated design rationale, though not isolated in a dedicated behavioral ablation.

A related but more structural version of the same principle appears in HTAA (Huang et al., 13 Apr 2026). There, not all tools are abstracted; instead, simple deterministic tools may remain basic, while subsets of frequently co-used or functionally overlapping tools are encapsulated into agent tools. The top-level planner then operates over a reduced hybrid action space

$\rightarrow$0

with worker-like agent tools defined as

$\rightarrow$1

This suggests a second form of minimality: minimize the leader’s action space even if worker internals remain complex.

ManagerWorker offers a third variant of the argument (Liu, 27 Mar 2026). Its strongest design lesson is that the leader should often have fewer tools, not more. The manager is text-only, with no repository access or code execution, while the worker has full repo/tool access. The paper reports that giving the manager repo access made it worse on a 5-instance development set, with a repo-access manager at 0–1/5 compared with 2/5 for a text-only manager and 3/5 for text-only plus iterative exploration (Liu, 27 Mar 2026). The paper interprets this as managers reverting to monolithic-agent habits when given tools. This suggests that minimal tool exposure can serve not only cost reduction but role preservation.

4. Control topology, routing, and information flow

Minimal-Toolset Leader-Worker systems typically use a centralized star topology rather than peer-to-peer negotiation. Deep Researcher Agent uses a strict Leader $\rightarrow$2 Worker $\rightarrow$3 Leader pattern inside each cycle, with single-worker execution and bounded dispatch count (Zhang, 7 Apr 2026). SMART-D, a manager-worker framework for stance detection, uses the same topology: Manager planning, parallel Worker reasoning, then Manager aggregation, with no Worker-to-Worker communication (Sabbaghan et al., 10 Jun 2026). The paper explicitly describes this as: $\rightarrow$4

Routing in these systems is usually prompt-driven or code-driven rather than learned by a dedicated routing model. Deep Researcher Agent does not provide a formal routing algorithm; it states that the Leader makes strategic decisions, dispatches tasks to specialized workers, receives outputs, and continues the cycle (Zhang, 7 Apr 2026). SMART-D adds adaptive worker allocation based on prompted complexity estimation, choosing

$\rightarrow$5

workers depending on whether the input is simple, medium, or complex, with more workers for sarcasm, indirect stance, mixed sentiment, multiple entities, or rhetorical framing (Sabbaghan et al., 10 Jun 2026).

ManagerWorker formalizes the control flow more explicitly as a five-phase pipeline: analysis, exploration loop, planning, implementation loop, and review (Liu, 27 Mar 2026). The manager emits up to 2–3 exploration tasks, workers execute them and return natural-language reports, the manager decides whether to continue exploration or produce a plan, the worker implements, and the manager reviews. The pipeline is externally scaffolded in code, with hard loop caps and role boundaries. The paper emphasizes that “the structure is in the code, not in the models” (Liu, 27 Mar 2026). This is a significant architectural claim: minimal toolsets often coexist with nontrivial orchestration logic.

HTAA generalizes this into a compressed planner/worker interface. The planner selects either a basic tool or an agent tool: $\rightarrow$6 and receives either direct tool output or an aggregated worker response: $\rightarrow$7 This hides internal worker trajectories from the leader and reduces context overhead (Huang et al., 13 Apr 2026). A plausible implication is that minimal top-level toolsets often require richer worker-side summarization to compensate for hidden intermediate state.

5. Memory, monitoring, and state discipline

A distinguishing feature of several minimal-toolset systems is that minimality is applied not only to tools, but to persistent state and online supervision. Deep Researcher Agent’s Two-Tier Constant-Size Memory ensures that the Leader reloads a bounded state each cycle: $\rightarrow$8 with a frozen project brief and a compact rolling log (Zhang, 7 Apr 2026). Conversation persists within a cycle for coherence, but resets between cycles. Workers thus avoid carrying long-run history and operate on delegated, local context.

Zero-Cost Monitoring complements this design. After the Code Agent launches an experiment, the system enters monitoring based only on kill -0 $$PID</code>, <code>nvidia-smi</code>, and log-tail reads; no Leader or worker LLM is active during training (<a href="/papers/2604.05854" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Zhang, 7 Apr 2026</a>). This means long wall-clock phases are deliberately moved outside the <a href="https://www.emergentmind.com/topics/agent-loop" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">agent loop</a>. The architecture therefore alternates between short, information-dense leadership intervals and long, non-agentic execution intervals.</p> <p><a href="https://www.emergentmind.com/topics/collabtoolbuilder" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">CollabToolBuilder</a> shows a parallel pattern in a different domain (<a href="/papers/2512.01434" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Xavier et al., 1 Dec 2025</a>). Its four-agent cycle—Coach, Coder, Critic, Capitalizer—relies on a persistent tool library and <a href="https://www.emergentmind.com/topics/reinforced-dynamic-prompt" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Reinforced Dynamic Prompt</a> rather than unconstrained context accumulation. The prompt structure is updated iteratively as</p> <p>$$\rightarrow$9</p> <p>This suggests a general principle: minimal-toolset architectures often compensate for bounded tool access by strengthening state discipline and reuse memory.</p> <p>A related perspective comes from Human Tool (<a href="/papers/2602.12953" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Tang et al., 13 Feb 2026</a>), where a human collaborator is represented through a compact schema of Capabilities, Information, and Authority. The leader owns task decomposition, allocation, invocation timing, context packaging, state tracking, and reintegration of worker outputs; the worker contributes bounded information, judgment, creativity, or authorization only when routed (<a href="/papers/2602.12953" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Tang et al., 13 Feb 2026</a>). Here too, minimality depends on a disciplined interface contract rather than a rich shared context.</p> <h2 class='paper-heading' id='empirical-evidence-benefits-and-limitations'>6. Empirical evidence, benefits, and limitations</h2> <p>The strongest empirical evidence for Minimal-Toolset Leader-Worker Architecture comes from sustained deployment and task-specific evaluations. Deep Researcher Agent reports sustained deployments spanning 30+ days, 500+ autonomous experiment cycles across four concurrent research projects, 200+ experiments in one project, and an average LLM cost of \$plan_t \leftarrow Think(B, M_{t-1}, d)$0\times$ cost reduction (Zhang, 7 Apr 2026). These numbers reflect the combined effect of minimal tool sets, bounded memory, zero-cost monitoring, and single-worker execution.

ManagerWorker provides evidence that a capability-asymmetric manager-worker split can outperform weaker monolithic baselines when the manager has a genuine capability gap (Liu, 27 Mar 2026). On 200 SWE-bench Lite instances, full ManagerWorker reaches 124/200 = 62\%, compared with 120/200 = 60\% for a strong direct single agent, 106/199 = 53\% for a review-only simple loop, and 101/200 = 51\% for a weak direct agent (Liu, 27 Mar 2026). The paper concludes that the manager’s value lies in directing, not merely reviewing: review-only adds only 2 percentage points over the weak baseline, while structured exploration and planning add 11 points (Liu, 27 Mar 2026). This is directly relevant to minimal-toolset design because it shows that minimality of tool access does not imply minimality of control logic.

HTAA provides complementary evidence that reducing top-level tool exposure shortens trajectories and reduces context cost. On InfoVerify, token usage reductions with HTAA versus non-agentized variants include 50.6\% for Claude-Sonnet-4.5, 45.1\% for GPT-4o, and 40.5\% for Qwen3-8B (Huang et al., 13 Apr 2026). In production deployment on tens of thousands of daily POI verification tasks, the paper reports manual verification workload reduced by 84.5\% and manual annotation costs reduced by 81.25\% (Huang et al., 13 Apr 2026). These results support the claim that toolset compression at the planner level can have operational consequences beyond benchmark accuracy.

SMART-D shows that even a very lean manager-worker system, with no retrieval, tools, memory, or verifier modules, can benefit from reasoning-level synthesis rather than label voting (Sabbaghan et al., 10 Jun 2026). The framework yields 86.07 Macro-F1 on COVID-19 and 82.90 on SemEval-2016, with the largest gains on implicit and context-dependent stance cases (Sabbaghan et al., 10 Jun 2026). However, the paper also reports mixed results on P-Stance, where explicit surface cues dominate and extra multi-agent reasoning adds less value. This supports a recurring limitation in the literature: minimal leader-worker structure is most beneficial when ambiguity, decomposition, or long-horizon coordination matter.

Several limitations recur across papers. Deep Researcher Agent sacrifices intra-project parallelism through experiment.max_parallel: 1, relies partly on regex log parsing, and supports single-GPU scope in the open-source release (Zhang, 7 Apr 2026). ManagerWorker shows that structure without substance is pure overhead: a weak manager directing a weak worker performs worse than the weak worker alone on the shared subset, 42\% versus 44\% (Liu, 27 Mar 2026). HTAA notes that abstraction may hide fine-grained intermediate information and that performance depends on the quality of tool grouping (Huang et al., 13 Apr 2026). CollabToolBuilder presents only preliminary experiments, with a small dataset and no full ablation of role removal (Xavier et al., 1 Dec 2025). These results indicate that minimality improves efficiency and often stability, but does not remove the need for strong routing, evaluation, and memory design.

A common misconception is that a minimal-toolset architecture means “simpler overall.” The literature suggests a more precise statement: tool access can be sharply minimized even while orchestration logic remains rich. Another misconception is that all agents should share all tools for maximum flexibility. Across Deep Researcher Agent, ManagerWorker, and HTAA, the opposite pattern is repeatedly favored: expose as little as possible at the top level, specialize workers by function, and externalize role discipline into prompts, code, or stable interfaces (Zhang, 7 Apr 2026, Liu, 27 Mar 2026, Huang et al., 13 Apr 2026).

The broader significance of Minimal-Toolset Leader-Worker Architecture is therefore architectural rather than merely operational. It provides a systematic answer to a recurring systems question: how should capability be distributed when planning, execution, and evaluation have different information requirements and different cost profiles? The papers surveyed here converge on a consistent answer. Strategic control should remain centralized; workers should be specialized and tool-bounded; state should be compact and explicitly managed; and any rich coordination structure should be placed in code, memory, or interface contracts rather than in a shared unrestricted toolbox.