NeurIPS2026 (task-list assignment; the cache is arXiv v1 and provides no acceptance confirmation) Multi-Agent deep research incremental planning directed acyclic graph hierarchical context structural credit assignment

DAGent: Evaluate-then-Grow Planning for Deep Research Agents¶

Conference: NeurIPS2026 (task-list assignment; the cache is arXiv v1 and provides no acceptance confirmation)
arXiv: 2609.39154
Code: https://github.com/hanwenliu6825/DAGent
Area: Multi-Agent Systems
Keywords: deep research, incremental planning, directed acyclic graph, hierarchical context, structural credit assignment

TL;DR¶

DAGent evaluates completed sub-tasks before incrementally growing a research DAG, combining hierarchical evidence propagation with DAGRPO structural rewards: training-free Qwen3-32B achieves 47.3 / 55.3 / 65.0 Pass@1 across three benchmarks, outperforming its same-architecture Plan-then-Patch variant by 5.3 / 4.8 / 4.0 percentage points.

Background & Motivation¶

Deep research requires more than retrieving information once and generating an answer: an agent must repeatedly assess whether existing leads are reliable, which evidence is missing, and where the next search should go. ReAct places actions and observations along one trajectory, whose context becomes crowded as pages and retrieval records accumulate. Summary and folding methods extend this trajectory, but do not necessarily represent dependencies among multiple research branches. DAG methods allow independent sub-tasks to run in parallel and each Executor to access only the upstream information it needs, yet graph structure alone does not guarantee that planning occurs at the right time.

Flash-Searcher and FlowSearch allow plans to change after execution, but establish a task-covering plan before any node runs. The paper calls this Plan-then-Patch: the broad commitment that most needs evidence support is made when evidence is weakest. If the initial assumptions about an entity, time range, or search direction are wrong, adding nodes later may rescue the answer, but cannot recover the cost of irrelevant branches already executed.

The paper therefore shifts attention from repairing a complete plan to deciding when the next part of a plan may be created. Completed nodes report not only answers, but also rationale, confidence, and uncertainties; the Orchestrator uses these signals to continue investigation, change search strategy, or synthesize an answer. Core Idea: commit only to a batch supported by current evidence, let evaluations drive graph growth, and use an append-only graph with unchanged historical dependencies to organize context and training credit.

Method¶

Overall Architecture¶

The input is a research question; the output is a final answer supported by evidence nodes. Starting from an empty DAG, the Orchestrator creates a small first batch of sub-tasks. ReAct Executors use retrieval and page-access tools and return structured summaries. Each subsequent round evaluates the previous batch before adding new nodes, until the Orchestrator creates an answer node that occupies its own batch.

Three designs support one another: Evaluate-then-Grow determines when nodes are created, Hierarchical Context determines what new nodes can read, and DAGRPO Structural Rewards use the recorded graph in an optional reinforcement learning stage. DAGent can perform inference without training. DAGRPO is neither an inference-time judge tool nor the mechanism that evaluates node statuses in each round.

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    Q["Research question<br/>and empty DAG"] --> P["Evaluate-then-Grow"]
    P --> C["Hierarchical Context"]
    C --> E["ReAct execution<br/>retrieval and page tools"]
    E -->|QueryDoc and status feedback| P
    E -->|answer node completes| A["Final answer"]
    E -.->|training only: graph and trajectories| R["DAGRPO<br/>Structural Rewards"]
    A -.->|training only: final correctness reward| R
    R -.->|update shared policy| U["Orchestrator and<br/>Executor policies"]

Solid arrows represent inference data flow; dashed arrows represent training supervision. The Orchestrator determines node statuses from execution results, while the final-answer judge provides the binary training reward. These are different signals.

Key Designs¶

1. Evaluate-then-Grow: ground the next batch in evidence already obtained

Each node stores a sub-task description, execution prompt, direct dependencies, and status. After executing a node, the Executor generates a QueryDoc containing its answer, a brief explanation, key execution steps, self-reported confidence between 0 and 1, and uncertainties requiring verification. The Orchestrator uses these fields to explicitly label every node in the previous batch as Success, Uncertain, or Not Found. Success indicates reliable evidence acquisition; Uncertain indicates evidence requiring verification; Not Found means execution was valid but returned no relevant evidence. The latter two cannot silently be treated as successful results.

