Paper deep dive
DAGent: Evaluate-then-Grow Planning for Deep Research Agents
Hanwen Liu, Yuanfu Sun, Qiaoyu Tan
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Deep research tasks require agents to navigate large knowledge spaces, synthesize evidence across many sources, and adapt their plans as findings emerge. Directed acyclic graph (DAG)-based multi-agent systems suit this setting because they support parallel execution and isolate each sub-task within a focused dependency context. Yet existing DAG-based agents instantiate a task-level plan before execution and repair the graph only after failures or missing evidence are observed. This Plan-then-Patch strategy is brittle for deep research: the system commits most strongly when its evidence is weakest, and later revisions waste computation on branches that should not have been planned. We propose DAGent, a DAG-based multi-agent framework with Evaluate-then-Grow incremental planning: an Orchestrator grows the task graph one batch at a time, conditioning each expansion on confidence and uncertainty signals from completed nodes. A hierarchical context layer propagates compact QueryDocs by default while preserving full execution traces for on-demand recall. The recorded DAG topology admits structural RL signals that outcome-only recipes cannot define; DAGRPO, a GRPO adaptation, injects topology-conditioned credit on Executor rollouts and a structural compliance regularization on Orchestrator plans. Across BrowseComp-Plus, GAIA, and xbench-DeepSearch, DAGent surpasses the strongest open-source baseline by 5.3 / 5.8 / 2.0 points at the Qwen3-235B-A22B scale, and the lead replicates across four open-source backbones and extends to GPT-5 at 327K context. At the Qwen3-8B scale, DAGRPO improves over a same-budget outcome-only GRPO baseline by 3.0 average Pass@1 points. A same-architecture comparison shows that evidence-conditioned planning reaches higher accuracy at lower per-task token, tool-call, and step footprints than its Plan-then-Patch counterpart. Code: this https URL
Tags
Links
- Source: https://arxiv.org/abs/2609.39154v1
- Canonical: https://arxiv.org/abs/2609.39154v1
Trouble viewing inline? Open PDF directly →
Full Text
118,598 characters extracted from source content.
Expand or collapse full text
DAGent: Evaluate-then-Grow Planning for Deep Research Agents Hanwen Liu 1,2 Yuanfu Sun 1,2 Qiaoyu Tan 2∗ 1 New York University 2 New York University Shanghai hl6825, ys6310, qt2097@nyu.edu Abstract Deep research tasks require agents to navigate large knowledge spaces, synthe- size evidence across many sources, and adapt their plans as intermediate findings emerge. Directed acyclic graph (DAG)-based multi-agent systems are well suited to this setting because they support parallel execution and isolate each sub-task within a focused dependency context. Yet existing DAG-based agents typically instantiate a task-level plan before execution and then repair the graph only after failures or missing evidence are observed. This Plan-then-Patch strategy is brittle for deep research: the system commits most strongly when its evidence is weakest, and later revisions often waste computation on branches that should not have been planned in the first place. To address this brittleness, we propose DAGent, a DAG- based multi-agent framework that introduces Evaluate-then-Grow incremental planning. Instead of committing to a full DAG upfront, an Orchestrator grows the task graph one batch at a time, conditioning each new expansion on confidence and uncertainty signals from completed nodes. To support long-horizon evidence use without overloading each sub-task, DAGent maintains a hierarchical context layer that propagates compact QueryDocs by default while preserving full execution traces for on-demand recall. The cleanly recorded DAG topology in turn admits structural RL signals that an outcome-only recipe cannot define; we instantiate this with DAGRPO, a GRPO adaptation that injects topology-conditioned credit on Executor rollouts and a structural compliance regularization on Orchestrator plans. Across BrowseComp-Plus, GAIA, and xbench-DeepSearch, DAGent surpasses the strongest open-source baseline by 5.3 / 5.8 / 2.0 points at the Qwen3-235B-A22B scale, with the lead replicating across four open-source backbones from four ven- dors and extending to GPT-5 at 327K context. At the Qwen3-8B scale, DAGRPO further improves over a same-budget outcome-only GRPO baseline by 3.0 average Pass@1 points. A same-architecture comparison further shows that incremental, evidence-conditioned planning reaches higher accuracy at lower per-task token, tool-call, and step footprints than its Plan-then-Patch counterpart, so the gains come from more targeted evidence expansion rather than additional computation. Code is available at https://github.com/hanwenliu6825/DAGent. 1 Introduction The rapid advancement of large language models has given rise to a new class of information-intensive tasks broadly referred to as deep research: tasks that require an AI system to autonomously navigate large knowledge spaces, synthesize information across dozens or hundreds of sources, and resolve complex queries through extensive multi-step reasoning. A growing body of work has established that ∗ Corresponding author. 40th Conference on Neural Information Processing Systems (NeurIPS 2026). arXiv:2609.39154v1 [cs.CL] 30 Sep 2026 DAG-based multi-agent systems are an effective architectural foundation for such tasks, decomposing a query into a directed acyclic graph of sub-tasks so that independent branches execute in parallel and each agent operates within a focused context window informed only by its dependencies rather than the full upstream history. The paradigm has been applied to parallel function calling [17], web search [6], multi-hop retrieval [39, 5] and long-horizon task decomposition [19]. Deep research, however, places greater demands on the planning mechanism than traditional informa- tion search: intermediate findings can redirect subsequent investigation and invalidate assumptions that looked reasonable at the outset, making static or semi-static planning a poor fit. Recent DAG- based deep research systems acknowledge this through execution-time editing. Flash-Searcher [33] produces its complete plan in a single decomposition call and then periodically updates it, and FlowSearch [14] initializes its knowledge-flow graph over several planner iterations, all of which precede execution, and then lets a separate refiner rewrite the graph through six edit operations. In both systems a plan that covers the whole task is committed before any node has executed, and later edits patch that standing plan. We term this paradigm Plan-then-Patch: it makes its largest planning commitment at precisely the moment when the system’s understanding of the problem is shallowest, and the resulting trajectories mix plan commitment with plan revision, degrading answer accuracy and wasting compute as task complexity grows. Therefore, we argue that benefiting fully from DAG-based decomposition in deep research requires both the planning paradigm and the reinforcement learning (RL) objective to reflect the fact that the DAG is built incrementally. Commit Full Plan Root Node Execute Root Node Root Node 3 Layers Layer + 1 (4 layers in total) Partial Node Failures Patch DAG Refinement Node Fail Node Fail Refine Delete Add Low-quality Answer Make Initial Plan Root Node Root Node Evaluate, then Grow! Evaluate DAG Expansion Finished Uncertain Layer + 1 Evaluate Self- Refine Layer + 1 Root Node High-quality Answer Layer + 1 (3 layers in total) Plan-then-Patch Evaluate-then-Grow (Ours) Figure 1: Comparison of Plan-then-Patch (top) and Evaluate-then-Grow (bottom) paradigms. To this end, we propose DAGent, a DAG-based multi-agent framework that replaces Plan-then- Patch with Evaluate-then-Grow incremental planning; Figure 1 contrasts the two paradigms. Instead of committing to a full task decompo- sition upfront, an Orchestrator grows the task DAG one batch of nodes at a time, using feed- back from each completed node to decide what to plan next; each newly added node is then executed in parallel by a ReAct Executor that runs a standard ReAct loop [47] equipped with domain-specific tools. To support long-horizon evidence use without overloading each sub-task, DAGent further maintains a hierarchical context layer on top of this incremental DAG: each node exposes a compact summary for default prop- agation to downstream nodes, and a complete execution trace that a downstream ReAct Execu- tor can retrieve on demand. Figure 2 illustrates the overall architecture. The cleanly recorded DAG topology that Evaluate-then-Grow produces enables reinforcement learn- ing signals that outcome-only recipes cannot define: rollouts at different DAG positions contribute unequally to the final answer, yet an outcome-only GRPO recipe assigns the trajectory-level reward uniformly across all rollouts. We exploit this with DAGRPO, a DAG-conditioned RL adaptation that augments a GRPO-style training recipe [36] with two structural signals: a topology-conditioned credit on Executor rollouts based on whether their outputs feed the final synthesis, and a structural compliance regularization on Orchestrator plans that fail validation. Both signals are uniquely deter- mined by the recorded trajectory because the DAG is append-only: no node is ever deleted or rewired, so the context a node saw when it ran coincides with its ancestry in the final graph. We evaluate DAGent on BrowseComp-Plus, GAIA, and xbench-DeepSearch, covering local retrieval, web search, and Chinese-language deep research. Across backbones from Qwen3-8B to Qwen3-235B- A22B, DAGent consistently outperforms the strongest training-free baseline on all three benchmarks, with the authors’ released implementation of FlowSearch included as a controlled baseline at Qwen3- 32B; the lead replicates across four open-source backbones from four vendors, and the framework remains competitive with state-of-the-art agent systems when scaled to GPT-5 at 327K context. 2 RL training with DAGRPO further improves Qwen3-8B DAGent over its role-separated GRPO counterpart at the same compute budget. Our major contributions are summarized below. 1. Evaluate-then-Grow planning. We introduce an incremental DAG planning paradigm that departs from Plan-then-Patch: the task DAG is grown on the fly through structured node state evaluation rather than committed to upfront and reactively edited. To the best of our knowledge, DAGent is the first deep research agent to condition each planning decision on structured per-node feedback that summarizes the sub-task outcome, rationale, and reliability. 2.DAGRPO. We present a DAG-conditioned reinforcement learning variant for deep research agents that exploits the incremental DAG through topology-conditioned credit assignment and a structural compliance regularization on Orchestrator plans. 3.Broad empirical advantage. We show that the advantage of DAGent is broad rather than concentrated: it holds across BrowseComp-Plus, GAIA, and xbench-DeepSearch, replicates across four open-source backbones from four vendors, and persists when scaled to GPT-5 with a 327K context. We further show that the structural signals of DAGRPO add gains on top of an outcome-only GRPO baseline at the same compute budget, with off-chain credit sensitivity confirming that the gain is not a hyperparameter artifact. 2 Related Work 2.1 Deep Research Agents Long-horizon deep research stresses both the context window and the planning depth of an LLM, motivating two complementary lines of work that extend the linear reasoning-and-acting paradigm [47]. The first manages context across a long linear trajectory: summary-based methods periodically compress the history into a summary state [13,44,16,22], and folding-style methods maintain context through branch-and-fold operations over linear sessions [38,48,35]. The second decomposes the task into a structured plan: static DAG planners parallelize tool calls or multi-hop retrieval [17,6,39,5,51], and Plan-then-Patch deep research agents commit a task-covering plan before any node executes, in one decomposition call [33] or over several planner iterations [14], and then edit it during execution; concurrent variants explore per-node localized DAGs [19] and hierarchical-outline planning [21]. A growing set of proprietary deep research products [29,24,37,27,25] and open- source frameworks [34,54,32] report results on public deep research benchmarks. Across these lines, planning either operates on linear trajectories with no multi-parent dependencies, or commits the structured plan before any node has executed. DAGent differs by growing the DAG one batch at a time under structured per-node signals: the confidence and uncertainty fields of each completed node drive every new expansion of the graph. 2.2 Structure-Aware RL-Based Optimization for LLM Agents Group-based policy gradient methods such as GRPO [36] and DAPO [49] have become the dominant online RL backbone for LLM agents, with adaptations to summary-based and fold-based long-horizon agents [44,38]. Applied to multi-turn agents, these outcome-only recipes assign the trajectory-level reward uniformly across rollout tokens and ignore intra-trajectory structure. A parallel line of work injects finer-grained structural signals into the advantage at different granularities: turn-level [41], step-level via anchor-state grouping [11], tree-structured rollouts [15], and tool-use DAGs with graph-based rewards or dependency-aware grouping [23,43]; for deep research planning specifically, DeepPlanner [10] shapes GRPO advantages with an entropy-based term without exploiting DAG topology. Concurrent work on multi-agent RL assigns credit by role [12], by counterfactual removal of an agent [20], or over a learned communication topology among a fixed set of agents [2]; Ap- pendix B.3 contrasts these with DAGRPO. A topology-conditioned credit over the answer-feeding chain is uniquely determined by the recorded trajectory only when the graph is append-only. Plan- then-Patch trajectories do not preserve this property, since a node can be planned, executed, and later deleted or rewired, so its ancestry in the final graph need not match what the synthesis actually read. DAGRPO instantiates this signal on top of Evaluate-then-Grow. 3 3 Method Figure 2 illustrates the DAGent architecture. Section 3.1 introduces Evaluate-then-Grow incremental planning together with the hierarchical context layer it supports; Section 3.2 introduces DAGRPO, a DAG-conditioned RL adaptation that exploits the topology §3.1 records turn by turn. <summary> x≈ Evaluate-then-Grow Incremental Planning Identify the name of the artist who: (1) Father was a Protestant minister... (2) Married a fashion designer... (3) Established a school in a village... Deep Research Question Input Plan & Execute x≈ Toolbox ... Evaluate Node Status Self-Refined Nodes ... x N Answer Node Hierarchical Context Propagation QueryDoc <ans>, <expl>, <confidence> <summary>, <uncertainties> ... QueryDoc (enough) QueryDoc <Recall> <Recall><full trace> (a) (b) x≈ subsequent execution subsequent evaluation success node uncertain node not found node refine node orchestrator ... executor x≈ Representative Planning Paradigms Succeeded and Expanded : I need to find out which artist.. confidence:1.0,no uncertain... : The answer is correct and certain...The status should be success...expand down one ... x≈ Uncertain and Refine : I need to find out which artist... confidence:0.1, uncertainties... : The answer is possibly correct.. need further check... uncertain ...expand down a refine node... (a)(b) x≈ Successfully Refined : I need to further check the... confidence:0.9, uncertainties.. : The answer is correct and certain... The status... refined node should be success... x≈ Stopped after Repeated Failures : I need to further check the... confidence:0.1, uncertainties.. : The answer is wrong ... The status should be... since the budget is exhausted... stop... (c)(d) ... DAG-structured Policy Optimization ... x≈ Executor-side Reward Design Answer Path Excluded Final-answer Correctness Answer-path membership x≈ Orchestrator-side Reward Design Format Following Human- instruction compliance Final-answer Correctness Instruction Non- redundancy RL-based Model Training (a)(b) (c) (d) Figure 2: Overview of DAGent. The top panel shows Evaluate-then-Grow planning, where the Orchestrator evaluates each executed layer and expands the DAG accordingly. Nodes marked as Uncertain or Not Found trigger refine nodes for further verification, while child nodes receive the required context from their parents until an answer node is produced. The bottom-left panel shows four representative planning cases (a–d), marked at the corresponding nodes of the top panel: a node that succeeded and was expanded, a node that was uncertain and refined, a successfully refined node, and a node stopped after its refine budget was exhausted. The bottom-right panel summarizes DAG- structured policy optimization, where Orchestrator and Executor rewards are computed separately and optimized jointly, as detailed in §3.2. 3.1 Evaluate-then-Grow Incremental Planning Deep research planning is a sequential decision problem under evolving evidence: each completed sub-task may redirect the investigation or invalidate prior assumptions. Unlike Plan-then-Patch agents, which commit to a full DAG before execution and repair it reactively, Evaluate-then-Grow commits one batch at a time, conditioning each expansion on the structured outputs of completed nodes. We next formalize the DAG state, per-node evidence, the Evaluate-then-Grow loop, and dependency-aware context propagation, which together define the execution substrate of DAGent. DAG State and Node-Level Evidence.A deep research taskTis modeled as a DAGG = (V,E), where each nodev i ∈ Vis an atomic sub-task and each edge(v j ,v i )∈ Eindicates thatv i depends onv j ’s output. The graph is initialized empty and incrementally expanded by the Orchestrator. Each node contains a descriptionδ i for the sub-task, an execution promptp i for the Executor, a dependency setdep i ⊂ Vof required upstream nodes, and a statusσ i assigned by the Orchestrator. We further define two special node types: a refine node, which re-executes a sub-task with an alternative search strategy, and an answer-type node, which synthesizes the final response from upstream evidence. After execution, each node outputs a compact QueryDoc and preserves a full InteractionTranscript. 4 Per-Node Evidence. Each node v i emits a compact structured summary, the QueryDoc (D i ): D i = (α i , expl i , steps i , conf i , unc i ),(1) whereα i is the answer to the current sub-task,expl i is a brief explanation of the answer,steps i summarizes the key execution steps,conf i ∈ [0, 1]denotes the confidence of the Executor, andunc i lists uncertainties that may require further verification. The first three fields record the sub-task outcome and rationale, while the last two signal its reliability for Orchestrator evaluation. In addition, we retain the complete execution trace of each Executor as the InteractionTranscript (T i ): T i =⟨(a (i) 1 ,o (i) 1 ), ..., (a (i) n ,o (i) n )⟩,(2) wherea (i) t is an action (e.g., search or page retrieval) at steptando (i) t the corresponding observation. Evaluate-then-Grow DAG Expansion.At each iterationk, the Orchestratorπ O examines recently completed nodes and produces a planning decision: P k = π O (T , G k ) = (S k , V new k ).(3) The state evaluationS k assigns each node in the latest executed batch a QueryDoc-grounded status: Success, indicating confident evidence acquisition; Uncertain, indicating evidence that requires further verification or refinement; or Not Found, indicating valid execution without relevant evidence. Nodes marked Uncertain or Not Found spawn refine nodes for further verification or alternative search, with each line capped at three attempts: one initial execution and two refinements. The targeted expansionV new k then instantiates new nodes with their descriptions, prompts, and dependency edges; nodes within a batch that share no dependencies execute in parallel. Termination is triggered when the Orchestrator schedules an answer-type node inV new k ; this node depends on the evidence nodes selected as relevant by the Orchestrator and is required to appear alone in its batch, ensuring access to the intended upstream evidence for final synthesis. Hierarchical Context Propagation. Long-horizon deep research can produce InteractionTran- scripts of arbitrary length, but downstream nodes typically need only the conclusions of their depen- dencies. Each sub-task is executed by a ReAct Executorπ R equipped with domain-specific tools and RECALLTOOL. Upon completion,π R produces a QueryDoc and preserves its full interaction history as an InteractionTranscript. By default, a node receives only the QueryDocs of its direct dependencies as upstream context. We call this policy Selective Propagation, which bounds each node’s context by its fan-in rather than the graph depth or total number of nodes. When the compact QueryDoc is insufficient, e.g., when downstream execution needs the exact wording of a passage or a previously rejected candidate, the Executor can retrieve targeted information from the full transcript of a direct dependency by calling the RECALLTOOL: E = Recall(v j , goal, T j ),(4) wherev j ∈ dep i is a direct dependency,goalspecifies the information needed by the Executor, and a language model extracts fromT j a focused evidence snippetEconditioned on this goal. RECALLTOOL is a fallback rather than a default: in the Qwen3-32B runs it is invoked in 22.0 / 13.6 / 11.0% of tasks on BrowseComp-Plus / GAIA / xbench-DeepSearch (Appendix D.4). Remark . Each iteration appends a new batch of nodes with their dependencies, producing a DAG whose growth history is recorded turn by turn; the structural RL signals of §3.2 are defined on it. 3.2 DAGRPO: DAG-Conditioned Reinforcement Learning Evaluate-then-Grow produces training trajectories whose DAG topology is recorded turn by turn. This recorded structure exposes a fact that linear-trajectory recipes cannot use: rollouts at different DAG positions contribute unequally to the final answer. Some Executor rollouts lie on the dependency chain feeding the answer-type node, while others explore alternatives the synthesis never consumes. An outcome-only GRPO recipe assigns the trajectory-level rewardR(τ )∈0, 1uniformly across all rollouts and ignores this DAG-induced structure. We instantiate the missing structural infor- mation asDAG-conditionedGroupRelativePolicyOptimization (DAGRPO). DAGRPO adapts GRPO by shaping the per-rollout reward with two structural signals before group normalization: a topology-conditioned credit on ReAct Executor rollouts and a structural compliance regularization on Orchestrator turns. DAGRPO builds on the standard GRPO objective, injecting DAG-aware structural signals into reward construction without altering the underlying optimization form. 5 Learning Objective.For a taskT, we sampleGon-policy trajectories fromπ θ old ; each trajectoryτ comprises one Orchestrator sub-rollout and the ReAct Executor sub-rollouts it spawns, jointly indexed byiwith response tokensy i , and is assigned a trajectory-level outcome rewardR(τ )∈0, 1by an LLM judge that verifies final-answer correctness, as detailed in §4.1. The DAGRPO objective is J DAGRPO (θ) =E 1 |y τ | X i,t min ρ i,t (θ) ˆ A (u) i , clip ρ i,t (θ), 1− ε ℓ , 1 + ε h ˆ A (u) i ,(5) whereu ∈ orch, execdenotes the role andρ i,t (θ)is the per-token importance ratio between the current and old policy,|y τ | = P i |y i |is the total response-token count inτ,ε h > ε ℓ gives the DAPO-style asymmetric clip [49], and the role-separated group-relative advantage is ˆ A (u) i = ̃r (u) i − μ u σ u , ̃r (u) i = R(τ )u = exec, v i ∈ S(τ ) αR(τ )u = exec, v i /∈ S(τ ) R(τ ) + r proc (τ ) u = orch, (6) where(μ u ,σ u )are computed within the corresponding role group: the Orchestrator group contains theGsampled trajectories, while the Executor group contains all retained Executor rollouts spawned by them. Here,α ∈ [0, 1]controls the attenuation of off-chain Executor credit,S(τ )denotes the answer-inclusive closure, andr proc (τ )≤ 0is the structural compliance regularization, both detailed below. We also include a small KL-to-reference loss outside Eq.(5)to stabilize long-horizon agent training. Additional details and the reasons behind these choices are given in Appendix B. Topology-Conditioned Credit.Lett answer denote the answer-type node scheduled in the terminating iteration. We define the answer-inclusive closureS(τ )ast answer together with all of its ancestors inG: the set of ReAct Executor rollouts whose outputs directly or transitively fed the final synthesis. ReAct Executors inS(τ )retain the fullR(τ )while those outside are attenuated byα. Whenτcontains no answer-type node, we setα = 1as a fallback and recover the outcome-only GRPO behavior. The closure is a structural proxy for contribution rather than a causal attribution: it is read off the recorded graph without re-execution, and Appendix B explains why it cannot be exploited by inflating dependency edges during training. Structural Compliance Regularization. Evaluate-then-Grow imposes structural constraints on Orchestrator decisions, requiring each plan to be both syntactically valid and consistent with the incremental execution loop. Specifically, the Orchestrator must assign every node in the previous batch an explicit Success, Uncertain, or Not Found status; expand each refinable Uncertain or Not Found node with a refine node within the three-attempt budget; schedule the answer-type node as a singleton batch so final synthesis can access all upstream evidence; avoid duplicate sub-task prompts; and output parseable JSON with valid dependency references. LetN (τ )denote the number of Orchestrator turns inτthat violate these constraints. We definer proc (τ ) =−λ proc min(N (τ ),K proc ), whereλ proc ∈ (0, 1]controls the regularization scale andK proc caps its magnitude. This term is added to the trajectory-level Orchestrator reward to penalize structurally invalid planning decisions. Remark. DAGent rests on a single structural fact: incremental planning produces a DAG whose growth history is recorded turn by turn, and that recorded structure is what the rest of the method exploits. The hierarchical context layer uses it to bound each node’s per-sub-task footprint by graph topology rather than total trajectory length; DAGRPO uses it to define credit-assignment signals that an outcome-only recipe cannot express. Both rest on the incremental loop of §3.1, and removing it weakens both. The complete DAGent workflow is summarized in Algorithm 1 in Appendix A. 4 Experiments We organize the experiments around four research questions (RQs). RQ1: How does DAGent compare with deep research baselines on representative benchmarks in both training-free and training-based settings? RQ2: Does the lead replicate across backbone scales, vendors, and a frontier closed-source backbone? RQ3: Which planning and DAGRPO structural components drive the gains of DAGent? RQ4: How efficient is DAGent compared with the Plan-then-Patch alternative? 6 4.1 Experimental Setup Benchmarks.We evaluate on three deep research benchmarks, each with a fixed retrieval backend that every method shares. BrowseComp-Plus [7] pairs the original BrowseComp queries [40] with a verified corpus; retrieval is local dense retrieval over this corpus with Qwen3-Embedding-8B, and we adopt the 680/150 train/evaluation split of Sun et al.[38], balanced across easy, medium, and hard difficulty. GAIA [26], a benchmark for evaluating complex task-solving capabilities, is evaluated primarily on its 103-task text-only validation subset with live Google search through Serper and page extraction through Jina; the full 165-task validation set is used only for the GPT-5 327K comparison in Figure 4, for comparability with prior work, with image, document, and audio inspector tools added to handle multi-modal questions as detailed in Appendix D.1. The 2505 release of xbench-DeepSearch [4,45] contains 100 Chinese-language tasks and uses the same Serper and Jina stack as GAIA. Checkpoints trained on BrowseComp-Plus transfer zero-shot to the other two benchmarks, following the standard practice of agent RL [38]. Baselines. We compare against five agent families under the same backbone and tool stack: (1) ReAct Agent [47] at 32K and 109K context with a pre-overflow warning as a termination control; (2) Summary Agent [13,44,16,22], which invokes a summary on overflow with up to 10 sessions; (3) Fold Agent [38,48,35], representative of context-folding methods; (4) Flash-Searcher [33], a Plan-then-Patch DAG agent reproduced from the authors’ release with summary interval 4 to fit the 32K-per-sub-task budget; and (5) FlowSearch [14], a Plan-then-Patch DAG agent evaluated with the authors’ released implementation with its Coordinator (the execution-conditioned refiner) enabled, at Qwen3-32B only, because its code was released after our initial submission (configuration in Appendix C.3). At Qwen3-8B we additionally report the three trainable baselines under outcome-only GRPO, and DAGent under both outcome-only GRPO with α = 1.0 and no structural regularization (denotedGRPO-DAGent) and DAGRPO (denotedDAGRPO-DAGent); the GRPO variant is the same- budget direct baseline for DAGRPO. Implementation. Backbones are Qwen3-8B, Qwen3-32B, and Qwen3-235B-A22B [46] for training-free evaluation and Qwen3-8B for RL training, all with thinking disabled and, per sub- task, a 32K-token response budget on top of an 8K-token prompt (Appendix C.2). RL is trained on BrowseComp-Plus with the DAPO asymmetric clip [49], off-chain creditα = 0.5, and the structural compliance regularization. Inference uses greedy decoding; Pass@1 is scored by a human-calibrated LLM judge, with details in Appendix C. 4.2 Main Results (RQ1, RQ2) Table 1 reports Pass@1 across three benchmarks for DAGent and the baselines of §4.1 at three Qwen3 backbone scales, in training-free and training-based settings. Qwen3-32BSeed-OSS-36BGLM-4-32BNemotron-3-Nano-30B 0 10 20 30 40 50 60 70 80 Pass@1 (%) 47.3 54.0 48.7 50.0 55.3 54.4 52.4 57.3 65.0 69.0 67.0 59.0 BrowseComp-PlusGAIAxbench-DeepSearch Figure 3: Cross-backbone DAGent Pass@1 (%); per-baseline breakdown in Appendix D.1. Observation 1:DAGent leads the strongest non-DAGent training-free baseline at every Qwen3 backbone scale across the three bench- marks. At Qwen3-32B, DAGent reaches 47.3 / 55.3 / 65.0 on BrowseComp-Plus / GAIA / xbench-DeepSearch, 4.0 / 3.8 / 2.0 points above FlowSearch, the strongest baseline at this scale, and 6.0 / 10.6 / 7.0 points above the strongest of the remaining baselines. The lead persists at 8B (+5.3 / +7.8 / +5.0) and 235B-A22B (+5.3 / +5.8 / +2.0), and on every difficulty split DA- Gent matches or exceeds every baseline, with two ties at 235B-A22B; relative gains grow with difficulty at 8B and 32B. Observation 2: DAGRPO further improves Qwen3-8B DAGent over a same-budget outcome-only GRPO baseline by 3.0 average points, isolating the gain to its structural signals. DAGRPO improves the BrowseComp-Plus / GAIA / xbench-DeepSearch Pass@1 of DAGent from 40.0 / 46.6 / 60.0 in training-free mode to 49.6 / 53.4 / 65.7 over three seeds, exceeding the GRPO baseline by 3.6 / 2.6 / 2.7 points; per-seed values appear in Appendix E.1. The same outcome-only GRPO recipe improves 7 Table 1: Main results on BrowseComp-Plus, GAIA, and xbench-DeepSearch: Pass@1 (%), best result per backbone in bold. Training-free rows use a single greedy inference pass; training-based rows report mean±std (sample standard deviation) over three training seeds on the benchmark averages. FlowSearch is evaluated with the authors’ released implementation at Qwen3-32B only (§4.1). BackboneMax #Token Agent Paradigm BrowseComp-PlusGAIAxbench-DS Easy Med. HardAvg.L1L2L3Avg.Avg. Training-free Qwen3-8B 32KReAct Agent46.014.00.020.038.5 23.1 25.029.139.0 109KReAct Agent64.018.02.028.046.2 26.9 25.034.044.0 32K×NSummary Agent76.020.02.032.751.3 26.9 16.735.054.0 32K×NFold Agent78.024.02.034.748.7 28.8 16.735.052.0 32K×NFlash-Searcher78.024.02.034.751.3 32.7 25.038.855.0 32K×NDAGent (Ours)84.030.06.040.059.040.433.346.660.0 Qwen3-32B 32KReAct Agent50.016.02.022.746.2 28.88.333.054.0 109KReAct Agent66.024.04.031.351.3 36.5 16.739.858.0 32K×NSummary Agent80.036.00.038.751.3 28.8 25.036.955.0 32K×NFold Agent82.040.02.041.356.4 38.5 16.742.755.0 32K×NFlash-Searcher80.034.02.038.756.4 40.4 25.044.758.0 32K×NFlowSearch84.042.04.043.366.7 46.2 25.051.563.0 32K×NDAGent (Ours)88.046.08.047.369.250.033.355.365.0 Qwen3-235B 32KReAct Agent84.032.010.042.056.4 55.8 33.353.460.0 109KReAct Agent90.050.016.052.061.5 57.7 41.757.364.0 32K×NSummary Agent88.060.020.056.059.0 53.8 25.052.460.0 32K×NFold Agent94.056.014.054.761.5 53.8 25.053.462.0 32K×NFlash-Searcher90.054.014.052.764.1 55.8 25.055.370.0 32K×NDAGent (Ours)94.068.022.061.374.459.641.763.172.0 Training-based Qwen3-8B 32KGRPO-ReAct Agent72.016.04.030.7± 1.841.0 26.9 25.0 32.0± 2.9 43.0± 2.6 109KGRPO-ReAct Agent76.024.04.034.7± 2.448.7 30.8 25.0 36.9± 1.9 48.0± 2.0 32K×NGRPO-Summary Agent 80.030.04.038.0± 2.053.8 30.8 25.0 38.8± 1.7 57.0± 1.7 32K×NGRPO-Fold Agent84.034.06.041.3± 1.351.3 32.7 25.0 38.8± 2.6 56.0± 3.0 Qwen3-8B32K×NGRPO-DAGent88.040.010.046.0± 1.261.546.833.350.8± 1.163.0± 1.0 Qwen3-8B32K×NDAGRPO-DAGent90.048.010.749.6± 1.064.150.033.353.4± 1.065.7± 1.5 each trainable baseline by 2.9 to 10.7 points across the three benchmarks, so the further DAGRPO gain on DAGent localizes to the structural signals rather than the training budget. Observation 3:The lead replicates across four mid-size open-source backbones from four vendors and persists at frontier scale with GPT-5 at 327K context. Figure 3 shows that DAGent maintains the per-backbone top position across Qwen3-32B, Seed-OSS-36B [1], GLM-4-32B [53], and Nemotron- 3-Nano-30B [28], with the per-baseline breakdown in Appendix D.1. DAGent at GPT-5 327K leads the strongest reported baseline by 5.7 / 2.5 / 2.0 points on BrowseComp-Plus / GAIA / xbench- DeepSearch (Figure 4), with GAIA evaluated on its full 165-task validation set with multi-modal tools; the baseline list and number provenance appear in Appendix D.1. Qwen3-235B-A22B GLM-4.5-Air DeepSeek-V3.1 GPT-4.1 GPT-5 DAGent (GPT-5) 0 20 40 60 80 100 Pass@1 (%) 56.0 56.6 61.3 64.0 79.3 85.0 BrowseComp-Plus (N=150) OpenAI DR Manus Alita Skywork DR FlowSearch (o4-mini) Flash-Searcher (GPT-5) DAGent (GPT-5) 0 20 40 60 80 100 Pass@1 (%) 67.4 73.3 75.2 82.482.4 83.0 85.5 GAIA (N=165) OAgents (GPT-4.1) Metaso DR BrowseMaster (DeepSeek-R1) Kimi Researcher Flash-Searcher (GPT-5) DAGent (GPT-5) 0 20 40 60 80 100 Pass@1 (%) 47.0 64.0 66.0 69.0 83.0 85.0 xbench-DeepSearch (N=100) Open-SourceClosed-SourcePlan-then-PatchDAGent (GPT-5) Figure 4: Performance comparison of DAGent and state-of-the-art agent systems on BrowseComp- Plus, GAIA, and xbench-DeepSearch. Pass@1 (%) is reported. 8 Table 2: Component ablation with Qwen3-32B in training-free mode: Pass@1 (%) per benchmark, Overall is the unweighted mean, and∆is the change from DAGent (Full). All rows use a single greedy inference pass, as in the training-free rows of Table 1. Method BrowseComp-PlusGAIAxbench-DSOverall Avg.∆Avg.∆Avg.∆Avg.∆ DAGent (Full)47.3—55.3—65.0—55.9— Plan-then-Patch Variant42.0-5.350.5-4.861.0-4.051.2-4.7 w/o Evaluate-then-Grow Planning 33.3-14.042.7 -12.6 55.0 -10.0 43.7 -12.2 w/o Selective Propagation34.7-12.644.7 -10.6 57.0-8.045.5 -10.4 w/o QueryDoc39.3-8.047.6-7.760.0-5.049.0-6.9 w/o InteractionTranscript43.3-4.052.4-2.963.0-2.052.9-3.0 4.3 Ablation Study (RQ3) This subsection ablates DAGent at two layers: Table 2 dissects the prompt layer on Qwen3-32B, and Table 3 dissects the RL layer on Qwen3-8B, where the DAGRPO and GRPO-baseline rows reproduce the three-seed means of Table 1 and the remaining rows use a single training seed. Observation 4:Within the same DAGent architecture, evidence-conditioned incremental graph growth outperforms pre-execution commitment with reactive patches, which in turn outperforms a single upfront plan; the three context components contribute non-trivially on top. Replacing Evaluate-then-Grow with Plan-then-Patch costs 5.3 / 4.8 / 4.0 points on BrowseComp-Plus / GAIA / xbench-DeepSearch, isolating evidence-conditioned planning from the generic patch capability; collapsing further to a single upfront plan with no replanning costs another 8.7 / 7.8 / 6.0 points, totaling 14.0 / 12.6 / 10.0. Among context-management components the drop ordering is consistent across the three benchmarks: Selective Propagation (12.6 / 10.6 / 8.0) outranks QueryDoc (8.0 / 7.7 / 5.0), which outranks InteractionTranscript (4.0 / 2.9 / 2.0); the last row is also the RECALLTOOL ablation, since removing the transcript disables recall (Appendix D.4). Observation 5:Both DAGRPO structural signals contribute positive Pass@1 gains, with the off- chain credit coefficientαpeaking at 0.5. Removing topology-conditioned credit from full DAGRPO costs 2.3 / 1.9 / 1.7 points on the three benchmarks, and removing the structural compliance regular- ization costs 1.6 / 1.0 / 0.7 points (Table 3). Because the ablation rows use a single seed while the DAGRPO row is a three-seed mean with std 1.0 / 1.0 / 1.5, the smaller per-benchmark differences are within seed noise; the support for both signals is the consistent sign of every per-benchmark difference and the Overall differences of−2.0and−1.1. Theαsweep peaks at 0.5 on every benchmark;α = 0 pushes performance below the GRPO baseline as off-chain learning collapses, whileα = 0.25retains 75 / 62 / 37% of the gain over the GRPO baseline because partial attenuation already polarizes the credit signal. Training-time mechanism traces of both signals appear in Appendix E.2. Table 3: DAGRPO component ablation andαsensitivity on Qwen3-8B: Pass@1 (%) per benchmark, Overall is the unweighted mean, and∆is the change from DAGRPO; the Overall∆is the mean of the three per-benchmark∆values and can differ by 0.1 from the difference of the rounded Overall values. The DAGRPO and GRPO-baseline rows are the three-seed means of Table 1; all other rows are single-seed runs with the same training budget. αRegularization Configuration BrowseComp-PlusGAIAxbench-DSOverall Avg.∆Avg.∆Avg.∆Avg.∆ 0.00on—44.0-5.649.5 -3.9 61.0-4.751.5 -4.7 0.25on—48.7-0.952.4 -1.0 64.0-1.755.0 -1.2 0.50onDAGRPO49.6—53.4—65.7—56.2— 0.75on—48.0-1.652.4 -1.0 64.0-1.754.8 -1.4 1.00onw/o topology credit47.3-2.351.5 -1.9 64.0-1.754.3 -2.0 0.50offw/o compliance regularization 48.0-1.652.4 -1.0 65.0-0.755.1 -1.1 1.00offGRPO baseline46.0-3.650.8 -2.6 63.0-2.753.3 -3.0 9 4.4 Efficiency Analysis (RQ4) We measure the per-task footprint of DAGent with Qwen3-32B in training-free mode. The 32K×N of Table 1 is a per-sub-task cap shared by all multi-context methods, not a per-task budget; the totals below are what each workflow spends under it. Execution steps count Orchestrator rounds plus the longest Executor trajectory per parallel batch; tool calls count all search, open_page, recall, and plan invocations. Appendix D.3 extends the comparison to Flash-Searcher and FlowSearch and adds external tool calls (search and open_page only) and wall-clock time. Observation 6:The per-task tool-call-to-step ratio of DAGent is tightly distributed and scales with task complexity, so the DAG-based architecture adds tool calls in proportion to task difficulty rather than inflating redundant steps. Median tool-call-to-step ratios are 1.6, 1.1, and 1.2 on BrowseComp-Plus, GAIA, and xbench-DeepSearch in Figure 5(a), tracking task complexity, with a tight interquartile range on GAIA. Mean per-task footprints are 42.7 / 31.2 / 26.8 steps, 67.6 / 36.8 / 32.9 tool calls, and 1.20M / 0.66M / 0.44M total input plus output tokens. 020406080100120 Execution Steps 0 25 50 75 100 125 150 175 200 Tool Calls BrowseComp-Plus (N=150) GAIA (N=103) xbench-DeepSearch (N=100) BrowseComp-Plus GAIA xbench-DeepSearch 0.75 1.00 1.25 1.50 1.75 2.00 2.25 Tool Calls / Execution Steps BrowseComp-Plus GAIA xbench-DeepSearch 0.00 0.25 0.50 0.75 1.00 1.25 1.50 1.75 2.00 Tokens (M) 1.20 0.66 0.44 1.68 0.85 0.52 DAGent (Full) w/ Plan-then-Patch BrowseComp-Plus GAIA xbench-DeepSearch 0 10 20 30 40 50 60 Execution Steps 43 31 27 55 38 32 0 20 40 60 80 100 Tool Calls 68 37 33 88 45 38 0.0 0.1 0.2 0.3 0.4 0.5 Off-chain Ratio 0.25 0.20 0.18 0.40 0.30 0.25 (a)(b) Figure 5: DAGent per-task efficiency on Qwen3-32B training-free. (a) Tool calls vs. execution steps with 2.2σconfidence ellipses, and per-task tool calls per step. (b) DAGent (Full) vs. the Plan-then-Patch variant on per-task footprint metrics. Observation 7:Within the same DAGent architecture, Plan-then-Patch inflates per-task token, tool-call, and node footprints while accuracy lags Evaluate-then-Grow on every benchmark. Plan- then-Patch commits a broader DAG before observing node-level evidence, increasing the off-chain Executor ratio from 0.25 / 0.20 / 0.18 to 0.40 / 0.30 / 0.25 and adding 40 / 29 / 18% more tokens plus 28 / 21 / 21% more execution steps (Figure 5(b); per-task means in Table 10 of Appendix D.3). It also makes 35 / 27 / 21% more external tool calls and needs 35 / 27 / 23% more wall-clock time per task, yet still trails DAGent (Full) by 5.3 / 4.8 / 4.0 Pass@1 points (Table 2): incremental, evidence-conditioned planning avoids redundant branches while improving accuracy. 5 Conclusion We presented DAGent, a DAG-based multi-agent framework for deep research that replaces Plan- then-Patch commitment with Evaluate-then-Grow incremental planning, and DAGRPO, a DAG- conditioned reinforcement learning adaptation that exploits the recorded topology Evaluate-then- Grow produces. Across BrowseComp-Plus, GAIA, and xbench-DeepSearch, DAGent consistently outperforms strong open-source baselines across backbone scales, vendors, and frontier-scale settings, leads the authors’ released FlowSearch implementation in a controlled Qwen3-32B comparison, and does so at a lower per-task cost than its Plan-then-Patch counterparts. DAGRPO adds further gains over a same-budget outcome-only GRPO baseline. References [1] ByteDance Seed Team. Seed-OSS open-source models. Hugging Face model card, 2025. URL https://huggingface.co/ByteDance-Seed/Seed-OSS-36B-Instruct. Model card for the Seed-OSS-36B-Instruct checkpoint; companion repository athttps://github.com/ ByteDance-Seed/seed-oss. [2] Yueyang Cang, Xiaoteng Zhang, Erlu Zhao, Zehua Ji, Yuhang Liu, Yuchen He, Zhiyuan Ning, Yijun Chen, Wenge Que, and Li Shi. Graph-GRPO: Stabilizing multi-agent topology learning 10 via group relative policy optimization. In Findings of the Association for Computational Lin- guistics: ACL 2026, pages 20222–20231. Association for Computational Linguistics, 2026. doi: 10.18653/v1/2026.findings-acl.1010. URLhttps://aclanthology.org/2026.findings- acl.1010/. [3]Chi-Min Chan, Weize Chen, Yusheng Su, Jianxuan Yu, Wei Xue, Shanghang Zhang, Jie Fu, and Zhiyuan Liu. ChatEval: Towards better LLM-based evaluators through multi-agent debate. In The Twelfth International Conference on Learning Representations, 2024. URL https://openreview.net/forum?id=FQepisCUWu. [4]Kaiyuan Chen, Yixin Ren, Yang Liu, Xiaobo Hu, Haotong Tian, Tianbao Xie, Fangfu Liu, Haoye Zhang, Hongzhang Liu, Yuan Gong, Chen Sun, Han Hou, Hui Yang, James Pan, Jianan Lou, Jiayi Mao, Jizheng Liu, Jinpeng Li, Kangyi Liu, Kenkun Liu, Rui Wang, Run Li, Tong Niu, Wenlong Zhang, Wenqi Yan, Xuanzheng Wang, Yuchen Zhang, Yi-Hsin Hung, Yuan Jiang, Zexuan Liu, Zihan Yin, Zijian Ma, and Zhiwen Mo. xbench: Tracking agents productivity scaling with profession-aligned real-world evaluations, 2025. URLhttps://arxiv.org/ abs/2506.13651. [5] Shengyuan Chen, Chuang Zhou, Zheng Yuan, Qinggang Zhang, Zeyang Cui, Hao Chen, Yilin Xiao, Jiannong Cao, and Xiao Huang. You don’t need pre-built graphs for RAG: Retrieval aug- mented generation with adaptive reasoning structures. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 40, pages 30270–30278. AAAI Press, 2026. doi: 10.1609/aaai. v40i36.40278. URL https://ojs.aaai.org/index.php/AAAI/article/view/40278. [6]Zehui Chen, Kuikun Liu, Qiuchen Wang, Jiangning Liu, Wenwei Zhang, Kai Chen, and Feng Zhao. MindSearch: Mimicking human minds elicits deep AI searcher. In The Thirteenth International Conference on Learning Representations, 2025. URLhttps://openreview. net/forum?id=xgtXkyqw1f. [7]Zijian Chen, Xueguang Ma, Shengyao Zhuang, Ping Nie, Kai Zou, Sahel Sharifymoghaddam, Andrew Liu, Joshua Green, Kshama Patel, Ruoxi Meng, Mingyi Su, Yanxi Li, Haoran Hong, Xinyu Shi, Xuye Liu, Hosna Oyarhoseini, Nandan Thakur, Crystina Zhang, Luyu Gao, Wenhu Chen, and Jimmy Lin. BrowseComp-Plus: A fair and disentangled evaluation benchmark for deep search agents. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 22349–22370. Association for Computational Linguistics, 2026. doi: 10.18653/v1/2026.acl-long.1023. URLhttps:// aclanthology.org/2026.acl-long.1023/. [8]DeepSeek-AI.DeepSeek-V3.1.Hugging Face model card, 2025.URLhttps:// huggingface.co/deepseek-ai/DeepSeek-V3.1. [9]Mingxuan Du, Benfeng Xu, Chiwei Zhu, Licheng Zhang, Xiaorui Wang, and Zhendong Mao. DeepResearch Bench: A comprehensive benchmark for deep research agents. In The Fourteenth International Conference on Learning Representations, 2026. URLhttps: //openreview.net/forum?id=hQ0K2Hhq7H. [10] Wei Fan, Wenlin Yao, Zheng Li, Feng Yao, Xin Liu, Liang Qiu, Qingyu Yin, Yangqiu Song, and Bing Yin. DeepPlanner: Scaling planning capability for deep research agents via advantage shaping. In Findings of the Association for Computational Linguistics: ACL 2026, pages 7510– 7525. Association for Computational Linguistics, 2026. doi: 10.18653/v1/2026.findings-acl.370. URL https://aclanthology.org/2026.findings-acl.370/. [11]Lang Feng, Zhenghai Xue, Tingcong Liu, and Bo An. Group-in-group policy optimization for LLM agent training. In Advances in Neural Information Processing Systems 38 (NeurIPS 2025), 2025. URL https://openreview.net/forum?id=QXEhBMNrCW. [12]Haoyang Hong, Jiajun Yin, Yuan Wang, Jingnan Liu, Zhe Chen, Ailing Yu, Ji Li, Zhiling Ye, Hansong Xiao, Yefei Chen, Hualei Zhou, Yun Yue, Minghui Yang, Chunxiao Guo, Junwei Liu, Peng Wei, and Jinjie Gu. Multi-agent deep research: Training multi-agent systems with M-GRPO, 2025. URL https://arxiv.org/abs/2511.13288. 11 [13]Mengkang Hu, Tianxing Chen, Qiguang Chen, Yao Mu, Wenqi Shao, and Ping Luo. Hi- Agent: Hierarchical working memory management for solving long-horizon agent tasks with large language model. In Proceedings of the 63rd Annual Meeting of the Associa- tion for Computational Linguistics (Volume 1: Long Papers), pages 32779–32798. Asso- ciation for Computational Linguistics, 2025. doi: 10.18653/v1/2025.acl-long.1575. URL https://aclanthology.org/2025.acl-long.1575/. [14]Yusong Hu, Runmin Ma, Yue Fan, Jinxin Shi, Zongsheng Cao, Yuhao Zhou, Jiakang Yuan, Shuaiyu Zhang, Shiyang Feng, Xiangchao Yan, Shufei Zhang, Wenlong Zhang, Lei Bai, and Bo Zhang. FlowSearch: Advancing deep research with dynamic structured knowledge flow. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 21212–21245. Association for Computational Linguistics, 2026. doi: 10.18653/v1/2026.acl-long.971. URLhttps://aclanthology.org/2026.acl- long.971/. [15]Yuxiang Ji, Ziyu Ma, Yong Wang, Guanhua Chen, Xiangxiang Chu, and Liaoni Wu. Tree search for LLM agent reinforcement learning. In The Fourteenth International Conference on Learning Representations, 2026. URLhttps://openreview.net/forum?id=ZpQwAFhU13. [16]Minki Kang, Wei-Ning Chen, Dongge Han, Huseyin A. Inan, Lukas Wutschitz, Yanzhi Chen, Robert Sim, and Saravan Rajmohan. ACON: Optimizing context compression for long-horizon LLM agents. In Proceedings of the 43rd International Conference on Machine Learning, volume 306 of Proceedings of Machine Learning Research. PMLR, 2026. URLhttps: //proceedings.mlr.press/v306/kang26b.html. [17] Sehoon Kim, Suhong Moon, Ryan Tabrizi, Nicholas Lee, Michael W. Mahoney, Kurt Keutzer, and Amir Gholami. An LLM compiler for parallel function calling. In Proceedings of the 41st International Conference on Machine Learning, volume 235 of Proceedings of Machine Learning Research, pages 24370–24391. PMLR, 2024. URLhttps://proceedings.mlr. press/v235/kim24y.html. [18] J. Richard Landis and Gary G. Koch. The measurement of observer agreement for categorical data. Biometrics, 33(1):159–174, 1977. doi: 10.2307/2529310. URLhttps://w.jstor. org/stable/2529310. [19]Yunfan Li, Bingbing Xu, Xueyun Tian, Xiucheng Xu, and Huawei Shen. Beyond entangled planning: Task-decoupled planning for long-horizon agents, 2026. URLhttps://arxiv. org/abs/2601.07577. [20] Zhongyi Li, Wan Tian, Jinju Chen, Huiming Zhang, Yang Liu, Yikun Ban, and Fuzhen Zhuang. Counterfactual credit policy optimization for multi-agent collaboration, 2026. URLhttps: //arxiv.org/abs/2603.21563. [21] Zijian Li, Xin Guan, Bo Zhang, Shen Huang, Houquan Zhou, Shaopeng Lai, Ming Yan, Yong Jiang, Pengjun Xie, Fei Huang, Jun Zhang, and Jingren Zhou. WebWeaver: Structuring web-scale evidence with dynamic outlines for open-ended deep research. In The Fourteenth International Conference on Learning Representations, 2026. URLhttps://openreview. net/forum?id=MtNCJjlrKt. [22]Miao Lu, Weiwei Sun, Weihua Du, Zhan Ling, Xuesong Yao, Kang Liu, and Jiecao Chen. Beyond the context window: Scaling agentic RL via end-to-end optimized context compression. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 21074–21125. Association for Computational Linguistics, 2026. doi: 10.18653/v1/2026.acl-long.966. URLhttps://aclanthology.org/2026.acl- long.966/. [23]Yifu Lu, Shengjie Liu, and Li Dong. OrchDAG: Complex tool orchestration in multi-turn interactions with plan DAGs. In NeurIPS 2025 Workshop on Multi-Turn Interactions in Large Language Models, 2025. URL https://openreview.net/forum?id=uZE8mTYvHE. [24] Manus AI. Manus: Hands on AI. Official website, 2025. URL https://manus.im/. 12 [25]Metaso. Xin SOTA! rang “Shendu Yanjiu” geng shen yidiandian [New SOTA! making “Deep Research” a little deeper]. WeChat official-account post, 2025. URLhttps://mp.weixin.q. com/s/-w48s1XuIEcWg6Rd3ZGRXg. In Chinese. Post on Metaso’s official WeChat account (bylined “Metaso AI Search”), 15 July 2025, announcing the free “Deep Research” (Shendu Yanjiu) mode and reporting BrowseComp and xbench-DeepSearch results; product page at https://metaso.cn/. [26]Grégoire Mialon, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, and Thomas Scialom. GAIA: a benchmark for general AI assistants. In The Twelfth International Con- ference on Learning Representations, 2024. URLhttps://openreview.net/forum?id= fibxvahvs3. [27]Moonshot AI. Kimi-Researcher: End-to-end RL training for emerging agentic capabilities. Blog post, 2025. URL https://moonshotai.github.io/Kimi-Researcher/. [28]NVIDIA. Nemotron 3 Nano: Open, efficient mixture-of-experts hybrid Mamba-Transformer model for agentic reasoning, 2025. URL https://arxiv.org/abs/2512.20848. [29]OpenAI. Introducing deep research. OpenAI announcement, 2025. URLhttps://openai. com/index/introducing-deep-research/. [30] OpenAI. Introducing GPT-4.1 in the API. OpenAI announcement, 2025. URLhttps: //openai.com/index/gpt-4-1/. [31]OpenAI. GPT-5 system card. OpenAI, 2025. URLhttps://openai.com/index/gpt- 5-system-card/ . Also available as arXiv:2601.03267,https://arxiv.org/abs/2601. 03267. [32]Xianghe Pang, Shuo Tang, Rui Ye, Yuwen Du, Yaxin Du, and Siheng Chen. BrowseMaster: Towards scalable web browsing via tool-augmented programmatic agent pair. In NeurIPS 2025 Workshop on Scaling Environments for Agents, 2025. URLhttps://openreview.net/ forum?id=MYIkHcP10t. [33]Tianrui Qin, Qianben Chen, Sinuo Wang, Xinyu Yang, Kang Zhu, He Zhu, Dingfeng Shi, Xinxin Liu, Ge Zhang, Jiaheng Liu, Xitong Gao, Yuchen Eleanor Jiang, and Wangchunshu Zhou. Flash-searcher: Fast and effective web agents via DAG-based parallel execution. In The Fourteenth International Conference on Learning Representations, 2026. URLhttps: //openreview.net/forum?id=QuaJ6kJaBm. [34] Jiahao Qiu, Xuan Qi, Tongcheng Zhang, Xinzhe Juan, Jiacheng Guo, Yifu Lu, Yimin Wang, Zixin Yao, Qihan Ren, Xun Jiang, Xing Zhou, Dongrui Liu, Ling Yang, Yue Wu, Kaixuan Huang, Shilong Liu, Hongru Wang, and Mengdi Wang. Alita: Generalist agent enabling scalable agentic reasoning with minimal predefinition and maximal self-evolution, 2025. URL https://arxiv.org/abs/2505.20286. [35]Jiaqi Shao, Yufeng Miao, Wei Zhang, and Bing Luo. FoldAct: Efficient and stable context folding for long-horizon search agents, 2025. URL https://arxiv.org/abs/2512.22733. [36]Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Xiao Bi, Haowei Zhang, Mingchuan Zhang, Y. K. Li, Y. Wu, and Daya Guo. DeepSeekMath: Pushing the limits of mathematical reasoning in open language models, 2024. URLhttps://arxiv.org/abs/ 2402.03300. [37]Skywork AI. DeepResearchAgent. GitHub repository, 2025. URLhttps://github.com/ SkyworkAI/DeepResearchAgent. Open-source deep research agent framework behind Sky- work Super Agents, launched 22 May 2025. [38]Weiwei Sun, Miao Lu, Zhan Ling, Kang Liu, Xuesong Yao, Yiming Yang, and Jiecao Chen. Scal- ing long-horizon agent via Context Folding. In Proceedings of the 43rd International Conference on Machine Learning, volume 306 of Proceedings of Machine Learning Research, pages 116894– 116910. PMLR, 2026. URL https://proceedings.mlr.press/v306/sun26x.html. 13 [39]Prakhar Verma, Sukruta Prakash Midigeshi, Gaurav Sinha, Arno Solin, Nagarajan Natarajan, and Amit Sharma. Plan ∗ RAG: Efficient test-time planning for retrieval augmented generation. In ICLR 2025 Workshop on Reasoning and Planning for Large Language Models, 2025. URL https://openreview.net/forum?id=gi9aqlYdBk. [40]Jason Wei, Zhiqing Sun, Spencer Papay, Scott McKinney, Jeffrey Han, Isa Fulford, Hyung Won Chung, Alex Tachard Passos, William Fedus, and Amelia Glaese. BrowseComp: A simple yet challenging benchmark for browsing agents, 2025. URLhttps://arxiv.org/abs/2504. 12516. [41]Quan Wei, Siliang Zeng, Chenliang Li, William Brown, Oana Frunza, Wei Deng, Yuriy Nevmyvaka, Yang Katie Zhao, Alfredo Garcia, and Mingyi Hong.Reinforcing multi- turn reasoning in LLM agents via turn-level reward design and credit assignment.In NeurIPS 2025 Workshop on Multi-Turn Interactions in Large Language Models, 2025. URL https://openreview.net/forum?id=drP7qVUnUt. [42]Ryan Wong, Jiawei Wang, Junjie Zhao, Li Chen, Yan Gao, Long Zhang, Xuan Zhou, Zuo Wang, Kai Xiang, Ge Zhang, Wenhao Huang, Yang Wang, and Ke Wang. WideSearch: Benchmarking agentic broad info-seeking. In The Fourteenth International Conference on Learning Representations, 2026. URLhttps://openreview.net/forum?id=Q7YUY7zGkZ. [43]Jiaqi Wu, Qinlao Zhao, Zefeng Chen, Kai Qin, Yifei Zhao, Xueqian Wang, and Yuhang Yao. GAP: Graph-based agent planning with parallel tool use and reinforcement learning. In NeurIPS 2025 Workshop on Knowledge Graphs & Agentic Systems Interplay (NORA), 2025. URL https://openreview.net/forum?id=7bJIVHEvLm. [44] Xixi Wu, Kuan Li, Yida Zhao, Liwen Zhang, Litu Ou, Huifeng Yin, Zhongwang Zhang, Xinmiao Yu, Dingchu Zhang, Yong Jiang, Pengjun Xie, Fei Huang, Minhao Cheng, Shuai Wang, Hong Cheng, and Jingren Zhou. Resum: Unlocking long-horizon search intelligence via context summarization, 2025. URL https://arxiv.org/abs/2509.13313. [45]xbench. xbench-DeepSearch. Hugging Face dataset card, 2025. URLhttps://huggingface. co/datasets/xbench/DeepSearch. Dataset card for the 2505 release of xbench-DeepSearch; a later release is published as xbench/DeepSearch-2510. Companion repository athttps: //github.com/xbench-ai/xbench-evals. [46]An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, Chujie Zheng, Dayiheng Liu, Fan Zhou, Fei Huang, Feng Hu, Hao Ge, Haoran Wei, Huan Lin, Jialong Tang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jing Zhou, Jingren Zhou, Junyang Lin, Kai Dang, Keqin Bao, Kexin Yang, Le Yu, Lianghao Deng, Mei Li, Mingfeng Xue, Mingze Li, Pei Zhang, Peng Wang, Qin Zhu, Rui Men, Ruize Gao, Shixuan Liu, Shuang Luo, Tianhao Li, Tianyi Tang, Wenbiao Yin, Xingzhang Ren, Xinyu Wang, Xinyu Zhang, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yinger Zhang, Yu Wan, Yuqiong Liu, Zekun Wang, Zeyu Cui, Zhenru Zhang, Zhipeng Zhou, and Zihan Qiu. Qwen3 technical report, 2025. URL https://arxiv.org/abs/2505.09388. [47] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In The Eleventh International Conference on Learning Representations, 2023. URLhttps://openreview. net/forum?id=WE_vluYUL-X. [48] Rui Ye, Zhongwang Zhang, Kuan Li, Huifeng Yin, Zhengwei Tao, Yida Zhao, Liangcai Su, Liwen Zhang, Zile Qiao, Xinyu Wang, Pengjun Xie, Fei Huang, Jingren Zhou, Siheng Chen, and Yong Jiang. AgentFold: Long-horizon web agents with proactive context folding. In The Fourteenth International Conference on Learning Representations, 2026. URLhttps: //openreview.net/forum?id=IuZoTgsUws. [49] Qiying Yu, Zheng Zhang, Ruofei Zhu, Yufeng Yuan, Xiaochen Zuo, Yu Yue, Weinan Dai, Tiantian Fan, Gaohong Liu, Juncai Liu, Lingjun Liu, Xin Liu, Haibin Lin, Zhiqi Lin, Bole Ma, Guangming Sheng, Yuxuan Tong, Chi Zhang, Mofan Zhang, Ru Zhang, Wang Zhang, Hang Zhu, Jinhua Zhu, Jiaze Chen, Jiangjie Chen, Chengyi Wang, Hongli Yu, Yuxuan Song, Xiangpeng Wei, Hao Zhou, Jingjing Liu, Wei-Ying Ma, Ya-Qin Zhang, Lin Yan, Yonghui 14 Wu, and Mingxuan Wang. DAPO: An open-source LLM reinforcement learning system at scale. In Advances in Neural Information Processing Systems 38 (NeurIPS 2025), 2025. URL https://openreview.net/forum?id=2a36EMSSTp. [50]Aohan Zeng, Xin Lv, Qinkai Zheng, Zhenyu Hou, Bin Chen, Chengxing Xie, et al. GLM-4.5: Agentic, reasoning, and coding (ARC) foundation models, 2025. URLhttps://arxiv.org/ abs/2508.06471. [51]Shu Zhao, Tan Yu, Anbang Xu, Japinder Singh, Aaditya Shukla, and Rama Akkiraju. Par- allelSearch: Train your LLMs to decompose query and search sub-queries in parallel with reinforcement learning, 2025. URL https://arxiv.org/abs/2508.09303. [52] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, and Ion Stoica. Judging LLM-as-a-judge with MT-Bench and chatbot arena. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023) Datasets and Benchmarks Track, 2023. URL https://openreview.net/forum?id=uccHPGDlao. [53]Zhipu AI Team. GLM-4-32B-0414. Hugging Face model card, 2025. URLhttps:// huggingface.co/zai-org/GLM-4-32B-0414. Companion repository athttps://github. com/zai-org/GLM-4. [54] He Zhu, Tianrui Qin, King Zhu, Heyuan Huang, Yeyi Guan, Jinxiang Xia, Yi Yao, Hanhao Li, Ningning Wang, Pai Liu, Tianhao Peng, Xin Gui, Xiaowan Li, Yuhui Liu, Yuchen Eleanor Jiang, Jun Wang, Changwang Zhang, Xiangru Tang, Ge Zhang, Jian Yang, Minghao Liu, Xitong Gao, Jiaheng Liu, and Wangchunshu Zhou. OAgents: An empirical study of building effective agents. In Findings of the Association for Computational Linguistics: EMNLP 2025, pages 13354– 13369. Association for Computational Linguistics, 2025. doi: 10.18653/v1/2025.findings- emnlp.720. URL https://aclanthology.org/2025.findings-emnlp.720/. 15 Appendix Table of Contents A DAGent Algorithm16 B Design Decisions16 B.1 Evaluate-then-Grow versus Plan-then-Patch . . . . . . . . . . . . . . . . . . . . . . . . . . .16 B.2 DAGRPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 B.3 Relation to Concurrent Credit-Assignment Methods . . . . . . . . . . . . . . . . . . . . . .18 C Implementation Details18 C.1 Benchmarks, Tool Stack, and Judge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 C.2 DAGent Framework Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 C.3 Baseline Configurations and Caps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 C.4 RL Training Hyperparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 C.5 Human Agreement Study on the LLM Judge . . . . . . . . . . . . . . . . . . . . . . . . . .19 D Additional Training-Free Results20 D.1 Cross-Backbone and Frontier-Scale Details . . . . . . . . . . . . . . . . . . . . . . . . . . .20 D.2 Plan-then-Patch Variant Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 D.3 Extended Efficiency Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 D.4 Behavioral Statistics of the Evaluate-then-Grow Loop . . . . . . . . . . . . . . . . . . . . .23 E Additional RL Results24 E.1 Per-Seed Training Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 E.2 DAGRPO Training Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 E.3 Efficiency as a Byproduct of RL Training . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 F Limitations25 G Prompts26 G.1 Orchestrator System Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 G.2 ReAct Executor System Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 G.3 Recall Extraction Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 G.4 LLM Judge Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 A DAGent Algorithm Algorithm 1 summarizes the complete DAGent workflow described in §3.1. B Design Decisions This appendix explains the main design decisions of DAGent and DAGRPO and relates DAGRPO to concurrent credit-assignment methods. B.1 Evaluate-then-Grow versus Plan-then-Patch The Plan-then-Patch label refers to when a planning decision is made and how much the system knows at that moment, not to how many nodes one call produces. Flash-Searcher [33] produces its entire plan in one decomposition call before execution and then periodically updates it, removing 16 Algorithm 1 DAGent: Evaluate-then-Grow Workflow Require: TaskT , Orchestrator policy π O , ReAct Executor policy π R , maximum iterations K Ensure: Final answer ˆa 1: G ← (∅,∅)▷ Initialize empty DAG 2: for k = 1, 2,...,K do 3:(S k ,V new k )← π O (T ,G)▷ Evaluate & plan, Eq. (3) 4:Update node statuses inG according to S k 5:Add nodes V new k and dependency edges toG 6:for each v i ∈ V new k in parallel do 7: C i ← L j∈dep i D j ▷ Selective Propagation 8:(D i ,T i )← π R (p i ,C i )▷ Sub-task execution 9:Store D i ,T i in node v i 10:end for 11:if V new k contains an answer-type node then 12:break 13:end if 14: end for 15: return answer field from D t answer resolved nodes and inserting new ones. FlowSearch [14] builds its knowledge flow over several planner iterations that all complete before any node runs, and then adjusts the flow with graph transformation operations based on intermediate outcomes. In both systems a plan that covers the whole task exists before execution, and execution-time edits patch that standing plan. In DAGent every node, including the answer node, is created only after the nodes it depends on have executed and been evaluated, and no node is ever deleted or rewired, so the recorded graph is exactly the graph that ran. The first batch is the one decision made without completed nodes: it is planned from the task description alone and kept small, and Appendix D.4 reports how often a first-batch node succeeds and how often a weak one is repaired by a refine node, where a node counts as weak when it has been evaluated as Uncertain or Not Found. B.2 DAGRPO Role-separated normalization.The Orchestrator and the Executors produce different numbers of rollouts per task and operate on different reward distributions. A single shared(μ,σ)across both roles would let the more numerous Executor rewards dominate the Orchestrator gradient signal, so the group statistics in Eq. (6) are computed within each role. Multiplicative off-chain attenuation.The form ̃r (exec, off-chain) i = αR(τ )is chosen because it gives no topology signal on failed trajectories withR(τ ) = 0. Off-chain rollouts in a failed trajectory may carry useful evidence that the synthesis never integrated, and a constant subtractive penalty would push the policy away from such queries. Theαsweep in Table 3 supports this reading: removing all off-chain credit (α = 0) falls below the outcome-only GRPO baseline, so off-chain rollouts carry learning value, and α = 0.5 is the best value on every benchmark. The answer-inclusive closure as a structural proxy.S(τ )is a reachability signal read off the recorded graph without re-execution. It is a proxy for contribution rather than a causal attribution, and three properties prevent it from being exploited by inflating dependencies during training. First, nothing in the objective grows with the number of ancestors: the Orchestrator rewardR(τ ) +r proc (τ ) does not count them, and Executor advantages are centered on the group mean, so moving more rollouts on-chain only redistributes credit. If every rollout were on-chain, the objective would reduce to theα = 1.0row with regularization on in Table 3, which DAGRPO beats by 2.0 points overall. Second, every extra edge costs accuracy: the DAG is append-only, so the closure can only be enlarged by adding a dependency edge, and under Selective Propagation each such edge places an irrelevant QueryDoc into the context of the node that consumes it. Third, the training runs show the opposite trend: dependency inflation would enlarge the graph and drive the off-chain ratio toward zero, whereas Appendix E.3 shows the node count per task falling, the off-chain ratio falling but staying well above zero, and Pass@1 rising under both GRPO and DAGRPO. 17 Trajectory-level structural penalty.The scaleλ proc = 0.3keeps the penalty of a correct plan with up to three violating turns below the outcome reward, so such a plan is not ranked below a clean failure, and the capK proc = 5bounds the penalty of a heavily violating plan at1.5. Aggregating r proc at the trajectory level rather than at the token level keeps the Orchestrator gradient tied toR(τ ) and lets the group baseline absorb the across-trajectory mean of frequent violations. Apart from the requirement of parseable JSON without duplicate sub-task prompts, the constraints that the penalty enforces (§3.2) control how evidence flows rather than how a plan looks: every executed node must receive an explicit status, every weak node with attempts left must be re-examined, the final synthesis must see all evidence assigned to it, and dependencies may point only to nodes that have already run and been evaluated. Appendix D.4 reports the association between structural violations and task accuracy observed in the evaluation logs. B.3 Relation to Concurrent Credit-Assignment Methods Three concurrent methods are closest to DAGRPO. Graph-GRPO [2] optimizes the communication topology over a fixed set of agents by scoring each edge across a sampled group of topologies; in DAGent the graph is the task decomposition itself, and its nodes do not exist until the run creates them. M-GRPO [12] computes group-relative advantages separately for a main agent and its sub-agents, which is the closest analogue of our role-separated normalization, but its credit depends only on the role of a rollout, whereas ours also depends on whether the rollout feeds the answer node. CCPO [20] estimates the marginal contribution of an agent by removing it counterfactually; in a research DAG the nodes below a removed node have already consumed its QueryDoc, so the counterfactual would require re-executing that subgraph, whereasS(τ )is read off the recorded graph without re-execution. Append-only growth is what makes this signal well defined: the ancestry of a node in the final graph is the context it saw when it ran, which no longer holds once a refiner can delete or rewire nodes after they have executed, as in FlowSearch and Flash-Searcher. C Implementation Details C.1 Benchmarks, Tool Stack, and Judge Table 4 lists the evaluation set, retrieval backend, and judge prompt of each benchmark. Within a benchmark every method uses the same backend, so differences between methods come from the workflow and not from the retrieval API. Two of the three benchmarks use live Google search; BrowseComp-Plus uses local dense retrieval with Qwen3-Embedding-8B over its fixed corpus because its protocol requires it. Pass@1 is scored by GPT-4o-mini with GPT-4.1 as a tie-breaker on borderline cases (Appendix C.5); the judge prompts are listed in Appendix G. Table 4: Benchmarks and tool stack; all methods on a benchmark share its backend and judge. BrowseComp-PlusGAIAxbench-DeepSearch Tasks150103 (text-only validation)100 (2505 release) Difficulty splits50 easy / 50 medium / 50 hard39 L1 / 52 L2 / 12 L3none LanguageEnglishEnglishChinese SearchLocal dense retrievalGoogle search via SerperGoogle search via Serper Page accessVerified corpusJina extractionJina extraction Judge promptBenchmark rubricEquivalence promptBenchmark rubric (Chinese) C.2 DAGent Framework Parameters Table 5 lists the parameters of the DAGent framework. The context budget is enforced per agent context: each Orchestrator turn and each Executor sub-task runs in its own context whose prompt is capped at 8,192 tokens and whose response, including tool outputs, is capped at 32,768 tokens. This is the 32K×N budget of Table 1, which every multi-context baseline shares. The Executor timeout applies to a single sub-task; the whole task is additionally bounded by a session timeout of 5,400 s, a bound that no evaluated task reaches. 18 Table 5: DAGent framework parameters, grouped by scope. “Per context” denotes one Orchestrator turn or one Executor sub-task; “per task” denotes one benchmark query. ParameterScopeValue Prompt lengthper context8,192 tokens Response length, including tool outputsper context32,768 tokens Orchestrator iterations Kper task30 Session timeoutper task5,400 s Executor turnsper sub-task200 Executor timeout, evaluation / trainingper sub-task600 s / 1,800 s Attempts, one initial execution plus refinesper sub-task3 Search results top-kper search call10 Decoding–greedy, thinking disabled C.3 Baseline Configurations and Caps Table 6 lists the budget-related settings of the baseline workflows; the DAGent settings are those of Table 5, and the Plan-then-Patch variant shares them and adds a patch budget. Flash-Searcher keeps the 40-step cap of the authors’ release; only its summary interval is changed from 8 to 4 so that each summary fits within the 32K per-sub-task budget shared by all multi-context methods. FlowSearch runs the official question-answering preset of the released implementation with three documented changes: the model of every role is set to the evaluation backbone, the Coordinator (the execution-conditioned refiner described by Hu et al.[14]) is enabled because the preset ships with it disabled, and the tool set is restricted to the sharedsearchandopen_pagebackends; all official budgets are kept. The effective configuration is written into every result record. Table 6: Budget caps of the baseline workflows (the DAGent caps are listed in Table 5). WorkflowSettingCap ReAct AgentContext window32K or 109K tokens Summary Agent / Fold AgentSessions per task10 Flash-Searcher Action steps per task40 Summary interval4 (release default 8) FlowSearch Main iterations per task5 Planner iterations / nodes2 / 7 Parallel workers10 Sub-tasks / tool calls per node2 / 5 Correction attempts3 Task timeout2,400 s Plan-then-Patch variant Patch turns per task30 Session timeout5,400 s C.4 RL Training Hyperparameters Table 7 lists the RL training and DAGRPO hyperparameters. Training uses LoRA on all linear layers with asynchronous vLLM rollouts; unlisted settings inherit the VeRL defaults. C.5 Human Agreement Study on the LLM Judge The Pass@1 numbers in §4 are produced by GPT-4o-mini with GPT-4.1 as a tie-breaker on borderline cases, applied through three dataset-specific judge prompts: an HLE-derived rubric for BrowseComp- Plus following its protocol [7], a short equivalence prompt for GAIA that replaces the original quasi-exact-match scoring of the benchmark [26] for cross-benchmark consistency, and a Chinese- language rubric for xbench-DeepSearch [4]. None has been validated against humans in prior work, so we calibrate each judge against three annotators following Du et al.[9], Wong et al.[42], and the LLM-as-judge meta-evaluation literature [52, 3]. 19 Table 7: RL training and DAGRPO hyperparameters. ParameterValue Hardware2× H200, tensor parallel 2 LoRA rank / alpha64 / 64, all linear layers Optimizer, learning rateAdamW, 1× 10 −5 Tasks per batch, rollouts per task G32, 8 PPO mini-batch (tasks / trajectories)16 / 128 Asymmetric clip ε ℓ / ε h 0.20 / 0.28 Entropy coefficient0.001 KL-to-reference coefficient0.001 Update steps21 α, DAGRPO / GRPO baseline0.5 / 1.0 λ proc , K proc 0.3, 5 Training seeds42, 123, 777 Setup. We sample150(question, predicted answer, reference answer) tuples stratified50/50/50 across the three benchmarks, drawn proportionally from DAGent and four agent baselines so that correct and incorrect predictions appear in roughly equal share. Three volunteer annotators with reading-comprehension and information-retrieval backgrounds independently provide a forced binary judgment, blinded to the score of the LLM judge. Observation 8:Each per-benchmark Cohen’sκbetween the human-majority label and the LLM judge falls in the almost-perfect bracket, with the aggregateκ = 0.95approaching the human- noise ceiling. Table 8 reports Fleiss’κon the three-human ensemble, Cohen’sκbetween the human-majority label and the LLM judge, and raw percent agreement. All per-benchmark Cohen’sκ values fall in the almost-perfect bracket of Landis and Koch[18]; the aggregateκ = 0.95exceeds theκ = 0.19pairwise alignment of Chan et al.[3]on FairEval, and the aggregate raw agreement of 97.3%approaches the97.8to98.3%range reported by Wong et al.[42]across four GPT-4.1-class judges, the small remaining gap reflecting our weaker GPT-4o-mini primary judge. Agreement is uniformly high on the English benchmarks and slightly lower on xbench-DeepSearch, where Chinese-language tasks admit longer phrasal answers and surface-form variation. Table 8: Human agreement on the LLM judge across150(question, predicted answer, reference answer) tuples. Fleiss’κis computed on the three-human ensemble; Cohen’sκis between the human-majority label and the LLM judge; raw % is between the same pair. SubsetNFleiss’ κ (3H)Cohen’s κ (H vs J)Raw % BrowseComp-Plus500.980.9698.0 GAIA500.980.9698.0 xbench-DeepSearch500.960.9296.0 Aggregate1500.970.9597.3 D Additional Training-Free Results This appendix collects the training-free results that supplement §4.2, §4.3, and §4.4. D.1 Cross-Backbone and Frontier-Scale Details This section supplements the cross-backbone consistency check of §4.2 (Figure 3) with the per- baseline breakdown in Table 9, plus the baseline list and multi-modal extension behind the frontier- scale comparison in Figure 4. All rows share the tool stack of the main results, and the Qwen3-32B block of Table 9 reproduces the corresponding rows of Table 1; FlowSearch, evaluated at Qwen3-32B only, is not part of this spot check. Frontier-scale baselines. For the GPT-5 327K comparison in Figure 4, the BrowseComp-Plus baselines are 100B+ LLMs running ReAct at 327K context, namely Qwen3-235B-A22B, GLM- 20 4.5-Air [50], DeepSeek-V3.1 [8], GPT-4.1 [30], and GPT-5 [31], with numbers reproduced from Sun et al.[38]; the GAIA and xbench-DeepSearch baselines are agent frameworks discussed in §2.1, with numbers from Qin et al.[33]except OpenAI Deep Research and FlowSearch on GAIA, whose numbers are from Hu et al.[14]. The GAIA runners-up Flash-Searcher (GPT-5), FlowSearch (o4-mini), and Skywork DR fall within a narrow range, between 82.4 and 83.0. Multi-modal extension for the GAIA full validation set.The GPT-5 327K comparison in Figure 4 evaluates GAIA on its full165-task validation set rather than the103-task text-only subset used elsewhere, following the protocol of Qin et al.[33]. The62multi-modal questions in the full set involve attached image, audio, and document files that the text-only Orchestrator and ReAct Executor cannot process directly. Following the framework of Zhu et al.[54], we extend the tool registry with three inspector tools: an image inspector that base64-encodes attachments and queries a vision model, a document inspector that parses PDF, spreadsheet, and structured-text files for question-conditioned extraction, and an audio inspector that transcribes audio attachments before extraction. Each attached file is pre-processed into a textual description via the appropriate inspector and prepended to the question; the same inspectors remain available as agent-callable tools during execution. All other DAGent components remain unchanged, so the full-set evaluation isolates the multi-modal extension from the planning and context-management mechanisms of the framework. Table 9: Cross-backbone spot check with four mid-size open-source backbones; all training-free with the same tool stack as the main results; Pass@1 (%); best per backbone in bold. The Qwen3-32B block reproduces the corresponding rows of Table 1. BackboneVendorAgent Paradigm BrowseComp-PlusGAIAxbench-DS Easy Med. Hard Avg.L1L2L3Avg.Avg. Qwen3-32BAlibaba ReAct Agent (32K)50.016.02.022.7 46.2 28.88.333.054.0 ReAct Agent (109K) 66.024.04.031.3 51.3 36.5 16.7 39.858.0 Summary Agent80.036.00.038.7 51.3 28.8 25.0 36.955.0 Fold Agent82.040.02.041.3 56.4 38.5 16.7 42.755.0 Flash-Searcher80.034.02.038.7 56.4 40.4 25.0 44.758.0 DAGent (Ours)88.046.08.047.3 69.2 50.0 33.3 55.365.0 Seed-OSS-36BByteDance ReAct Agent (32K)64.018.00.027.3 43.6 40.48.337.958.0 ReAct Agent (109K) 88.044.02.044.7 43.6 48.1 16.7 42.762.0 Summary Agent82.040.02.041.3 48.7 51.9 25.0 47.659.0 Fold Agent88.036.08.044.0 43.6 46.2 16.7 41.760.0 Flash-Searcher88.044.04.045.3 51.3 51.9 25.0 48.567.0 DAGent (Ours)94.058.010.054.0 64.1 53.8 25.0 54.469.0 GLM-4-32BZhipu AI ReAct Agent (32K)52.016.02.023.3 41.0 25.0 25.0 31.156.0 ReAct Agent (109K) 68.024.04.032.0 48.7 32.7 25.0 37.960.0 Summary Agent82.036.02.040.0 43.6 30.8 25.0 35.057.0 Fold Agent84.040.04.042.7 51.3 36.5 25.0 40.858.0 Flash-Searcher82.034.02.039.3 53.8 38.5 25.0 42.764.0 DAGent (Ours)90.048.08.048.7 66.7 46.2 33.3 52.467.0 Nemotron-3-Nano-30B NVIDIA ReAct Agent (32K)50.018.04.024.0 43.6 25.0 25.0 32.046.0 ReAct Agent (109K) 66.026.08.033.3 51.3 36.5 25.0 40.851.0 Summary Agent80.038.02.040.0 53.8 30.8 25.0 38.848.0 Fold Agent84.040.04.042.7 56.4 38.5 25.0 43.749.0 Flash-Searcher82.038.04.041.3 59.0 40.4 25.0 45.653.0 DAGent (Ours)90.048.012.050.0 71.8 51.9 33.3 57.359.0 D.2 Plan-then-Patch Variant Details The Plan-then-Patch variant used in Table 2 and Figure 5(b) reuses the Orchestrator, ReAct Executor, backbone, tool stack, context-management components, and per-node refine budget of DAGent; only the cross-iteration planning behavior of the Orchestrator is modified. Planning and patching protocol. At iteration0the Orchestrator outputs the complete task DAG in one call, committing every search node plus exactly one answer node with full id, description, prompt, and dependency wiring before any node has executed; subsequent iterations execute the next ready batch in parallel and defer the answer node whenever any non-answer node is also ready. After each batch the Orchestrator may issue Refine operations, reusing the three-attempt mechanism 21 of DAGent on a node whose status is Uncertain or Not Found, or Add operations, introducing a new search node whose description must cite at least one already-executed node id (enforced by the structural validator through the format-warning loop). Both operations preserve the DAGent JSON schema; added nodes are automatically appended to the dependency set of the answer node so their evidence reaches final synthesis. Total patch turns are capped at30, with mean per-task patch turns of 4.2/1.8/1.4 on BrowseComp-Plus / GAIA / xbench-DeepSearch. Absolute per-task footprints. Table 10 in Appendix D.3 lists the absolute per-task footprints summarized in Figure 5(b), alongside those of Flash-Searcher and FlowSearch. Where the off-chain nodes come from. Figure 5(b) shows that the variant raises the off-chain Executor ratio from 0.25 / 0.20 / 0.18 to 0.40 / 0.30 / 0.25. Where these off-chain nodes come from follows from how the variant is built rather than from a measurement: every patch node, whether a refine or an add, is connected to the answer node automatically so that its evidence reaches the final synthesis, so patch nodes are on-chain by construction and off-chain nodes can only come from the initial plan. The extra off-chain nodes are therefore over-commitment at planning time, not a failure of the patch mechanism to prune. A smarter deletion policy would close only part of the gap: deleting a node saves compute only if the node has not yet run, and a patch policy that decides batch by batch, from evidence, what to keep, drop, or expand is Evaluate-then-Grow. The released FlowSearch implementation includes a deletion-capable refiner, and Table 10 shows that it still costs more than DAGent on every cost column. D.3 Extended Efficiency Comparison Section 4.4 compares DAGent with its Plan-then-Patch variant. This section extends the comparison to the two external Plan-then-Patch systems, Flash-Searcher and FlowSearch, and reports absolute values for external tool calls and wall-clock time, which the main text quotes only as relative differences. Setting.All four workflows use the same Qwen3-32B backbone and the same retrieval backends on every benchmark, and no method is modified beyond the configuration documented in Appendix C.3; FlowSearch runs with its Coordinator enabled. The tool calls column counts every model-driven call in the workflow, so its composition differs by method: search, open_page, and recall, plus Orchestrator plan calls for the DAGent rows, planning and summary calls for Flash-Searcher, and Planner and Coordinator calls for FlowSearch. The external tool calls column counts only search and open_page, which all four workflows use in the same way, and therefore isolates the cost of the search API. The steps column follows the parallelism-aware definition of §4.4 and does not measure latency. The tokens column is total input plus output, and the time column is the wall-clock time to finish one task. The nodes column is the final graph size and off-chain is the fraction of Executor nodes outside the answer-inclusive closure; both are defined only for the two DAGent rows. The calls / step column is the ratio of tool calls to execution steps and is reported as a parallelism measure, not as a cost. We do not impose a common per-task cost cap on the four workflows, because most workflows stop through an explicit finish call rather than by exhausting a budget (Appendix C.3 lists the caps of each workflow), and a common cap would cut the remaining runs off mid-task and turn the comparison into a completion-rate test. Observation 9: Among the systems that keep a separate context per node, DAGent is both the most accurate and the cheapest on every per-task cost column (tool calls, external calls, steps, tokens, and time); Flash-Searcher spends less because it is a single-agent system, and it is 8.6 / 10.6 / 7.0 points less accurate. The Plan-then-Patch variant differs from DAGent only in when it commits to a plan, and it makes 35 / 27 / 21% more external tool calls (82.3 / 42.0 / 35.4 against 60.8 / 33.1 / 29.2) and needs 35 / 27 / 23% more wall-clock time (731.9 / 584.6 / 466.8 s against 541.6 / 461.8 / 380.9 s). FlowSearch makes 26 / 6 / 8% more external tool calls and needs 32 / 23 / 28% more time, while staying 4.0 / 3.8 / 2.0 points below DAGent. A pre-committed plan contains branches that later turn out not to be needed, and the system still has to execute them; when the graph grows only after evidence arrives, those branches are never created. Executing them is what accounts for the extra search calls and wall-clock time of the two pre-committed workflows. Flash-Searcher is the one workflow that costs less than DAGent, and the reason is architectural rather than a property of Plan-then-Patch: it keeps a single reasoning trajectory and merges every parallel branch back into the same state, so it never holds a separate context per node. DAGent, its Plan-then-Patch variant, and 22 Table 10: Per-task cost of four workflows with Qwen3-32B and the same retrieval backends. Pass@1 values are from Table 1 and Table 2. Tool calls, external tool calls, execution steps, tokens, and time are per-task means; the calls / step column is the sum of tool calls divided by the sum of execution steps. BenchmarkWorkflowPass@1 Tool calls External calls Steps Calls / step Tokens (M) Time (s) Nodes Off-chain BrowseComp-Plus DAGent (Full)47.367.660.842.71.581.20541.611.80.25 Plan-then-Patch variant42.087.982.354.81.601.68731.917.60.40 Flash-Searcher38.751.342.135.81.430.91388.7– FlowSearch43.383.576.747.61.751.57714.5– GAIA DAGent (Full)55.336.833.131.21.180.66461.85.40.20 Plan-then-Patch variant50.545.342.037.61.200.85584.67.30.30 Flash-Searcher44.728.721.823.51.220.48301.9– FlowSearch51.540.435.132.81.230.74567.7– xbench-DeepSearch DAGent (Full)65.032.929.226.81.230.44380.94.90.18 Plan-then-Patch variant61.038.235.432.41.180.52466.86.20.25 Flash-Searcher58.024.618.920.21.220.30241.6– FlowSearch63.036.731.629.61.240.55488.9– FlowSearch are multi-agent systems that keep one context per node, which accounts for the additional tokens and calls and is also what lets a DAG operate over long horizons. Lower cost only matters at comparable accuracy, and no workflow in Table 10 matches the accuracy of DAGent at any cost level. Overall accuracy of the Plan-then-Patch systems. Averaged over the three benchmarks, FlowSearch reaches 52.6, the Plan-then-Patch variant 51.2, and Flash-Searcher 47.1, against 55.9 for DAGent. The variant, which keeps the full DAGent component stack, therefore scores between the two released Plan-then-Patch systems rather than below both, so Table 2 does not compare Evaluate- then-Grow against a weakened Plan-then-Patch system, and the released FlowSearch implementation, whose refiner can also delete nodes, is the strongest non-DAGent system in the Qwen3-32B block of Table 1 while still costing more than DAGent on every cost column. D.4 Behavioral Statistics of the Evaluate-then-Grow Loop Figure 6 summarizes statistics computed from the logs of the Qwen3-32B training-free runs reported in the main text: how the statuses that the Orchestrator evaluation assigns are distributed over all executed nodes and over first-batch nodes, and how often the Executor calls RECALLTOOL. 020406080100 Share of nodes (%) BrowseComp-Plus GAIA xbench-DeepSearch First batch (all) 45.7 68.4 66.4 61.9 41.6 26.4 28.8 34.9 12.7 5.2 4.8 3.2 (a) Orchestrator evaluation SuccessUncertainNot Found BrowseComp-PlusGAIAxbench-DeepSearch 0.0 0.1 0.2 0.3 0.4 Calls per task 0.33 0.21 0.18 (b) RecallTool usage Calls per taskTasks with a recall call (%) 0 5 10 15 20 25 30 Tasks with a recall call (%) 22.0 13.6 11.0 Figure 6: Behavioral statistics of the Qwen3-32B training-free runs. (a) Distribution of the Orchestra- tor evaluation outcomes over all executed nodes per benchmark and over first-batch nodes pooled across the three benchmarks. (b) RECALLTOOL usage: mean number of calls per task and share of tasks that make at least one call, per benchmark. Observation 10:Inconclusive evaluations are a routine planning input rather than an exception, and recall stays a fallback: Uncertain and Not Found account for 54.3% of the executed nodes on BrowseComp-Plus and about a third on GAIA and xbench-DeepSearch, while 22.0 / 13.6 / 11.0% of tasks make at least one recall call. 23 RECALLTOOL usage.The Executor calls RECALLTOOL (Eq.(4)) asrecall(node_id, goal). The extractor reads the full InteractionTranscript of the named dependency and returns what the goal asks for; it may use only that transcript, must attach a document id, URL, or exact quote to every claim, and must state explicitly when nothing relevant is present (prompt in Appendix G). The tool is a fallback rather than a default channel: the mean number of calls per task is 0.33 / 0.21 / 0.18 on BrowseComp-Plus / GAIA / xbench-DeepSearch, and 22.0% / 13.6% / 11.0% of tasks make at least one call (Figure 6b). The w/o InteractionTranscript row of Table 2 is the corresponding ablation, since removing the transcript disables recall, and it costs 4.0 / 2.9 / 2.0 Pass@1 points; given the usage rates, the tool changes the outcome of roughly one in five of the tasks that call it. Evaluation outcomes and the first batch. Across all executed nodes, the Orchestrator evaluates 41.6% / 12.7% of nodes as Uncertain / Not Found on BrowseComp-Plus, 26.4% / 5.2% on GAIA, and 28.8% / 4.8% on xbench-DeepSearch (Figure 6a). The Orchestrator reads these outcomes to decide the next expansion, so negative and inconclusive evidence is a routine planning input rather than discarded work. First-batch nodes are planned from the task description alone (Appendix B.1) and are evaluated as Success / Uncertain / Not Found in 61.9% / 34.9% / 3.2% of cases, so a first node that finds nothing relevant at all is rare. The validator forces a refine node for every weak first node in the same turn; these refinements turn 44.4% of weak first nodes into Success, and the remainder reach the next expansion as an explicit uncertainty rather than as silently accepted evidence. Structural violations and accuracy. The structural compliance regularization of DAGRPO pe- nalizes Orchestrator turns that violate the constraints of §3.2. Removing the term costs 1.6 / 1.0 / 0.7 Pass@1 points (Table 3), and Appendix E.2 shows that it drives the format-warning rate of the Orchestrator down faster than the outcome-only baseline. The association is also visible in the evaluation logs: tasks whose trajectory contains at least one structural violation score 14.7 points lower than tasks with none (43.6 against 58.3). Task difficulty may contribute to both, so we read this as an association consistent with the mechanism rather than as a causal estimate. E Additional RL Results This appendix collects the RL results that supplement the training-based rows of Table 1. E.1 Per-Seed Training Results Three independent training seeds (42,123,777) are run for each of the six RL-trained variants in the Qwen3-8B block of Table 1 with all other hyperparameters held fixed; the seed enters through both the dataloader shuffle and the LoRA initialization. Figure 7 reports the per-seed Pass@1 (%) values of these variants, one panel per benchmark. Observation 11:The RL gains of DAGent are robust across training seeds, with standard deviations below1.6absolute points and no single seed reversing the DAGRPO-versus-GRPO ranking. Standard deviations of the two RL rows of DAGent in the Qwen3-8B block of Table 1 stay below 1.6across all three benchmarks, and the per-seed values in Figure 7 show that no single seed alone reverses the DAGRPO-versus-GRPO ranking on any benchmark. ReAct (32K) + GRPO ReAct (109K) + GRPO Summary + GRPO Fold + GRPO DAGent + GRPO DAGent + DAGRPO 25 30 35 40 45 50 55 Pass@1 (%) 31.3 37.3 40.0 41.3 46.7 49.3 28.7 32.7 36.0 42.7 44.7 48.7 32.0 34.0 38.0 40.0 46.7 50.7 BrowseComp-Plus ReAct (32K) + GRPO ReAct (109K) + GRPO Summary + GRPO Fold + GRPO DAGent + GRPO DAGent + DAGRPO 25 30 35 40 45 50 55 Pass@1 (%) 29.1 36.9 39.8 40.8 51.5 54.4 35.0 38.8 39.8 35.9 51.5 53.4 32.0 35.0 36.9 39.8 49.5 52.4 GAIA ReAct (32K) + GRPO ReAct (109K) + GRPO Summary + GRPO Fold + GRPO DAGent + GRPO DAGent + DAGRPO 35 40 45 50 55 60 65 70 Pass@1 (%) 44.0 46.0 56.0 59.0 62.0 64.0 40.0 50.0 59.0 53.0 64.0 67.0 45.0 48.0 56.056.0 63.0 66.0 xbench-DeepSearch Seed 42Seed 123Seed 777 Figure 7: Per-seed Pass@1 (%) for the six RL-trained variants in the Qwen3-8B block of Table 1, broken out by training seed (42 / 123 / 777) on BrowseComp-Plus, GAIA, and xbench-DeepSearch. 24 E.2 DAGRPO Training Dynamics Figure 8 traces four training-time metrics that distinguish DAGRPO from GRPO; panels (b) to (d) are computed on the sampled training rollouts of each step, so their levels differ from the evaluation-time values of Table 11, which are measured on the evaluation set with greedy decoding. Observation 12:Both DAGRPO signals act as designed during training: the topology-conditioned credit separates the on-chain and off-chain Executor rewards by construction, which theα = 1.0 baseline never does, and the compliance regularization lowers the Orchestrator format-warning rate faster than outcome-only GRPO. Panel (b) shows the topology credit atα = 0.5separating on-chain and off-chain Executor reward by construction, while theα = 1.0baseline shows zero gap. Panel (c) shows the compliance regularization driving the Orchestrator format-warning rate down faster than the outcome-only baseline. Panels (a) and (d) report validation Pass@1 and on-chain-ratio progression over training, included for completeness of the training record. 071421 Training step 40 42 44 46 48 50 BrowseComp-Plus Pass@1 (%) training-free (40.0) 49.6 46.0 (a) Validation Pass@1 071421 Training step 0.00 0.05 0.10 0.15 ̄ r on-chain − ̄ r off-chain (b) Topology-conditioned credit 071421 Training step 0.4 0.5 0.6 0.7 0.8 0.9 Orchestrator format-warning rate (c) Compliance regularization 071421 Training step 0.55 0.60 0.65 0.70 0.75 0.80 On-chain Executor nodes / all Executor nodes (d) On-chain ratio DAGent + DAGRPO (α = 0.5, regularization on)DAGent + GRPO (α = 1.0, regularization off) Figure 8: DAGRPO training dynamics on Qwen3-8B with LoRA. (a) BrowseComp-Plus validation Pass@1 over training steps, averaged over the three training seeds, so that the end points equal the Qwen3-8B means of Table 1. (b) Per-step training-time reward gap ̄r chain − ̄r off -chain ; theα = 0.5 topology credit separates the two groups, whileα = 1.0gives zero gap by construction. (c) Per-step Orchestrator format-warning rate from the structural validator. (d) Per-step on-chain ratio, the fraction of Executor nodes inside the answer-inclusive closure. E.3 Efficiency as a Byproduct of RL Training We did not design DAGRPO for efficiency: neither the topology-conditioned credit nor the structural compliance regularization targets per-task footprint. Yet across the three benchmarks we observe consistent reductions on every footprint metric, reported here as a byproduct of accuracy-driven RL training averaged over three independent training seeds. Observation 13:RL training reduces the per-task footprint of DAGent without any explicit ef- ficiency design, and DAGRPO reduces it further than role-separated GRPO. Role-separated outcome-only GRPO (the GRPO-DAGent row of Table 1) yields step reductions of8to12%, tool- call reductions of6to9%, and token reductions of15to16%across BrowseComp-Plus / GAIA / xbench-DeepSearch (Table 11); the two structural signals of DAGRPO raise these to12to17%,10to 14%, and17to21%, in line with reductions reported across step-grouped [11] and DAG-structured [23,43] RL agent variants. Structural metrics decrease in parallel: the graph node count drops by 0.7to0.9nodes per task under GRPO and by1.3to1.9under DAGRPO, and the off-chain Executor ratio decreases by0.02to0.04under GRPO and by0.05to0.09under DAGRPO. The additional reduction under DAGRPO is spread evenly over steps, tool calls, and tokens, between 2 and 5 points of the training-free value each, and is largest for the off-chain ratio, consistent with the pressure of the topology-conditioned credit on answer-chain focus. F Limitations DAGent is text-native. The multi-modal extension used for the full GAIA validation set (Ap- pendix D.1) converts attachments into text before planning begins; handling multi-modal evidence inside the loop would require changes to how the Orchestrator evaluates evidence and how the Executor represents its transcript, not only additional tools. DAGent also plans over the evidence that its tools return and cannot create evidence that the retriever never retrieves, so its accuracy depends 25 Table 11: Effect of RL training on the per-task efficiency of DAGent on Qwen3-8B; the RL rows are means across three independent training seeds. Pass@1 values are taken from the Qwen3-8B block of Table 1. Tokens is total input plus output; tool calls aggregate search, open_page, recall, and Orchestrator plan invocations; nodes is the final graph size; off-chain is the fraction of Executor nodes outside the answer-inclusive closure, as in Table 10. BenchmarkSettingPass@1 Tokens Tool calls Steps Nodes Off-chain BrowseComp-Plus DAGent (training-free)40.01.14M65.541.512.20.25 + RL (GRPO)46.00.96M59.636.511.30.21 + RL (DAGRPO)49.60.90M56.334.510.30.16 GAIA DAGent (training-free)46.60.62M35.529.55.30.20 + RL (GRPO)50.80.53M33.026.84.60.17 + RL (DAGRPO)53.40.51M31.625.74.00.13 xbench-DeepSearch DAGent (training-free)60.00.41M32.026.05.20.18 + RL (GRPO)63.00.35M30.123.94.50.16 + RL (DAGRPO)65.70.34M28.822.93.90.13 on search-engine, retrieval-embedding, and page-extraction quality. The answer-inclusive closure is a structural proxy for contribution rather than a causal attribution, and the association between structural compliance and accuracy that we report is correlational (Appendices B and D.4); per-node causal attribution in DAG-based multi-agent systems remains open. The three benchmarks have closed-form answers that an LLM judge can verify, so open-ended report generation is outside the evidence presented here. Finally, the RL experiments train one backbone (Qwen3-8B) with LoRA for 21 update steps over three seeds; whether the DAGRPO gains persist at larger training scales, longer schedules, or full fine-tuning is not established by this paper. G Prompts This appendix lists, verbatim, the prompts of the three DAGent roles and the three LLM judge prompts. Inside a listing, section headings are set in bold in the color of the role, and template slots that are filled at run time, such asgoal, are set in orange. The Orchestrator prompt is shown with the Overall Goal of one BrowseComp-Plus task filled in. G.1 Orchestrator System Prompt Orchestrator System Prompt You are a world-class orchestrator for deep research. You plan search tasks for a ReAct agent, evaluate its results, and iterate until the Overall Goal is answered. ## Overall Goal An individual was encouraged to use a different tool for their work during the year between the assassinations of John F. Kennedy and his brother, Senator Robert F. Kennedy. Up until 2014, they have continued to use this tool. This person first studied at a university in Africa, then in the United Kingdom, and later in the United States. They taught and held the positions of head of department and dean at the university where they studied in Africa until a year in the last decade of the 20th century. They also built a venue to showcase their own work as well as the work of other people. This venue celebrated its 25th anniversary in a year between 2015 and 2020. What is the name of this individual? ## How This System Works You manage nodes in a task graph. Your conversation history contains all previous planning turns. Each new user message only contains NEW execution results and a compact status ledger. Review your history to recall earlier node details. ## Core Responsibilities ### 1. Evaluate (output:`node_statuses`) For each node listed as "Awaiting Evaluation" in the user message, evaluate its execution result and assign status: - **Success**: information retrieved with high confidence, grounded in actual search results. - **Uncertain**: information found but verification needed (triggers refine). - **Not Found**: search executed correctly but yielded no results (triggers refine). 26 Every id listed under "Nodes to evaluate this turn" MUST appear in `node_statuses`. Do NOT include nodes that already have a status. ### 2. Plan (output:`nodes`) Plan nodes that can be executed immediately. Each node has `id`, `description`, `prompt`, `dependencies`. **id** (encodes task type): - Search: `t1`, `t2`, `t3`, ... - Refine: `<parent>_refine1` or `<parent>_refine2` (id MUST end in `_refineN`) - Answer: `t_answer` (id MUST end in exactly `_answer`) **description**: must be detailed and **self-contained**. Include all necessary context. **prompt**: provide detailed instructions for the ReAct agent. Synthesize relevant findings from dependency nodes as context bridge, and add operational value such as search strategies, angles to try, and prior results to avoid. Formulate **complete natural language sentences** (NOT keywords) for the ReAct agent. Our retrieval uses embedding model - full sentences work much better. Preserve rare verbatim phrases from the Overall Goal exactly. **dependencies**: list ALL nodes whose content is needed. All dependencies must already be evaluated (not Awaiting Evaluation, not in the same batch). **IMPORTANT**: the ReAct agent can ONLY see the description, prompt, and content from dependency nodes. It CANNOT see the Overall Goal or full graph state. Use these three fields together to give it everything it needs. **Granularity Rule**: task granularity depends on the purpose: - **Finding candidates**: first, resolve any conditions that contain indirect references (references to events, abstract categories that need resolution into specific entity names) into concrete facts via search. If a lookup returns multiple plausible values, try each value in separate candidate-discovery searches. Then, substitute resolved facts into the remaining conditions and combine 2-3 distinctive conditions per node to narrow down candidates. Plan MULTIPLE candidate-discovery nodes in the SAME turn with DIFFERENT condition combinations. Do NOT put all conditions in one node (retrieval degrades with too many conditions). After gathering candidates, proceed to check them. - **Checking specific conditions**: each node should target ONE condition for ONE candidate. - **Fallback**: if all candidates fail critical conditions, return to finding candidates with DIFFERENT search angles. If candidate discovery keeps failing, the resolved facts themselves may be wrong. Re-do those lookups with different angles. **Parallelism Rule**: you can include MULTIPLE nodes per plan. - When finding candidates, plan MULTIPLE search nodes in parallel to explore DIFFERENT combinations. - When checking conditions for one candidate, plan ALL unchecked conditions in parallel. - Dependency constraint: parallel nodes can only be planned if all their dependencies have already been evaluated. **Refine Rule**: - If status is Uncertain or Not Found AND the line still has refine budget, you MUST plan a refine node (`<parent>_refine1`, or `<parent>_refine2` for a second refine) with a DIFFERENT search strategy. The refine prompt MUST copy ALL prior search queries from the entire refine chain verbatim (the original node's `key_steps` plus any earlier refine's `key_steps`) and specify new angles. - **3-attempt limit**: original search + refine1 + refine2. After 3 attempts, the line is exhausted. Accept that gap and move forward. **Answer Rule**: - Plan a single answer node when: (1) evidence is sufficient AND a concrete candidate exists, OR (2) all search lines are exhausted AND a best-effort answer is available. If a `[CONTEXT WARNING]` has been injected, begin the termination path: verify the answer's required form if needed, then plan the answer node. - Finding candidates is NOT enough. You MUST go through the checking-conditions phase first. - You MUST have a concrete candidate. The question is guaranteed to have an answer. Responses like "No such X exists" or "Insufficient information" are WRONG. Compare candidates by how many conditions each satisfies and pick the best-supported one. - Before the answer node, try to ensure all necessary information about the selected candidate has been gathered by upstream nodes. If the Overall Goal requires a specific form or granularity, ideally an upstream node should have already retrieved it. If not, the answer node can perform targeted searches to fill in missing details. - The answer node MUST be planned ALONE, NEVER in the same batch with search or refine nodes. Set its prompt to list accumulated evidence and instruct the ReAct agent to verify any details still needed for the answer's required form, then call `finish`. ## Output Format Structure your response in TWO parts. ### Part 1: Thinking You MUST answer EACH question below step by step. Do NOT include any JSON in this section. **Step 1: Evaluate** - What status (Success / Uncertain / Not Found) should I assign to each Awaiting Evaluation node? 27 Is the answer grounded in actual search results, or guessed from prior knowledge? - Have I covered every id listed in "Nodes to evaluate this turn", and no others? **Step 2: Plan** - What phase am I in? - Finding candidates: are there conditions with indirect references that need factual lookup first? What condition combinations should I try? Am I planning MULTIPLE nodes with DIFFERENT combinations? - Checking conditions: am I targeting ONE condition per node? Am I planning ALL unchecked conditions in parallel? - Fallback: are all candidates failing? Could the resolved facts be wrong? - Need refine? Any Uncertain or Not Found nodes with refine budget left? Have I copied ALL prior queries from the entire refine chain verbatim and specified new angles? - Ready to answer? Have I gone through the checking-conditions phase? Do I have a concrete candidate? Have I compared candidates by condition coverage and picked the best-supported one? Does the answer satisfy the form or granularity requirement? If the required form hasn't been retrieved by an upstream node, does the answer node's prompt include instructions to look it up? Is the answer node planned ALONE? - For each new node: is the id correctly formed (search `tN`, refine `<parent>_refine1` or `_refine2`, answer `t_answer`)? Is the description self-contained? Does the prompt include context bridge and **complete natural language sentences (NOT keywords)**? Are all dependencies already evaluated and not in the same batch? Remember: the ReAct agent CANNOT see the Overall Goal. ### Part 2: JSON Plan Output a single JSON object in a ```json block. Follow this format strictly. Any deviation will cause parsing errors. - `node_statuses`: one entry for every id listed in "Nodes to evaluate this turn" (no more, no less). Empty `` only when there are no nodes to evaluate. - `nodes`: at least one new node. Each node MUST have `id` (string), `description` (string), `prompt` (string), `dependencies` (array of strings). ```json "node_statuses": "...": "Success" / "Uncertain" / "Not Found" , "nodes": [ "id": "...", "description": "...", "prompt": "...", "dependencies": [], ... ] ``` G.2 ReAct Executor System Prompt ReAct Executor System Prompt You are a meticulous and strategic research agent. Your primary function is to conduct comprehensive, multi-step research to deliver a thorough, accurate, and well-supported report in response to the user's query. Your operation is guided by these core principles: * **Rigor:** Execute every step of the research process with precision and attention to detail. * **Objectivity:** Synthesize information based on the evidence gathered, not on prior assumptions. Note and investigate conflicting information. * **Thoroughness:** Never settle for a surface-level answer. Always strive to uncover the underlying details, context, and data. * **Transparency:** Your reasoning process should be clear at every step, linking evidence from your research directly to your conclusions. Follow this structured protocol to find the answer ### Phase 1: Deconstruction & Strategy 1. **Deconstruct the Query:** * Analyze the user's prompt to identify the core question(s). * Isolate key entities, concepts, and the relationships between them. * Explicitly list all constraints, conditions, and required data points (e.g., dates, quantities, specific names). 2. **Hypothesize & Brainstorm:** * Based on your knowledge, brainstorm potential search vectors, keywords, synonyms, and related topics that could yield relevant information. * Consider multiple angles of inquiry to approach the problem. 3. **Verification Checklist:** * Create a **Verification Checklist** based on the query's constraints and required data points. This checklist will be your guide throughout the process and used for final verification. ### Phase 2: Iterative Research & Discovery 28 **Tool Usage:** * **Tools:** * `search`: Use for broad discovery of sources and to get initial snippets. * `open_page`: **Mandatory follow-up** for any promising `search` result. Snippets are insufficient; you must analyze the full context of the source document. * **Query Strategy:** * Start with moderately broad queries to map the information landscape. Narrow your focus as you learn more. * Do not repeat the exact same query. If a query fails, rephrase it or change your angle of attack. * Execute a **minimum of 5 tool calls** for simple queries and up to **50 tool calls** for complex ones. Do not terminate prematurely. * **Post-Action Analysis:** After every tool call, briefly summarize the key findings from the result, extract relevant facts, and explicitly state how this new information affects your next step in the OODA loop. * **<IMPORTANT>Never simulate tool call output</IMPORTANT>** You will execute your research plan using an iterative OODA loop (Observe, Orient, Decide, Act). 1. **Observe:** Review all gathered information. Identify what is known and, more importantly, what knowledge gaps remain according to your research plan. 2. **Orient:** Analyze the situation. Is the current line of inquiry effective? Are there new, more promising avenues? Refine your understanding of the topic based on the search results so far. 3. **Decide:** Choose the single most effective next action. This could be a broader query to establish context, a highly specific query to find a key data point, or opening a promising URL. 4. **Act:** Execute the chosen action using the available tools. After the action, return to **Observe**. ### Phase 3: Synthesis & Analysis * **Continuous Synthesis:** Throughout the research process, continuously integrate new information with existing knowledge. Build a coherent narrative and understanding of the topic. * **Triangulate Critical Data:** For any crucial fact, number, date, or claim, you must seek to verify it across at least two independent, reliable sources. Note any discrepancies. * **Handle Dead Ends:** If you are blocked, do not give up. Broaden your search scope, try alternative keywords, or research related contextual information to uncover new leads. Assume a discoverable answer exists and exhaust all reasonable avenues. * **Maintain a "Fact Sheet":** Internally, keep a running list of key facts, figures, dates, and their supporting sources. This will be crucial for the final report. ### Phase 4: Verification & Final Report Formulation 1. **Systematic Verification:** Before writing the final answer, halt your research and review your **Verification Checklist** created in Phase 1. For each item on the checklist, confirm you have sufficient, well-supported evidence from the documents you have opened. 2. **Mandatory Re-research:** If any checklist item is unconfirmed or the evidence is weak, it is **mandatory** to return to Phase 2 to conduct further targeted research. Do not formulate an answer based on incomplete information. 3. **Never give up**, no matter how complex the query, you will not give up until you find the corresponding information. 4. **Construct the Final Report:** * Once all checklist items are confidently verified, synthesize all gathered facts into a comprehensive and well-structured answer. * Directly answer the user's original query. * Ensure all claims, numbers, and key pieces of information in your report are clearly supported by the research you conducted. Execute this entire protocol to provide a definitive and trustworthy answer to the user. You have access to the following functions: ---- BEGIN FUNCTION #1: search ---- Description: Performs a web search: supply a string 'query' and optional 'topk'. The tool retrieves the top 'topk' results (default 10) for the query, returning their docid, url, and document content. Parameters: (1) query (string, required): The query string for the search. (2) topk (integer, optional): Return the top k pages. ---- END FUNCTION #1 ---- ---- BEGIN FUNCTION #2: open_page ---- Description: Open a page by docid or URL and return the complete content. Parameters: (1) docid (string, optional): Document ID from search results. (2) url (string, optional): URL from search results. ---- END FUNCTION #2 ---- ---- BEGIN FUNCTION #3: recall ---- Description: Deep retrieval from a previous task node's original transcript. Use when upstream context summary is insufficient. Parameters: 29 (1) node_id (string, required): The ID of the node to recall from (e.g., "t1", "t2"). (2) goal (string, required): What specific information you need. ---- END FUNCTION #3 ---- ---- BEGIN FUNCTION #4: finish ---- Description: Return the final result with structured output including answer, explanation, key steps, confidence, and uncertainties. Parameters: (1) answer (string, required): DIRECT answer only. Do NOT include explanations here. (2) explanation (string, required): Brief explanation with [docid] citations. (3) key_steps (string, required): Key research steps taken, separated by semicolons. (4) confidence (string, required): Confidence score between 0% and 100%. (5) uncertainties (string, required): Unresolved questions or single-source facts, separated by semicolons. ---- END FUNCTION #4 ---- If you choose to call a function ONLY reply in the following format with NO suffix: <function=example_function_name> <parameter=example_parameter_1>value_1</parameter> <parameter=example_parameter_2> This is the value for the second parameter that can span multiple lines </parameter> </function> <IMPORTANT> Reminder: - Function calls MUST follow the specified format, start with <function= and end with </function> - Required parameters MUST be specified - You may provide optional reasoning for your function call in natural language BEFORE the function call, but NOT after. - If there is no function call available, answer the question like normal with your current knowledge and do not tell the user about function calls </IMPORTANT> G.3 Recall Extraction Prompt Recall Extraction Prompt You are a Data Extraction Specialist. Your job is to scan a research transcript and extract content that addresses a specific goal, STRICTLY from the transcript itself. ## Input Context **Goal** (the specific information to extract): goal **Transcript** (the raw content to extract from; this is the full execution log of a previous search task, including tool calls and tool results): transcript ## Extraction Rules 1. **Strict adherence**: extract only from the Transcript. Do not use prior knowledge. Do not infer or extrapolate facts that are not literally present in the Transcript. 2. **Citations**: every factual claim in your output MUST be backed by a source identifier from the Transcript (docid, URL, or quoted snippet). If the Transcript contains a docid for a fact, include the docid. If only a URL is present, include the URL. If neither, quote the exact passage. 3. **Relevance**: ignore content unrelated to the Goal. Do not include filler, navigation text, or general commentary from the Transcript. 4. **Negative result**: only after you have scanned the entire Transcript and found no content relevant to the Goal, explicitly state: "No relevant information found in the provided text." Do NOT use this as a shortcut when extraction is merely difficult. ## Output Format Structure your response as follows: ### 1. Summary A concise, fact-based answer to the Goal, drawn directly from the Transcript. Keep this paragraph short. Do NOT paraphrase loosely; stay close to what the Transcript actually says. ### 2. Relevant Content The exact quoted passages from the Transcript that support the Summary, each followed by its source identifier (docid / URL / position). 30 G.4 LLM Judge Prompts The BrowseComp-Plus judge follows the grader of the benchmark protocol; the GAIA judge is a short equivalence prompt that replaces the original quasi-exact-match scoring for cross-benchmark consistency (Appendix C.5); the xbench-DeepSearch judge is the Chinese-language grader prompt released with the benchmark [45], shown in its original language. All three are answered by GPT-4o- mini, with GPT-4.1 as a tie-breaker on borderline cases. LLM Judge Prompt for BrowseComp-Plus Judge whether the following [response] to [question] is correct or not based on the precise and unambiguous [correct_answer] below. [question]: question [response]: response Your judgement must be in the format and criteria specified below: extracted_final_answer: The final exact answer extracted from the [response]. Put the extracted answer as 'None' if there is no exact, final answer to extract from the response. [correct_answer]: correct_answer reasoning: Explain why the extracted_final_answer is correct or incorrect based on [correct_answer], focusing only on if there are meaningful differences between [correct_answer] and the extracted_final_answer. Do not comment on any background to the problem, do not attempt to solve the problem, do not argue for any answer different than [correct_answer], focus only on whether the answers match. correct: Answer 'yes' if extracted_final_answer matches the [correct_answer] given above, contains all the essential information from [correct_answer], is equivalent despite minor wording/order differences (such as name order, inclusion or omission of middle names/initials, common honorifics, standard shortenings of first names, inclusion/omission of non-contradictory date parts like year, minor articles like "a"/"the", extra descriptive context, non-essential descriptive prefixes/suffixes such as "Restaurant", "Inc.", "Ltd.", or sports suffixes like "FC", "CF", "SC", inclusion/omission of subtitles in titles, minor spacing/punctuation differences - including presence/absence of quotation marks, interchangeable punctuation such as ":" / "-" / "-", case-only differences, or presence/absence of diacritics), or is within a small margin of error for numerical problems. Answer 'no' only if the extracted answer is factually incorrect, missing essential identifying information, or contradicts the [correct_answer]. confidence: The extracted confidence score between 0% and 100% from [response]. Put 100 if there is no confidence score available. LLM Judge Prompt for GAIA You are an evaluation assistant. Please determine if the predicted answer is equivalent to the labeled answer. Question: question Labeled Answer: correct_answer Predicted Answer: response Did the model give an answer **equivalent** to the labeled answer? Please respond with "Correct" if they are equivalent, or "Incorrect" if they are not equivalent. Do not include any other text. LLM Judge Prompt for xbench-DeepSearch 你是一个通用人工智能助手。根据下面给出的[正确答案], 判断以下对[原问题]的[回答]的回答是否正确。 [原问题]: question [正确答案]: correct_answer [回答]:response 你的判断必须按照以下格式和标准进行: 最终答案: 从[回答]中提取出的最终准确答案。如果[回答]中没有明确的最终答案, 则填写’无’。 31 解释:根据[正确]解释为什么[最终答案]是正确的或错误的。只关注[最终答案]与[正确答案]之间是否存在实质性差异, 不要评论题目的背景, 不要尝试重新解题, 不要为任何不同于[正确答案]的答案辩护,只专注于判断答案是否一致。 结论: 如果[最终答案]与上方给出的[正确答案]一致, 或者在数值题目中处于可接受的微小误差范围内, 则填写’正确’; 否则（即存在任何不一致、歧义、不等价或提取出的答案错误的情况）填写’错误’。 32