When you hand a complex research job over to an AI wholesale, there's one thing you have to settle first: how much of the plan do you lock in ahead of time?
By deep research, I mean the kind of AI work that ranges across dozens to hundreds of sources, gathering evidence to answer a complex question. The answer from DAGent, a recently released deep research agent, is a surprising one: don't plan it all in advance. Instead of fixing the entire plan at the outset, it only appends the next piece of work after checking how solid the task it just finished is, and what still remains uncertain. The authors named this approach Evaluate-then-Grow — evaluate first, then grow the plan.
Let's start with the result. Pitted against the conventional approach with the same model, the same tools, and every condition held identical, DAGent was more accurate while using fewer tokens, tool calls, and steps to solve a single task. Usually these two trade off against each other: raising accuracy means pouring in more compute, and saving compute means giving up accuracy. DAGent took both.
Deep research isn't like ordinary search. A single question can mean combing through hundreds of sources. Work like this lends itself to breaking the job into small tasks and wiring them together by dependency — this has to finish before that can start. A task map built this way is called a DAG: a directed acyclic graph, meaning the arrows flow in one direction only and never loop back. Branches that don't depend on one another can run in parallel, and each worker only needs to look at the tasks it stands on, not the entire history. None of this is new — it's already established design.
The dividing line is when you decide the plan. Existing DAG agents typically lay out a plan covering the whole task in one shot, before any work begins. Then, when a failure or a gap in evidence surfaces mid-run, they patch the graph. The paper calls this pattern Plan-then-Patch — plan first, patch later.
There's a structural trap here. The system commits to its biggest plan exactly when it knows the least about the problem, at the moment it holds the least evidence.
A mountain analogy makes it clear. Plan-then-Patch is drawing the entire route to the summit on your map before you set out, then erasing and redrawing it every time the trail is blocked on the way up. You end up drawing the most lines at the foot of the mountain, where visibility is worst. Evaluate-then-Grow flips the order: you climb one stretch, and only once the view opens up do you decide the next stretch, and only that stretch.
In this way DAGent breaks the old premise that everything must be fixed at the start. The authors describe it as the first deep research agent to tie each planning decision to a summary of the completed subtask's results, evidence, and confidence.
Let's be precise about what it beat. DAGent didn't beat a single strong opponent. The three benchmarks each have a different character, so the method holding first place differed from one benchmark to the next. DAGent came out ahead of each of those different leaders, in all three. And it did so with no training attached, on a setup running the largest base model. A base model here is the LLM (large language model) that acts as the agent's brain, also called the backbone. The scores are the average Pass@1 — the first-attempt success rate, which checks whether a single run lands the right answer.
| Benchmark | Prior leader on that benchmark | DAGent | Difference |
|---|---|---|---|
| BrowseComp-Plus | 56.0 (history-summary method) | 61.3 | +5.3 |
| GAIA | 57.3 (109K-context ReAct) | 63.1 | +5.8 |
| xbench-DeepSearch | 70.0 (Flash-Searcher) | 72.0 | +2.0 |
(No training · backbone Qwen3-235B-A22B · all average Pass@1)
The names in parentheses are the prior front-runners on each benchmark, so feel free to skip past them if they're unfamiliar. For reference, the context window is the amount of text an AI can hold in its head and look at all at once.
This isn't a fluke from one model, either. The same pattern repeated across scales from Qwen3-8B up to 235B, and across open-source base models from four vendors. And when compared on a setup that pushed GPT-5 to a 327K context, it held its own against the latest agent systems.
Add training and the gap widens. Applying a reinforcement learning method called DAGRPO to Qwen3-8B raised average Pass@1 by 3.0 points over a conventional, outcome-only RL method that used the same compute budget. That said, the gain isn't independent of the settings. A sensitivity analysis — a test of how performance shifts when you jiggle a setting — that swept one key hyperparameter (α in the paper) shows that setting α to 0.25 or 0.75 left average performance 1.2 and 1.4 points below the optimal setting, respectively, and setting α to 0 dropped it even below the outcome-only RL baseline. In other words, to reap the gain in full you have to tune this value properly. (Table 3) (We'll look at what DAGRPO is separately, further down.)
The cost story comes through most clearly in the cleanest comparison. It's an experiment that holds every other condition fixed and pits only the planning approach — Evaluate-then-Grow versus Plan-then-Patch — against each other. The model, the tools, the architecture are all identical, so if there's a difference, it's down to the planning approach. The result was clear: the side that grows by reading the evidence used fewer tokens, tool calls, and steps per task, and was more accurate. The magnitudes are nailed down in Appendix Table 10. On BrowseComp-Plus, relative to Plan-then-Patch, DAGent cut tokens from 1.68M to 1.20M, tool calls from 87.9 to 67.6, and steps from 54.8 to 42.7. By pinning everything to a single variable, this comparison is the strongest evidence for the "more accurate and cheaper" claim.
The experiments themselves are thorough. They span seven base models — three Qwen3 variants, three from other vendors, and GPT-5 — and three benchmarks, with conditions fixed so that every method shares the same search backend, the search engine and tools that actually go fetch the material. The design details are in the paper.
So how does a machine actually pull off "grow by reading the evidence"? The mechanism comes down to one thing: a separation of roles. It splits an orchestrator from workers and lets a clear signal flow between them.
The Orchestrator looks at the tasks finished so far and appends the next bundle of work — a batch — to the graph. A worker (the ReAct Executor) is an execution agent that loops through think, use a tool, observe the result. The newly appended tasks run side by side as long as they don't depend on one another.
The crux is what the worker hands back to the orchestrator. When a task finishes, two records remain. One is a detailed log holding the entire execution trace; the other is a one-page summary card that compresses it, called the QueryDoc.
The card carries five things. The subtask's answer, a short explanation of that answer, and a summary of the key execution steps — that much is "what did it find out." Then the executor's self-assigned confidence and a list of uncertainties still to be checked — those two are "how trustworthy is it, and what's still open." The worker doesn't just toss back an answer; it grades its own result and sends that grade up along with it. So what the orchestrator looks at isn't the long, long execution trace in full, but this summary card that fits the answer and its reliability onto a single page.
It's this card that decides the next move. The orchestrator tags each task in the batch that just finished with a status: Success if it caught solid evidence, Uncertain if it needs more verification, Not Found if it ran fine but turned up no usable evidence. A task tagged Uncertain or Not Found spawns a refine task that retries the same job with a different search strategy — but only up to three times per chain. The initial attempt plus two reinforcements, cut off there to prevent endless retries. Growing this way, it ends when the orchestrator sets up an answer task that gathers the scattered evidence and composes the final answer. That task must sit alone in its own batch, so that it can reach all of the evidence flowing down from above and build the answer.
In long research runs the execution log grows without end. Yet what the downstream tasks need is usually just the conclusion from upstream. So by default only the summary card passes to the next task, and each task receives only the summaries of the tasks it stands directly upon. The paper calls this selective propagation. As a result, the context a task carries is bounded not by the whole graph but only by the number of direct dependencies feeding into it. Only when the summary falls short — as when the exact wording of a source is needed — does a worker pull the needed fragment from the detailed log. That stays the exception.
One property underpins all of this: append-only, the rule that once a task is attached, it's never deleted or rewired, only stacked on. Because of that, "the context a task actually saw when it ran" matches exactly "the tasks sitting above it in the finished graph." This seemingly minor property turns out to be the key to the next part of the story.
DAGRPO is the mechanism that takes DAGent up another notch. Its starting point is one common-sense gripe. Even within a single graph, some runs sit on the critical path that led to the final answer, while others are dead-end explorations that were never used. Yet conventional RL doesn't tell the two apart. The conventional method here is GRPO, which runs the same problem several times and then throws its weight behind the runs that did better than average. It looks only at final success.
The problem is that the learning signal gets smeared. If a run that reached the right answer and a run that floundered and got discarded receive the same score, the model can never work out which choices actually helped produce the answer.
What DAGRPO does is fix exactly this. It takes the final answer together with all the upstream tasks that actually led to it, and treats them as the set that contributed to the answer. A worker that labored inside this set gets its reward in full; a worker that spun its wheels outside the set has its reward docked. If no chain leading to an answer ever formed, it docks nothing and falls back to the original scheme. It doesn't force a penalty.
This contribution tracking is possible only thanks to the append-only property mentioned earlier. The contributing set falls right out by reading backward through the stack-only graph structure, with no need to rerun anything. In Plan-then-Patch, where plans are drawn, erased, and rewired, the final structure can diverge from what was actually consulted, so a signal like this can't even be defined in the first place. In a sense, the choice of planning approach handed over the training-method innovation for free.
This method is no cure-all. The limits the authors draw for themselves are, if anything, refreshingly candid.
First, the contributing set is a metric that stands in for causation by measuring structure instead. "It sat on the chain that led to the final answer" is not the same as "that task produced the correct answer." It's also worth noting that the whole method is bound to the append-only premise. The moment you move to a design that erases and rewires the graph, DAGRPO's credit-assignment signal no longer carries over as is.
There's a weightier point. The hardest problems still mostly go unsolved. On the hard-problem subset of BrowseComp-Plus, DAGent scored just 6.0 with Qwen3-8B, and only 22.0 even on the largest 235B. Separate from its across-the-board edge on the three benchmarks, this signals that the real hard problems of deep research remain a large open challenge.
There are also caveats to keep in mind throughout. The scores lean on Pass@1 and an LLM judge. They look only at whether a single run got it right, and the correctness call is made by another LLM, not a human. If the judge is wrong, the score is wrong. DAGRPO's training gain was confirmed only at the Qwen3-8B scale; whether it holds on larger models is outside this paper's scope. And since the search backend is fixed per benchmark, how well it generalizes to a different tool stack or a different domain remains to be seen.
This discipline, which a cutting-edge AI agent arrived at in order to save compute, actually maps straight onto how we work. It's a point we ran into ourselves while designing the AI PM at ONTLE.
Picture a scene. A client asks us to "analyze how our pricing and reviews stack up against the competition." A plan-it-all-upfront PM nails down the entire research plan on intake day, before looking at anything: finalize the competitor list, collect prices, analyze reviews, synthesize. But when it comes time to actually collect prices, two of the competitors keep theirs private. The "price comparison" branch hung beneath that becomes a dead plan in its entirety, and gets erased and redrawn. All because the plan was pinned down the most at the very moment the client's request was at its vaguest.
The way ONTLE breaks a project into small subtasks and branches them out is exactly the task graph we saw earlier; today, work is already managed in this branching form. Layering the Evaluate-then-Grow ordering on top of that is the next picture we're drawing. The AI PM runs only "identify competitors" and "check whether pricing is public" as its first batch, and only after checking the confidence and uncertainty each task left behind does it compose the next batch. "Three of five publish prices, high confidence. The other two need additional sources, uncertain." Only once it has this signal does it decide the next move, and if an item marked uncertain stays unresolved for too long, it's raised to the "awaiting decision" state on the ONTLE client screen to call for a human judgment.
The reporting style comes out of the same frame. A summary card compressed to "conclusion and evidence, confidence, what's still uncertain" is exactly the shape of the interim report the AI PM sends up to the client, and the detailed execution log comes out only when a question like "what exactly is the source of that figure?" arrives. The principle cutting-edge research reached in order to save cost meets the common sense a good PM has always kept, at the very same spot.
Rarely. RecallTool is an exception path that pulls from the detailed log only when the summary card falls short. On Qwen3-32B runs, it was used on just 22.0 / 13.6 / 11.0% of all tasks across BrowseComp-Plus, GAIA, and xbench-DeepSearch, respectively.
You have to separate two things. The "ahead on all three" result in the table above is a setting with no training attached at all. For the DAGRPO-trained version, meanwhile, a checkpoint trained on BrowseComp-Plus alone was carried over as is and evaluated on the other two benchmarks. Evaluating this way — without training separately on the target task — is called zero-shot. In other words, it was not retrained for each benchmark.
The authors explain in the appendix that the contributing set is a structural proxy read off the recorded graph without rerunning anything, and that it isn't gamed by inflating dependencies during training.
The paper states that the code is available on GitHub (github.com/hanwenliu6825/DAGent). The three benchmarks used for evaluation are BrowseComp-Plus, GAIA, and xbench-DeepSearch.