For Uncertain or Not Found nodes, the Orchestrator creates refine nodes when budget remains, changing the search strategy or pursuing further verification. Each sub-task line permits at most three attempts: one initial execution plus two refinements, not three additional retries. After the budget is exhausted, the lead remains an explicit uncertainty rather than triggering an endless search loop. New dependencies may point only to nodes that have already executed and been evaluated, so current-batch tasks can run in parallel instead of depending on unfinished peers.

The graph only appends new nodes and their dependencies: existing nodes are neither deleted nor rewired. Beyond simplifying scheduling, this ensures that ancestry in the final graph matches the upstream information a node actually received at execution time. An answer node is created only when the Orchestrator considers the evidence sufficient. It must occupy a singleton batch and directly depend on the evidence nodes selected by the Orchestrator, preventing final synthesis from running alongside unfinished evidence searches.

This differs from building a complete plan through several planner calls: if all those calls occur before execution, the system still commits first and patches later. The first batch in DAGent is the only planning decision without execution evidence and is therefore kept small. Subsequent investigation follows actual findings rather than merely unfolding the initial outline.

2. Hierarchical Context: propagate conclusions by default and revisit direct dependencies when needed

Passing every ancestor's records into each node would turn the graph into a continually expanding context. DAGent's Selective Propagation supplies only the QueryDocs of direct dependencies as default upstream context. Its footprint is therefore primarily governed by fan-in and summary length, rather than directly converting graph depth or total node count into context length. This does not imply constant cost for arbitrarily high-fan-in nodes.

A QueryDoc preserves conclusions and reliability signals, but may omit exact wording, rejected candidates, or details of the retrieval process. Each node therefore also stores an InteractionTranscript containing its complete tool actions and observations. When specific material is needed, the Executor calls recall(node_id, goal), asking a language model to extract a focused snippet from a named direct dependency's transcript. This is neither graph-wide retrieval nor a default reinjection of all raw history into the current task.

The appendix constrains RecallTool to the specified transcript, requires a document ID, URL, or exact quote for each claim, and requires an explicit statement when relevant material is absent. These rules limit the returned evidence while preserving traceability, but recall remains model-based extraction rather than lossless reading. Only 22.0% / 13.6% / 11.0% of Qwen3-32B tasks across the three benchmarks invoke it, consistent with a summary-first, transcript-fallback interface.

3. DAGRPO Structural Rewards: distinguish answer-chain execution from planning violations

Training solely on final correctness gives useful evidence and irrelevant exploration within a task trajectory the same reward. DAGRPO starts at the final answer node and takes the closure containing that node and all its ancestors, denoted \(S(\tau)\). Executor outputs in this closure directly or transitively feed final synthesis. Off-chain nodes may still have exploration value, but need not receive identical credit on successful trajectories.

On-chain Executors retain the full binary outcome reward; off-chain Executors receive it multiplied by \(\alpha\). Since failed trajectories have zero outcome reward, multiplicative attenuation adds no extra penalty to nodes that found material the final answer failed to use. This motivates attenuation rather than subtracting a constant. Trajectories without an answer node fall back to \(\alpha=1\), restoring outcome-only Executor credit.

The ancestor closure is a structural proxy for contribution, not causal attribution. Listing a node as a dependency does not prove it is indispensable or factually correct; estimating marginal contribution would require removing it and rerunning affected descendants. The authors argue that arbitrary dependency inflation is unattractive because rewards do not directly increase with ancestor count, irrelevant dependencies contaminate downstream context, and graph size does not inflate during training. These arguments are not a general guarantee against reward gaming.

The Orchestrator separately receives a structural compliance penalty: all previous-batch nodes need statuses, weak nodes with remaining attempts must be refined, answer nodes must occupy singleton batches, prompts must not duplicate, JSON must be parseable, and dependency references must be valid. The penalty aggregates violating turns at the trajectory level with a cap, rather than independently penalizing each malformed token. Orchestrator and Executor rewards undergo separate group normalization so that the more numerous Executor sub-rollouts do not dominate the Orchestrator's baseline statistics.

A Worked Example¶

The following is a mechanism illustration, not a reported test case. Suppose a question asks for the recipient of a historical award and the institution they belonged to at that time. The first batch can investigate award records and candidate biographies in parallel, without prebuilding investigation chains for every possible person.

The award-record node returns a candidate and source and receives Success. The biography node encounters two similar names and records identity uncertainty in its QueryDoc, so the Orchestrator assigns Uncertain. The next batch creates the first biography refinement to search institutional archives with the award year, while other reliable leads may continue to expand. If uncertainty persists, only one more refinement is allowed, limiting that line to three executions in total.

Once identity is resolved, a new institution-verification node directly depends on the confirmed biography and award record, receiving just their two QueryDocs. If it needs the institution's exact wording in the announcement, it calls RecallTool on the award-record node rather than reading all pages in the graph. Finally, a singleton answer-node batch depends on the verified evidence and returns the person and institution.

If a training trajectory also contains a branch unrelated to the final answer, that branch remains in the recorded graph but lies outside \(S(\tau)\) and receives attenuated credit when the answer is correct. Such a branch might have helped reject a candidate even though the closure does not capture that value, illustrating the difference between graph reachability and causal contribution.

Loss & Training¶

DAGRPO retains GRPO's clipped policy-gradient form, changing reward construction before advantage normalization rather than introducing a graph neural network. With final-answer reward \(R(\tau)\in\{0,1\}\) and role \(u\), its core rewards and advantages are:

\[ \tilde r_i^{(u)}= \begin{cases} R(\tau), & u=\mathrm{exec},\ v_i\in S(\tau),\\ \alpha R(\tau), & u=\mathrm{exec},\ v_i\notin S(\tau),\\ R(\tau)+r_{\mathrm{proc}}(\tau), & u=\mathrm{orch}, \end{cases} \qquad \hat A_i^{(u)}=\frac{\tilde r_i^{(u)}-\mu_u}{\sigma_u}. \]

The Orchestrator group contains the \(G\) trajectories sampled for a task; the Executor group contains all retained Executor sub-rollouts they spawn. The statistics \(\mu_u\) and \(\sigma_u\) are computed within each role. GRPO-DAGent must not be described as globally normalized GRPO without role separation: it also separates roles, while setting \(\alpha=1\) and removing the compliance penalty.

The structural penalty is:

\[ r_{\mathrm{proc}}(\tau)=-\lambda_{\mathrm{proc}}\min\bigl(N(\tau),K_{\mathrm{proc}}\bigr). \]

Here \(N(\tau)\) counts planning turns with structural violations, not the total number of violation categories. The experiments use \(\lambda_{\mathrm{proc}}=0.3\) and \(K_{\mathrm{proc}}=5\), capping the penalty at 1.5. A correct trajectory with one to three violating turns still outranks a clean failure, but this ordering is not guaranteed with more violations.

Training uses Qwen3-8B and all-linear-layer LoRA on 680 BrowseComp-Plus training tasks, with both rank and LoRA alpha set to 64. Each batch contains 32 tasks with 8 trajectories per task. AdamW uses learning rate \(1\times10^{-5}\) for 21 update steps on two H200 GPUs. DAPO-style lower and upper clipping ranges are 0.20 and 0.28; entropy and reference-model KL coefficients are both 0.001. Full DAGRPO uses \(\alpha=0.5\).

The clipped objective over sub-rollout tokens is normalized by the total response-token count of the entire task trajectory, with a reference-model KL stabilizer outside that objective. Inference uses greedy decoding with thinking disabled. Trained checkpoints transfer zero-shot to GAIA and xbench-DeepSearch without further training on those evaluation sets.

Key Experimental Results¶

Main Results¶

All metrics are Pass@1 (%), subject to three distinct dataset conditions. BrowseComp-Plus has 150 evaluation tasks, with 50 each in easy / medium / hard, and uses local dense retrieval with Qwen3-Embedding-8B over a fixed corpus. Main-table GAIA uses 103 text-only validation tasks, split into 39 / 52 / 12 at L1 / L2 / L3. xbench-DeepSearch uses the 2505 release with 100 Chinese tasks. The latter two use Serper Google search and Jina page extraction; methods within each benchmark share the tool backend.

Setting and statistical protocol	Method	BrowseComp-Plus	GAIA	xbench-DeepSearch
Qwen3-32B, training-free, single greedy pass	ReAct, 109K	31.3	39.8	58.0
Qwen3-32B, training-free, single greedy pass	Fold Agent	41.3	42.7	55.0
Qwen3-32B, training-free, single greedy pass	Flash-Searcher	38.7	44.7	58.0
Qwen3-32B, training-free, single greedy pass	FlowSearch	43.3	51.5	63.0
Qwen3-32B, training-free, single greedy pass	DAGent	47.3	55.3	65.0
Qwen3-8B, trained, three-seed mean ± sample std	GRPO-DAGent	46.0 ± 1.2	50.8 ± 1.1	63.0 ± 1.0
Qwen3-8B, trained, three-seed mean ± sample std	DAGRPO-DAGent	49.6 ± 1.0	53.4 ± 1.0	65.7 ± 1.5

This table selects results from the paper's Table 1. At 32B, DAGent exceeds FlowSearch by 4.0 / 3.8 / 2.0 percentage points. The 8B structural-reward gain should be compared against same-budget GRPO-DAGent: 3.6 / 2.6 / 2.7 points, approximately 3.0 when averaged equally across benchmarks. The groups differ in model size and statistical protocol and should not be directly pooled into one ranking.

FlowSearch uses the authors' released implementation with its execution-conditioned Coordinator enabled and a shared backbone and tool stack, while retaining official budgets. It is evaluated only at Qwen3-32B. The 32K × N setting for multi-context methods is a per-context cap, not a 32K budget for an entire research question. DAGent caps each context at an 8,192-token prompt and a 32,768-token response including tool outputs.

GPT-4o-mini judges answers, with GPT-4.1 breaking ties on borderline cases. A human calibration sample of 150 cases, 50 per benchmark, yields 97.3% overall agreement with human-majority labels and Cohen's \(\kappa=0.95\). GAIA uses an answer-equivalence judge instead of its original quasi-exact-match scoring, so comparisons with original-protocol scores require this qualification.

Ablation Study¶

Qwen3-32B training-free configuration	BrowseComp-Plus	GAIA	xbench-DeepSearch	Overall
DAGent full method	47.3	55.3	65.0	55.9
Same-architecture Plan-then-Patch	42.0	50.5	61.0	51.2
No Evaluate-then-Grow, single upfront plan	33.3	42.7	55.0	43.7
No Selective Propagation	34.7	44.7	57.0	45.5
No QueryDoc	39.3	47.6	60.0	49.0
No InteractionTranscript / RecallTool	43.3	52.4	63.0	52.9

Every row of the original Table 2 uses a single greedy pass; Overall is the unweighted mean across benchmarks. The same-architecture Plan-then-Patch variant retains Executors, tools, context components, and the three-attempt mechanism, changing only cross-iteration planning: create the full graph first, then permit refinements or added nodes. It is not the single-plan ablation that disallows subsequent adjustment, whose loss is larger.

Qwen3-8B training configuration	\(\alpha\)	Structural penalty	BrowseComp-Plus	GAIA	xbench-DeepSearch	Overall
DAGRPO, three-seed mean	0.50	On	49.6	53.4	65.7	56.2
No topology credit, single seed	1.00	On	47.3	51.5	64.0	54.3
No compliance penalty, single seed	0.50	Off	48.0	52.4	65.0	55.1
Remove all off-chain credit, single seed	0.00	On	44.0	49.5	61.0	51.5
GRPO baseline, three-seed mean	1.00	Off	46.0	50.8	63.0	53.3

In the original Table 3, full DAGRPO and GRPO are three-seed means; other rows are same-budget single-seed runs. The reported Overall changes without topology credit and compliance regularization are −2.0 and −1.1, respectively; the former can differ by 0.1 from subtracting rounded Overall values. Smaller per-benchmark differences are comparable to seed variation and do not establish independently significant component effects.

Key Findings¶

Removing incremental planning causes the largest training-free ablation loss: 14.0 / 12.6 / 10.0 percentage points. Selective Propagation is next, indicating that local dependency context and planning timing both matter.
Summaries are not the sole information channel. Retaining full transcripts with RecallTool fallback provides 4.0 / 2.9 / 2.0 points of overall advantage despite limited usage, but table differences cannot directly establish a causal effect for every calling task.
In the same-architecture efficiency comparison, full DAGent uses 1.20M / 0.66M / 0.44M total input-plus-output tokens, versus 1.68M / 0.85M / 0.52M for Plan-then-Patch. The latter costs more and is less accurate. Steps count the longest Executor trajectory per batch plus Orchestrator rounds, not total tool calls or latency.
Flash-Searcher uses fewer tokens and less time than DAGent, so the paper does not show lower cost against every method. The defensible claim is improved accuracy and realized cost within the same architecture or per-node-context comparisons; workflows do not share a common whole-task cost cap.
\(\alpha=0\) performs worse than the GRPO baseline, indicating that exploration outside the answer chain cannot all be treated as useless. Full DAGRPO beats other single-seed attenuation settings on each benchmark, but the precise best coefficient may change with task distribution and training scale.

Highlights & Insights¶

Planning timing is an algorithmic variable. DAG parallelization addresses execution, while Evaluate-then-Grow additionally decides whether a branch should exist yet. Treating weak evidence as normal input to the next round, rather than exceptional recovery, is the most transferable idea.
An append-only graph supports both execution and training. Unchanged historical dependencies let training read the evidence flow that actually occurred. Its value is a low-cost, reproducible structural proxy, not proof of node contribution.
Summaries and traceable records serve different purposes. QueryDocs control everyday context cost, while InteractionTranscripts retain verification material. They provide a default interface and an on-demand fallback rather than competing memory replacements.

Limitations & Future Work¶

The authors explicitly describe DAGent as text-native. The GPT-5 experiment on the full 165-task GAIA validation set uses image, document, and audio inspectors to convert attachments into text, rather than evaluating multimodal evidence directly inside the planning loop. Those results must not be pooled with the main table's 103-task text-only GAIA.
Planning cannot create evidence the retriever never returns; search engines, embeddings, and page extraction remain bottlenecks. QueryDoc confidence is also model-reported and is not demonstrated to be probabilistically calibrated.
The answer ancestor closure can miss a node's value in rejecting incorrect candidates if that node is not connected to synthesis. The association between structural violations and lower accuracy may also be confounded by task difficulty. Small-scale subgraph reruns and counterfactual checks could calibrate these proxies.
The three benchmarks primarily test verifiable closed-form answers, not quality of long, open-ended research reports. Citation coverage, evidence-conflict handling, and report completeness require additional evaluation.
RL covers only Qwen3-8B, LoRA, and 21 updates; main training comparisons use three seeds, and component ablations mostly use one. Gains for larger models, longer schedules, and full fine-tuning remain unestablished.
Append-only growth preserves clean history but prevents direct revision of early dependency mistakes. A future system could separate immutable execution logs from a revisable current knowledge graph, requiring a new mapping between the two for credit assignment.

vs Flash-Searcher / FlowSearch: They establish a task-covering plan before repairing it from execution results; DAGent creates new tasks only after dependency evidence has executed. The actual FlowSearch implementation includes a deletion-capable refiner, so the advantage is not merely against a fully static graph.
vs Summary / Fold Agent: These methods primarily extend usable context along a linear trajectory; DAGent organizes evidence through multi-parent dependencies and separate node contexts. The approaches could be combined, but summary loss and fan-in cost would need control.
vs M-GRPO / Graph-GRPO / CCPO: M-GRPO normalizes credit by role, Graph-GRPO learns communication topology among a fixed agent set, and CCPO estimates marginal contribution through counterfactual removal. DAGRPO instead subdivides Executor credit beyond role separation using the answer ancestor closure of a task DAG created during execution.
Research direction: Replace the fixed three-attempt refinement budget with decisions based on evidence conflict, search cost, and expected information gain. This would require genuine counterfactual or information-gain evaluation rather than repeated scheduling from self-reported confidence alone.

Rating¶

Novelty: 4/5 — Evidence-conditioned incremental planning and recorded structural credit fit together clearly, while building on existing DAG, ReAct, and GRPO components.
Experimental Thoroughness: 4/5 — Same-architecture planning controls, shared tools, and three-seed main training results are strengths; single-seed component tests and missing open-report evaluation limit conclusions.
Writing Quality: 4/5 — Planning timing, context, and rewards are connected clearly, with explicit boundaries between structural proxies and causal contribution.
Value: 4/5 — Useful for long-horizon retrieval-based multi-agent systems, subject to retrieval quality, evidence calibration, and training-scale limits.