FlowSearcher: Synthesizing Memory-Guided Agentic Workflows for Web Information Seeking
Authors: Keyi Xiang
Zeyu Feng
Zhuoyi Lin
Yueming Lyu
Shi Boyuan
Yew-Soon Ong
Ivor Tsang
Haiyan Yin
Venue: ICLR 2026 Poster (2026)
Keywords: Large Language Model Reasoning
Structured Planning
Agentic Workflow
Primary area: applications to computer vision, audio, language, and other modalities
TL;DR: FlowSearcher is the first to reframe web search as query-specific agentic workflow synthesis with structured planning and hierarchical memory.

Abstract: Web search is a cornerstone for deep research agents, enabling them to acquire and reason over knowledge beyond static corpora. Yet most existing systems rely on ReAct-style tool chains with rigid, linear workflows,  hindering their ability to adapt to diverse query types and tool-use strategies. We introduce **FlowSearcher**, a novel deep search framework that formulates web information seeking as *memory-guided agentic workflow synthesis*.  FlowSearcher decomposes a query into subgoals and synthesizes a tailored workflow graph for each subgoal, dynamically adapting the depth, ordering, and composition of tool use. Complementing this, a hierarchical memory consolidates past workflows into reusable structural experience, which is retrieved to guide both workflow orchestration and execution on new queries.  By shifting from reactive tool calls to experience-conditioned workflow design, FlowSearcher enables flexible multi-path exploration and reuse without any supervised training or RLHF.  Experiments on GAIA, BrowseComp, and GPQA show that FlowSearcher consistently matches or exceeds the performance of RLHF-trained web agents under the same model backbone. Our code is released at [github.com/XiangKeYiNTU/flowsearcher](https://github.com/XiangKeYiNTU/flowsearcher).

Published as a conference paper at ICLR 2026
FLOWSEARCHER: SYNTHESIZING MEMDRY-GUIDED AGENTIC WORKFLOWS FOR WEB INFORMATION SEEKING
Keyi Xiang" 1x Zeyu Feng', Zhuoyi Lin Yueming Lyu', Shi Boyuan', Yew-Soon Ongl.3, Ivor Tsang" Haiyan Yin
CFAR and IHPC, Agency for Science, Technology and Research (A (A*ST))), Singapore
"Institute for Infocomm Research (I²R), S*SRAR, Singapore Cooleee of Computing and Data Science, Nanyang Technological University (NTU), Singapore
ABSTRACT
Web search is a cornerstone for deep research agents, enabling them to acquire and reason over knowledge beyond static corpora. Yet most existing systems rely on ReAct-style tool chains with rigid, linear workflows, hindering their ability to adapt to diverse query types and tool-use strategies. We introduce FlowSearcher, a novel deep search framework that formulates web information seeking as memory-guided agentic workflow synthesis. FlowScarcher decomposes query into subgoals and synthesizes a tailored workflow graph for each subgoal, dynam- ically adapting the depth, ordering. and composition of tool use. Complementing this, hierarchical memory consolidates past workflows into reusable structural experience, which is retrieved to guide both workflow orchestration and execution new queries. By shifting from reactive tool calls to experience-conditionee workflow design, FlowSearcher enables flexible multi-path exploration and reuse without any supervised training RLHF. Experiments on GAIA, BrowseComp, and GPQA show that FlowScarchi consistently matches or exceeds the perfor- mance of RLHF-trained web agents under the same model backbone. Our code is released at wit.gbthhbb..... com/ wwtpca//.aaaaagee////////eeeeeee
INTRODUCTION
The paradigm of scaling large language models (LLMs) is shifting away from expanding static pre-training corpora toward dynamic, real-time knowledge acquisition. Central to this shift is the emergence of research agents, which couple LLMs' intrinsic reasoning capabilities with ternal tools and web interaction. This fusion goes beyond static retrieval, equipping models to tackle time-sensitive, knowledge-intensive tasks across domains such as science, technology, and finance (Huang et al. 2025) Xu & Peng 2025). This trajectory is already exemplified by industrial systems such as OpenAl's Deep Research (OpenAl 2025b and Google Gemini Advanced (Co- manici et al., 20255; Google, (2024), which vividly illustrate how LLMs can evolve from passive repositories into autonomous collaborators that retrieve, evaluate, and synthesize knowledge at scale.
Despite recent advances, the real bottleneck is not model scale but the decision structures that deter- mine how agents navigate the web. Training-bait based systems such as WebThinker (Li al., 2025d) and WebDancer (Wu et al. (225a) still follow the ReAct template (Yao et al. 2023), locking agents into a abine-ect-observe loop. This enforces a narrow, tingeeeth trajectory that collapses in- herently branching research queries into linear chains, suppressing parallel exploration, backtrack- ing, and structural revision. Plan-execute frameworks (Song et al. 20255 Zheng et al. (025b) offer higher-level organization but remain static: once produced, the plan becomes fixed scaffold with little room for reordering or adaptation as new evidence arrives. As a result, these architectures
WWok conducted while interning at Centre for Frontier Al Research (CFAR), STARR, Singapore. Corresponding authors.

---

Published as a conference paper at ICLR 2026
remain fundamentally misaligned with the non-linear, exploratory, and continuously evolving work- flows that genuine research demands.
Another foundational challenge for long-horizon agent systems is the inability to learn across tasks (ang Gao et al., 2025). When faced with open-domain queries, most agents still operate in episode isolation (Wu et al. 2025a et al. 2025a Tao al., 2025): tool calls are issued within short reactive chains, and whatever is learned evaporates as soon as the episode ends. This limita- tion arises from their reliance on ephemeral, episodic memory, where chains-of-thought, tool traces, and exploration paths are never consolidated into any persistent, structured knowledge. Without such consolidation, agents accumulate no reusable experience. They repeatedly reinvent the wheel, repeating ineffective actions, failing to exploit strategies that succeeded previously, and showing little improvement across similar tasks. Overcoming this bottleneck requires abandoning transient context windows in favor of cumulative, structured memory system that can retain, organize, and reuse past workflows, supporting genuine long-horizon planning and strategic adaptation.
Building on these foundations, we introduce FlowSearcher, web-based research framework that departs from the rigid, ReAct-style behavior traditional agents by explicitly reasoning about how information-sseekng procedures should be structured for given query. Rather than committing to a single fixed tool-use trajectory, FlowSearcher represents query-conditioned workflows that allow the agent reason about the composition, ordering, and revision of tool operations when solving complex queries. This explicit structuring enables research behaviors that are inherently non-linear, such branching exploration, revisiting earlier decisions, and reorganizing intermediate steps as new evidence emerges. Importantly, these workflows are represented as explicit graphs, making the solution structure itself manipulable object that can be adapted, revised, and reused across related queries, rather than an implicit byproduct of step-wise action generation.
Crucially, FlowSearcher reframes open-domain web research as experience-driven workflow syn- thesis, rather than sequential action prediction. Past research trajectories are not discarded after execution, but abstracted into reusable experiences that infor how future workflows should be struc- tured. By elevating structure over step-wise actions, FlowSearcher enables adaptive planning and principled revision without relying on parameter updates or supervised fine-tuning. Our results fur- ther indicate that this form of structural reuse play a crucial complementary role parameter- level fine-tuning in complex web information seeking, offering a path to generalization that does not depend continual retraining. In practice, this perspective is supported by substantial empirical gains: FlowSearcher consistently outperforms strong ReAct-style baselines such as WebThinker- Base challenging benchmarks (e.g.. +11.5% GAIA and +9.5% on BrowseComp), without task-specific parameter training.
In summary, contributions are three-fold:
We formulate web information seeking as two-level process that separates high-level query decomposition and workflow synthesis from low-level workflow execution. This decoupling enables the system generate query-adaptive workflows while jointly optimizing orchestration and execution for complex, multi-step search tasks.
We reframe web search a workflow synthesis problem rather than sequential tool invocation. By grounding FlowSearcher in a compact and expressive library of workflow building blocks, the system can flexibly compose diverse solution strategies with explicit structural control.
We introduce multi-level memory spanning node, graph, and task abstractions that consol- idates past workflows into reusable structural knowledge. A compatible retrieval and instruc- tion mechanism injects this experience into both workflow synthesis and execution, enabling memory-guider co-optimization, adaptation across tasks, and learning-free generalization.
2 RELATED WORK
FlowSearcher connects three lines of research: agentic information seeking, workflow planning for research agents, and long- ang-horizon memory and experience reuse. While prior work has explored each of these directions independently, existing systems typically treat workflows either implicit execution traces or fixed protocol templates, and memory as an auxiliary component rather than driver of workflow design. FlowSearcher differs by unifying these strands through experience-
2

---

Published as a conference paper at ICLR 2026
conditioned workflow synthesis, where accumulated execution experience directly shapes how workflows are composed and executed for new queries.
Agentic Information Seeking Systems Although there exist works that demonstrate different in-
formation seeking behaviors by shifting among pre-defined modes like Reason- Mestoo-in--oooee In-Doouments mod- ule introduced in et al. (l and Problem-Solvine and Deport-Drafting modes introduced in
et al. (202dd). they still adopt single-step. linear planning structures et. al. 20224a; Jin et al.) [025] Song et al. 2025; Zheng et al., 2025b Wu et al. 2025a). While effective for short-horizon tasks, these approaches struggle with complex, malti-faceted queries that require branching exploration, revision, and long-range coordination across search steps. More fundamentally, their performance is often bottlenecked by the backbone LLM's ability directly interpret and decompose diverse search queries within a single reactive trajectory. As query complexity and heterogeneity increase, this tight coupling between query understanding and step-wise action selection limits robustness, making it difficult for agents to adapt their search strategy beyond what can be implicitly encoded in the model's prompt-time reasoning.
Workflow Planning and Optimization Recent work explores how research agents decompose tasks and execute multi-step workflows. ReAct-style frameworks such as WebThinker (Li et al.) 2025d) and WebWalker (Wu et al. 2025b) interleave reasoning and actions through sequential traces, but their global search strategy remains implicit, making optimization and generalization difficult. Planning-first frameworks (Hu et al. 2025 Tang et al. 2025b a) impose top-down workflow struc- tures, improving coherence but relying on manually defined roles and rules, which limits scalability in open-domain web settings (Qiu et al.
2025; Xie et al. 2025). RL--based systems like Web- Dancer (Wu et al.] 2025a) treat information seeking as an end-to-end pipeline and optimize via sampled trajectories. Surveys such as Xu & Peng (2025), Huang et al. (2025). and Li et al. (2025b) summarize these trends. More recent systems, exemplified by AutoFlow (Li et al. 2024b), AFLOW (Zhagg et al., 20256), and MermaidFlow (Zheng et al. 2025a), move toward automated protocol or workflow synthesis, demonstrating that reusable workflow patterns can serve as transferable knowl- edge. However, these approaches typically operate over a predefined workflow space, relying on fixed templates, evolutionary search, or offline optimization. In contrast, FlowSearcher synthesizes workflows dynamically at inference time, conditioning both workflow structure and execution on retrieved experience and task-specific evidence.
Agentic Memory and Experience Reuse Another line of research equips agents with persistent memory support long-horizon reasoning and adaptation. A-MEM (Xu et al. 2025) introduces Zettelkasten tinteiassteninspieedd memory system in which new experiences are stored as structured notes, linked related past traces, and incrementally updated new evidence arrives, enabling adaptive long-term reasoning. Mem0 (Chhikara et al. 2025) focuses on lightweight, production-orientee memory layer that maintains persistent state across interactions and summarizes past contexts to re- duce prompt length and improve personalization. G-Memory (Zhang et al. 2025a) extends memory mechanisms to multi-agent settings by organizing experiences into hierarchical graph structures at the interaction, query, and insight levels, and retrieving information at different levels of abstraction to guide coordinated agent behavior. Despite these advances, most existing memory systems rely on fixed retrieval policies operate over limited set of memory abstractions, which constrains their adaptability in open-domain web research. In contrast, FlowSearcher introduces a workflow- conditioned, multi-level memory hierarchy in which retrieval is jointly shaped by the task query and the evolving structure of the synthesized workflow, allowing past experience to directly inform both workflow design and execution.
METHODOLOGY
3.1 HIERARCHICAL AGENTIC WEB SEARCH TASK FORMULATION
In this paper, present FlowSearcher, agentic workflow framework for web search. We first reframe research query solving as a hierarchical maaiing process, where high-level query decomposition and workflow synthesis coupled with low-level structured execution. We then introduce a memory-driven workflow planner that conditions each execution step on both workflow structure and accumulated traces. Through this design, FlowSearcher brings structural fiexibility
3

---

Published as a conference paper at ICLR 2026
Workflow Synthesis
Two-leve Trajectory
Find itatt..
Hicrurchical Memory
Different Tool Use Patterny
Tasle level
Origiial queetions
cchernecter
Collect Reaults
High Level
General
Ensemble
Level
Arats butoll unwodiorss senrror
Satnanel freen crerting oorth now!
Swift-Hit
Break-Down
Orchastrator
Taok-Adapptive
inrotre nanigation, based on the provous
(1)
Workflowr Synthesis
Novigation
Quick
Oeperiene ipection
(2)
Mivortoo
Graph Topologyy @ Succonseedy
Mentry-Guuied Workfoow Execution
Count
Visit Count
Node: level:
lexenying
Summarise
10 Koywwrrds
Ranults
Browss
Search
Generate-Seocil Search
Salect Search Resalte
Reffornnce
Queviss
Ersemble
An overview of the FlowSearcher framework. Left: FlowSearcher synthesizes diverse tool-use patterns into task-adaptive workflow graphs, enabling different strategies for navigation, look-up, and surveying. Middle: A two-level search trajectory separates high-level orchestration from low-level execution: the orchestrator decomposes the query into sub- sub-goals and synthesizes workflows conditioned on retrieved experience, while the executor performs memory- guided work- flow execution. Right: A hierarchical memory records execution traces the task, graph, and node levels, which are retrieved to guide both workflow synthesis and execution, enabling experience- driven reuse and adaptation across queries.
Figure 1:
and layered memory grounding into agentic web search, enabling adaptive handling of complex queries and resilient reasoning over long horizons.
We formalize each research task together with its solution trajectory as {Q, (.. Here, Q denotes the original query, ý the predicted answer, and I' = {Mr } the trajectory consisting of decomposed sub-questions {Mr} and their corresponding workflow graphs (9i). In addition, we maintain structured execution memory M, which is updated after each step to record intermediate traces, and later serves as foundation for both workflow synthesis and execution.
workflow synthesis). the high level, FlowSSercher generates trajectory by iteratively decompos- ing the query into sub-questions and synthesizing the workflow graphs. At step i, the agent sam- ples the next sub-question μ4 and then generates workflow graph G, that specifies how to address it. Formally, if the query is solved in K steps, the probability of generating the overall trajectory is given by:
High-level (decomposition +
Q
{or M.0s
Gi
M fa,0t
K
finalize
g.
Lower level
Upper level
Figure 2: FlowSearcher's hierarchical search trajectory, involv- ing workflow synthesis, execution, and aggregation.
P(T Q,
II P(u Q,T'a,, P(G: &i Mi-1,
where On and fg. are the prompts for decomposition and workflow synthesis modules. Note that at the start of each trajectory, have Mo 0. As the trajectory unfolds, the memory M is incrementally updated, accumulating execution traces that capture both workflow structure and intermediate outcomes, providing rich contextual grounding that guides subsequent decomposition and execution. After obtaining complete trajectory, a finalization step is performed to produce the predicted answer ý for query Q.
Low-level (workflow execution). At the low level, each workflow G, for sub-question μ4; is exe- cuted the node level, where each node is followed along its dependency connections and guided
4

---

Published as a conference paper at ICLR 2026
by accumulated memory traces. For given node V(G.), the agent interacts with the web envi- ronment to generate an action sequence a and observations o. Hence, given a node with K2 distinct action steps, the execution process can thus be factorized as follows:
K, P(a,0 pi Mi-1) II P(as, Or acss, Octs Oct, Pi: Mi-1).
Given the above formulation, the overall trajectory of FlowSearcher is illustrated in Fig. Empow- ered by a hierarchical task structure and workflow-groundee execution, FlowSearcher departs from traditional linear tool-use agents and enables adaptíve reasoning across complex query landscapes. This flexible structure not only aligns decomposition with exccution, but also provides memory- grounded coherence, offering principled path toward resilient long- Long-horizon web search.
3.2 STRUCTURED COMPOSITIONAL MEMORY FOR EXPERIENCE REUSE
To enable efficient reuse of past experiences, we introduce a Structured Compositional Memory that organizes trajectories into three-level hierarchy. Our design allows selective retrieval and flexible cross-level recomposition of past traces, which is crucial for adapting workflows to insightful queries and ensuring generalization beyond single-task memorization. Formally, the memory M is set of task entries M = {M]ask), ), each bundling its sub-question workflow graphs together with their node-level traces.
Node-level. For node e E VGi), we record:
Masde (No, (0),, )(").
where N, is the node type and variant, and (*() and (o) denote the action sequence and its corre- sponding output. This fine-grained representation enables precise replay and transfer of tool execu- tion patterns across different sub sub-questions.
Graph level. For workflow graph addressing sub- sub-question pú we store:
M = (G., (4 Vi. n2s
where G; is the textual representation of Gs, 74 E {0,1) } is success indicator, and E NI7 is per-tool usage vector, with component (n,), counting how many times tool J T was invoked in G, By recording workflow structure, performance signals, and tool statistics, graph-level memory enables targeted reuse of effective strategies while avoiding over-reliance on fragile tool chains.
Task level. For query Qj we maintain:
Maask = (Qj, Eq, (Moroph K 1
where &q E {0, 1} indicates whether the task is successfully solved. encapsulates the end-to- end problem context and its outcome, allowing direct recall of solved tasks and failures alike, and providing reliable signals that guide decomposition and workflow selection in future queries.
Memory Retrieval Mechanism. FlowSearcher flexibly retrieves and recomposes traces from its hierarchical memory to guide agentic search with prior experience. To support adaptive reuse of trajectories, we define unified retrieval operator R(:{) parameterized by retrieval level Ç (graph, node). Given new query (Q" ,Q",,"""" (,;s), the operator selects the top- relevant struc- tured traces from M:
E(Q") E(Q) [EQ*)) + (1 - 5) E(u²) E(p) E(μ²) [(()]]
arg top-k MinskgM, QE Qeark MCCM PEMS
(3)
where F(() denotes the textual embedding, and a factor balancing between similarities of the original question and the sub-question. Finally, depending the retrieval level Ç, each entry is flex- ibly expanded within the hierarchical memory, yielding the enriched set: R(Q", (): @ {M²}. This flexible retrieval mechanism allows FlowSearcher to ground future reasoning not only on rele- vant past queries but also useful insights extracted from targeted execution traces.

---

Published as a conference paper at ICLR 2026
Planning
Execution
Task Tuple
Workflow Trace1
Searcher Trace
Browser Trace
Workflow Trace
Searcher Trace
Browser Trace
Task Tuple k
experience
experience
experience injection
retrieve
injection
injection
Current Task Tuple
Workflow Planner
Searcher Nodes
Browser Nodes
Figure 3: Flow-Sarcceer's structured compositional memory enables the co-optimization work- flow synthesis and execution. Retrieved task-level tuples surface high-value workflow traces that shape the global DAG structure ("planning"), ) while graph- and node-level traces inject fine- the-grained procedural knowledge into searcher and browser nodes ("execution")
3.3 MEMORY- GUIDED AGENTIC WORKFLOW PLANNING
We present memory-guided agentic workflow planning, which aims to synthesize adaptive work- flows typed directed acyclic graphs (DAGs). In this formulation, decomposed sub-queries handled by adaptive planning modules, while past execution traces are reused to refine and update these workflows, yielding workflows that are refined by experience both orchestration and ex- ecution levels. Fig. B illustrates how FlowSearcher's hierarchical memory supports this process: workfllw-level traces guide high-level DAG synthesis, whereas searcher- and browser-level traces effectively refine node behaviors and execution strategies.
At each step i, the orchestrator must not only generate a valid workflow, but also adapt its structure to the evolving query context. Formally, to handle sub-question μı, it constructs typed workflow graph as:
orchestrator Ubi T T,, B,0g) Mi-1 G.VV Epp)
(4)
VCB, VCVXV s.t. (u,v) Ep v(u, E.
Here, V/T.0.1 denotes typed nodes parameterized by an available tool т, prompt schema 0, and backbone model e) are admissible edges constrained by the web grammar p. and B is the pre- defined set of building blocks. Crucially, the construction of Gj binds the query Q, current sub- question H4, the previous trajectory cii and memory M,-1- This makes each workflow not just static composition, but an experience-driven program that evolves with context.
Experience-Guidd Workflow Orchestration. Retrieved graph-level traces inject prior experi- ence into orchestration, exposing both successful and failed strategies, tool-usage statistics, and graph topologies. Formally,
(5) Here Mg {G. n² J1.x denotes the retrieved graph-level traces, each containing the work- flow structure G, its success indicator 7, and tool-usage statistics n². These traces are expanded into full execution records and distilled by the orchestration instructor Ig into concise insights Eg, which are then injected into the orchestration prompt 0g. As a result, the workflow G* not a static composition, but one shaped by prior evidence: by contrasting successful and unsuccess- ful workflows, FlowSearcher uncovers structural patterns that guide effective design choices, while tool-usage statistics across topologies reveal how efficiency scales with structure. These insights ground orchestration in empirical evidence, making it adaptive, resource-aware, and systematically refined by past executions.
Mg = RR(Q",
Eo (M
G orchestrator(Og @ Eg).
Experience-Guided Workflow Execution. We formalize the node-level memory-enhanced exe- cution process as equation 6
Mr = R. (Q',,(")),, Eo = L.M.
(a", = execute(8, e Ev. TC).
(6)
The retrieved traces, M, = (N, (a, o)h... expand into execution logs that capture node configu- ration N, action sequences a, and their outcomes o. Distilled by the node instructor 7.,, these traces

---

Published as a conference paper at ICLR 2026
Table Performance comparisons on three benchmarks. We report Pass@ I metric on all tasks. The best results are highlighted in bold and the first runner-ups are underlined. Results from OpenAl's Deep Research are presented in gray for reference.
GAIA
GPQA-Diamond
BrowseComp
Backbone
Framework
Level
Level 2
Level
Avg.
Phy.
Chem.
Bio.
Avg.
Art
His.
No Agency
Qwen-2.5-32B
Base
20.5
9.6
13.1
52.3
30.1
68.4
43.4
0.0
0.0
RAG
20.3
11.8
6.3
13.0
64.0
41.9
57.9
53.0
0.0
0.0
0.0
Qwenn2.5-72B
Base
20.5
13.5
6.0
13.4
58.1
39.8
57.9
49.5
0.0
0.0
0.0
GPT-4o
Base
23.1
15.4
8.3
1.566
62.8
46.2
68.4
55.6
0.8
0.8
0.8
QwQ-32B
Base
30.8
15.6
6.7
17.7
84.8
44.1
68.4
64.1
0.0
0.0
0.0
RAG
33.3
25.0
19.4
84,9
45.2
73.7
65.2
0.0
0.0
DespSeck-R1-67IB
Base
43.6
26.9
8.3
31.1
90.7
57.0
84.2
74.2
0.0
0.0
0.0
Close-Sourced Agentic Fromeworks
OpenAl DR
74.3
69.1
47.6
67.4
51.5
ReAct Agentic Frameworks
Qwen-2.5-32B
Vanilla ReAct
46.1
26.9
31.
64.0
41.9
57.9
53.0
0.0
0.0
0.0
WebDancer
46.1
44.2
8.3
40.7
QwQQ32B
34.6
76.7
46.2
61.6
Search-ol
61.5
50.0
25.0
51.5
77.9
47.3
78.9
63.6
1.6
2.4
1.9
WebThinker-Bac
44.2
16.7
44.7
87.2
51.6
68.4
68.7
2.4
2.4
WebThinker-Re
56.4
50.0
16.7
48.5
90.7
50.5
78.2
70.7
2.4
3.1
2.7
WebDancer
61.5
50.0
25.0
51.5
3.8
Qwen-2.5.128
2,5-12B
FlowSearcher
61.5
46.2
16.7
48.5
72.0
47.3
68.4
60.1
5.5
5.6
5.6
Qwen-3-32B
FlowSearcher
53.8
16.7
55.3
87.2
48.4
78.9
68.2
8.7
QwQ-32B
FlowSearcher
66.7
57.7
16.7
56.3
90.7
51.6
78.9
71.2
7.9
7.2
8.0
GPT-4o-mini
FlowSearcher
66.7
53.8
25.0
55.3
81.4
49.5
73.7
65.7
11.0
12.0
11.8
yield execution insights Eo, which are injected into the node prompt 0g to guide the next action sequence o²)).
Beyond replay, these traces enable node-type specialization, refining execution strategies for roles such retrieval, parsing, or tool invocation. They also support cross-query transfer, allowing new tasks to inherit behaviors from structurally similar nodes. Crucially, the workflow graph G provides the scaffold for structure, while node-level memory drives local behavioral refinement. This divi- sion localizes and mitigates errors at the node level, while improving robustness over long-horizon workflow executions.
Together with orchestration, this node-level adaptation achieves the co-optimization of workflow planning and execution, ensuring workflows evolve holistically with both structural and behav- ioral guidance. Beyond conventional rigid workflows that are statically designed and replayed, FlowSearcher enables adaptive strategies that scale diverse tasks and promotes transfer across queries by grounding decisions in accumulated experience. To the best of our knowledge, FlowSearcher is the first framework realize such experience-driven agentic workflow planning.
EXPERIMENTS
4.1 EXPERIMENT SETUP
Tasks and Benchmarks. We evaluate FlowSearcher three challenging benchmarks: GAIA:(Mialon et al.) 2023) A benchmark testing Al models' ability as general assistants with three levels of difficulty, we used 103 text-only questions to evaluate our system's complex information retrieval and reasoning abilities; BrowseComp:(WWet et al. 2025) A benchmark for browsing agents consisting of "hard solve yet easy to verify" questions across topies like Art, History, etc.; GPQA- (aamond:(Rein et al.) 2023) A graduate-level Google-proof benchmarks of multi-choie questions across three domains: Physics, Biology, and Chemistry. We chose the Diamond subset as our test set, which consists of questions experts answer correctly but non-experts rarely.
Baselines. We compare FlowSearcher with three types of baselines: (1) Vanilla LLMs with no agency: under this category, tested two variants: Base LLMs with no access search tools and LLMs incorporated with standard RAG which retrieved top-10 relevant documents from search engines references before generating answers. (2) Close-sourced proprietary framework: We

---

Published as a conference paper at ICLR 2026
example of commercial solution. Notably, we exclude it from our quantitative comparisons because its full methodology. training setup, and evaluation pipeline are not publicly available, making results non-reproducible. (3) Existing agen- tie frameworks (particularly ReAct-style): including Vanilla ReAct, WebThinker Li Li et al. 2025d),
chose OpenAl Deep Research[OpenA] 2025b)
WebDDancrr(Wa et al. 2025a). and Search-ol ([i et al. 2025c).
Implementation Details. We utilized a variety of LLM backbones, including both open-sourced models (Qwen3-32B. Qwen2.5-32B, QwQ-32B Yang al. b025a(b)) and closed-sourced models (GPT-to-mini(pennal 2024)). We used SerpAP to enable web search and the Jina Reader AP for browsing capabilities. For each query initiated by the agents, we retrieved the top 10 results from the respective search tool. We provide details of prompts and data schemas as per Appendix C
4.2 BENCHMARK EVALUATION RESULTS
We present benchmark evaluation results in Table L1
ReAct-style agents do provide noticeable gains. For instance, vanilla ReAct boosts Qwen2.5-32B's GAIA score by +25.8 over standard RAG. However, their rigid step-wise structure limits further improvement. Even with reinforcement learning, progress quickly plateaus: WebThinker-RL. im- proves over WebThinker-Base by only +3.8 on GAIA, +2.0 on GPQA, and negligible +0.2 on BrowseComp, despite the heavy cost of dataset construction and training. These results reveal a core constraint: fine-tuning alone cannot overcome the structural bottlenecks of linear ReAct-style search.
In contrast, FlowSearcher avoids these limitations through dynamic, memory-guided workflow syn- thesis. Without any supervised fine-tuning, it consistently outperforms comparably scaled agentic baselines. With a BwQ-32B backbone, FlowSearcher surpasses WebDancer by +4.8 on GAIA and +4.2 on BrowseComp. Its advantage becomes even clearer on BrowseComp, which stresses open- domain browsing and long-horizon reasoning: FlowSearcher achieves a further +8.0 % improvement using a GPT-4o-mini backbone. On GPQA-Diamond, it reaches performance competitive with ad- vanced reasoning models such as DeepSeck-R1- -rrpScck-R1-61B...
These results illuminate two key insights: (i) FlowSearcher's structural flexibility enables it to adapt reasoning procedures to large, noisy, and unpredictable information spaces, a capability that rigid ReAct-style workflows struggle to match. (ii) FlowScarcher improves purely through experience-driven workflow planning, without relying on any fine-tuning pipeline. This in- dependence makes the system practical, generalizable, and naturally self-refining: it continually strengthens its workflows directly from execution history. In open-domain knowledge environments, FlowSearcher simply has strategic leverage navigate diverse and unreliable sources of in- formation.
4.3 BLOCK USAGE
In this section, evaluate the functional contributions of the pre-defined modules in FlowSearcher. We begin by analyzing block usage on the GAIA benchmark with the GPT-4o- mini backbone, verifying that the workflow orchestrator assigns each block to tasks aligned with its intended role.
The block usage across GALA's three levels is shown in Fig, Our key observations
Searcher block usage patterns are largely consistent across levels. Among the variants, the first- hit searcher dominates all levels, reflecting that most sub-steps involve quick look-ups. However, parallel searchers appear more frequently in Levels 2 and 3, capturing the added complexity of harder problems.
Browser block usage varies significantly. At Level 1, the first-hit browser was dominant, often paired with first-hit searchers for simple fact-checking. In contrast, usage of the in-depth browser rose sharply at higher levels, becoming the most frequently used at Level 3. This indicates that more complex tasks Levels and required deeper web navigation and interaction with webpages.
hhttss//serpapp.com// hupss//jna.a//raddr/
8

---

Published as a conference paper at ICLR 2026
GAIA Level Block Usage
GAA Level 2 Block Usage
GAIA Level Block Usage
Drvew
Gemeber
(a) GATA level
(b) GATA level
(c) GATA level
Figure 4: Usage of each block variant on GAIA evaluation tests with GPT-4o-mini backbone. The distribution highlights how the orchestrator assigns blocks in alignment with their intended roles, with deeper browser variants increasingly favored higher task levels.
Summarizer block usage is the most stable. Between the two summarizer variants, the gen- eral summarizer was consistently more common than the ensemble summarizer across levels. Nonetheless, slight increase in ensemble summarizer usage was observed at Levels 2 and 3 com- pared Level 1.
These studies reveal that FlowSearcher adapts its strategies to the blocks at hand, shifting from quick look-ups to deeper browsing when searchers are limited, or leaning on summarization when browsing capacity is reduced. Crucially, even with smaller toolset, the system reorganizes work- flows to sustain performance, underscoring its adaptability and robustness under constrained search- ing conditions.
4.4 ABLATION STUDY
In this section, we conduct ablation studies that probe the internal mechanics of FlowSearcher by independently scaling its core modules: (a) block library, which governs the expressiveness of workflow synthesis; (b) hierarchical memory, which governs experience-driven refinement.
4.4.1 IMPACT OF SCALING THE BUILDING BLOCK LIBRARY
For analyzing the effects scaling blocks, we conducted three groups of controlled experiments on GAIA with GPT-4o-mini backbone, where the set of available blocks was configured following three settings:
First-Hit Only. In this condition, the searcher and browser modules restricted to their first-hit variants exclusively. Accordingly, the system is permitted to perform only a single search query at a time, and the browsing process terminates immediately once the first relevant piece of information is retrieved.
First-Hit General. In this condition, the range of available modules is expanded include both the general and first-hit variants of the searcher and browser. The system may therefore issue up five search queries and aggregate their results, and it may browse up ten distinct webpages while extracting relevant information. However, the system can't 't conduct in-depth browsing, which means they cannot click links on pages and perform web navigation tasks.
No Limitations. In this condition, the orchestrator operates without any restrictions on module selection. All block types are available, and the system may employ them without predefined limits. This represents the default, unconstrained configuration, supporting the broadest possible range of retrieval strategies.
The results (Table show a clear progression. The first-hit only condition struggled due to its rigid constraints. Adding general blocks yielded a moderate gain of +7.8%, while lifting restrictions produced a substantial +20.3% improvement. These numbers underscore simple truth: limiting core building blocks narrows workflow flexibility, whereas expanding the available toolkit unlocks richer, more effective execution patterns, mirroring real-life web search, where diverse strategies are often required, much like how humans adapt their browsing behavior to the task at hand. This progression also indicates that workflow expressiveness, rather than raw tool count, is key driver

---

Published as a conference paper at ICLR 2026
Table 2: Performance on different sets of block options (with increasing system-level flexibility). Results show that broader block availability consistently enables more diverse strategies and delivers higher performance.
GALA
Block Option
Level 1
Level 2
Level
Avg.
First-Hio only
35,9
26.9
0.0
27.2
First-Hit General
41.0
36.5
8.3
35.0
No limitations
66.7
53.8
25.0
55.3
of performance, as richer block combinations allow the orchestrator better align search strategies with query structure.
4.4.2 IMPACT OF MEMORY COMPOSITION
In this section, we conducted four groups of controlled experiments to study the impact of utilizing different memory composition: (i) No Mem- ory: FlowSearcher synthesizes and executes workflows with mem- ory retrieval and experience injec- tion in this settings; (ii) Full Mem- ory: FlowSearcher synthesizes and executes workflows while recording
Table 3: Cumulative number of successful tasks under dif- ferent memory compositions.
Task Window
Full Mem.
No Mem.
Suce.- Only
Unsucc.- Only
1-20
5
6
1-40
16(+11)
(+11)
(014)))
13 (+8)
1-60
2+10)
(+6)
24 30(+00)
1-80
(014)
339)
42 (+12)
36 (+12)
and utilizing all past traces; (iii) Only
1-103
57 (+17)
(2
(311)
48 (+12)
Successful Memory: Only success- ful episodes are recorded and re- trieved; (iv) Only Unsuccessful Memory: Only unsuccessful episodes are recorded and retrieved.
We shuffled GAIA's 103 tasks in order to observe the unbiased trend shown in Table 3 We inferred from the results that: (a) Successfulonly memory yields the fastest early-stage gains because it reinforces high-quality positive patterns without noise; (b) Full memory eventually overtakes all others, as combining successful and unsuccessful traces enables stronger long-term correction and generalization; (c) No-memory and unsuccessful-only strategies improve far more slowly, highlighting the importance of structured experience reuse for continual self-improvement. Over- all, these trends reveal clear trade-off between exploitation and correction: prioritizing successful traces accelerates early learning by stabilizing effective patterns, while incorporating unsuccess- ful experiences becomes critical over time expose failure modes, refine workflow structure, and support robust long- morizoor generalization.
CONCLUSION
In this work, we introduced FlowSearcher, a framework that redefines web information seek- ing through experience-driven agentic workflows. Rather than relying on reactive tool-use, FlowSearcher constructs and optimizes full workflow graphs, supported by structured memory that retrieves and adapts past trajectories across tasks. These reusable traces directly inform both work- flow orchestration and execution, enabling FlowSearcher to achieve consistent and sizable gains over strong baselines on three challenging benchmarks. Beyond empirical results, our findings highlight a broader insight: memory-driven workflow design can unlock improvements on par with, and in some cases exceeding, those achieved through conventional fine-tuning. More broadly, our results suggest that elevating workflow structure and experience reuse to first-class design princi- ples offers a scalable alternative to purely parametric approaches for building robust, long-horizon research agents. Looking forward, aim to enrich FlowSearcher's memory with finer- merrngr patterns and distilled abstractions, and to extend its workflow representations with more expressive structures, moving toward agents that increasingly adaptive, transferable, and seff-improving.
10

---

Published as a conference paper at ICLR 2026
ACKNOWLEDGMENTS
This research is supported by the National Research Foundation, Singapore under its AI Singapore Programme (AISG Award No: AISG-NMLP-2024-005), and the National Research Foundation, Singapore and Infocomm Media Development Authority under its Trust Tech Funding Initiative, Career Development Fund (CDF) of the Agency for Science, Technology and Research (A *STAR) (No: C24351 C243512014). Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and not reflect the views of the National Research Foundation, Singapore, the Agency for Science, Technology and Research, or the Infocomm Media Development Authority.
REPRODUCIBILITY STATEMENT
To ensure the reproducibility and transparency of our research findings, all evaluations were con- ducted using publicly available benchmarks: GAIA (General AI Assistant benchmark ? GPQA- Diamond (Graduate-level Google-Prool Q&A benchmark(] and BrowseComp (Web browsing and comprehension benchmark] These datasets are openly accessible to the research community, en- abling replication of experimental conditions. Environment setting scripts, benchmark repro- ducing scripts (testing and evaluation) are provided as per in the Supplementary Materials. Com- prehensive implementation details provided in the Appendix. This documentation, combined with the standardized nature of the public benchmarks, ensures that our work can be independently reproduced and validated by the research community.
REFERENCES
Huan ang Gao, Jiayi Geng, Wenyue Hua, Mengkang Hu, Xinzhe Juan, Hongzhang Liu, Shilong
Liu, Jiahao Qiu, Xuan Qi. Yiran Wu, Hongru Wang. Han Xiao, Yuhang Zhou, Shaokun Zhang, Jiayi Zhang, Jinyu Xiang, Yixiong Fang, Qiwen Zhao, Dongrui Liu, Qihan Ren, Cheng Qian, Zhenhailong Wang. Minda Hu, Huazheng Wang, Qingyun Wu, Heng Ji, and Mengdi Wang. A survey of self-evolving agents: On path to artificial super intelligence, 2025. URL https:
//axxiv.rgg/ab/////.
Prateek Chhikara, Dev Khant, Saket Aryan, Taranject Singh, and Deshraj Yadav. Mem0: Building production-ready ai agents with scalable long-term memory, 2025. URL https://arxxv.
erg/abs/2504 19413
Gheorghe Comanici, Emile Bieber, et Gemini 2.5: Pushing the frontier with advanced rea- soning, multimodality. long context, and next generation agentic capabilities. arXiv preprint arXiv:2507.06261, 2025. URL /ttpttt/s///xxi.. wttp://ww.wg//a////../////// 002222077.666111
Google. Gemini deep research your personal research assistant, 2024. URL https:// receee--reeeacchh Accessed: 2025-08-25.
gemini ni wwt...ggglee/veeveewwweooo /
Mengkang Hu, Yuhang Zhou, Wendong Fan, Yuzhou Nie, Bowei Xia, Tao Sun. Ziyu Ye, Zhaoxuan Jin, Yingru Li, Qiguang Chen, Zeyu Zhang, Yifeng Wang, Qianshuo Ye, Bermard Ghanem, Ping Luo, and Guohao Li. Owl: Optimized workforce learning for general multi-agent assistance in real-world task automation, 2025. URL Bolltttts://aaact.
orq/ abs wtw.o///aaa//ooo 23885.
Yuxuan Huang, Yihang Chen, Haozheng Zhang, Kang Li, Meng Fang. Linyi Yang, Xiaoguang Li, Lifeng Shang, Songcen Xu, Jianye Hao, et al. Deep research agents: A systematic examination and roadmap. arXiv preprint arXiv:2506. 18096, 2025.
Bowen Jin, Hansi Zeng, Zhenrui Yue, Jinsung Yoon, Sercan Arik, Dong Wang. Hamed Zamani, and Jiawei Han. Search-rl: Training 1lms to reason and leverage search engines with reinforcement learning, 2025. URL https:tps//......... //axxvvvvvvv///a///avaaeaaraaaaa .eeiiii.rrrrgo org/ 001.5550..1111.0
09516
"htpss//hugginniccc.oo//////////

---

Published as a conference paper at ICLR 2026
Kuan Li, Zhongwang Zhang, Huifeng Yin, Liwen Zhang, Litu Ou, Jialong Wu, Wenbiao Yin, Baix- uan Li, Zhengwei Tao, Xinyu Wang, Weizhou Shen, Junkai Zhang. Dingchu Zhang, Xixi Wu, Yong Jiang, Ming Yan, Pengjun Xie, Fei Huang, and Jingren Zhou. Websailor: Navigating super- human reasoning for web agent, 2025a,
absg///a/////// /2077. 02592
Wenjun Li, Zhi Chen, Jingru Lin, Hannan Cao, Wei Han, Sheng Liang. Zhi Zhang, Kuicai Dong, Dexun Li, Chen Zhang, et al. Reinforcement learning foundations for deep research systems: A survey. arXiv preprint arXiv:2509.06733, 2025b.
Xiaoxi Li, Guanting Dong, Jiajie Jin, Yuyao Zhang, Yujia Zhou, Yutao Zhu, Peitian Zhang, and Zhicheng Dou. Search-ol: Agentic search-enhanced large reasoning models, 2025c. URL
https: //rsiv//axivvv./ org/ altp://s///// 250..
Xiaoxi Li, Jiajie Jin, Guanting Dong, Hongjin Qian, Yutao Zhu, Yongkang Wu, Ji-Rong Wen, and Zhicheng Dou. Webthinker: Empowering large reasoning models with deep research capability, 2025d. URL
21776
Yangning Li, Yinghui Li, Xinyu Wang. Yong Jiang, Zhen Zhang, Xinran Zheng, Hui Wang, Hai- Tao Zheng, Pengjun Xie, Philip S. Yu, Fei Huang, and Jingren Zhou. Benchmarking multimodal retrieval augmented generation with dynamic vqa dataset and self-adaptive planning agent, 2024a.
URL httts::/ppptaiiaeee org/ abaaabss22222 02937
Zelong Li, Shuyuan Xu, Kai Mei, Wenyue Hua, Balaji Rama, Om Raheja, Hao Wang, He Zhu, and Yongfeng Zhang. AutoFlow: Automated workflow generation for large language model agents. arXiv preprint arXiv:2407.12821, 2024b.
Grégoire Mialon, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, and Thomas Scialom. Gaia: benchmark for general ai assistants, 2023. URL https:://axxiy
abs 0////2311.11199
OpenAl. Gpt-4o mini: Advancing cost-efficient intelligence, 2024. URL https://openai.
OpenAl. Deep research system card, 2025a. URL
com/
deep research system card.pds Technical Report/System Documentation.
OpenAl. Introducing deep research, 2025b. URI. Lntroouuciggddeee-eeeee
Accessed: 2025-08-25.
Jiahao Qiu, Xuan Qi, Tongcheng Zhang. Xinzhe Juan, Jiacheng Guo, Yifu Lu, Yimin Wang, Zixin Yao. Qihan Ren, Xun Jiang, et al. Alita: Generalist agent enabling scalable agentic reasoning with minimal predefinition and maximal self-evolution. arXiv preprint arXiv:2505.20286 2025.
David Rein, Betty Li Hou, Asa Cooper Stickland, Jackson Petty, Richard Yuanzhe Pang, Julien Dirani, Julian Michael, and Samuel R. Bowman. Gpga: A graduate-level google-proof q&a benchmark, 2023. URL http::tttt//att //rriii///xvvvva///a or. abs 12111.12022
Huatong Song, Jinhao Jiang, Yingqian Min, Jie Chen, Zhipeng Chen, Wayne Xin Zhao Lei Fang, and Ji-Rong Wen. RI-searcher: Incentivizing the search capability in 1lms via reinforcement learning, 2025. URL IRLlttts:://aaa
org/ abs abs/abss.35. 2503. 20005555..522222
Jiabin Tang, Tianyu Fan, and Chao Huang. Autoagent: A fully-automated and zero-code framework for Ilm agents, 2025a. URL / abs/ 05957
wrw.a. org
Xiangru Tang, Tianrui Qin, Tianhao Peng, Ziyang Zhou, Daniel Shao, Tingting Du, Xinming Wei, Peng Xia, Fang Wu, He Zhu, Ge Zhang, Jiaheng Liu, Xingyao Wang, Sirui Hong, Chenglin Wu, Hao Cheng, Chi Wang, and Wangchunshu Zhou. Agent kb: Leveraging cross domain experience for agentic problem solving, 2025b. URL httpt: http::///aavvvvea wwtp://gg/abbbaaaeeee
abs 2507. /Rt.ttps./x....oooo//o/. 252..06229999
Zhengwei Tao, Jialong WU, Wenbiao Yin, Junkai Zhang, Baixuan Li, Haiyang Shen, Kuan Li, Liwen Zhang, Xinyu Wang, Yong Jiang, Pengjun Xie, Fei Huang, and Jingren Zhou. Web- shaper: Agentically data symthesizing via information-seeking formalization, 2025. URL
12

---

Published as a conference paper at ICLR 2026
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. 12516
Jialong Wu, Baixuan Li, Rumnan Fang, Wenbiao Yin, Liwen Zhang, Zhengwei Tao, Dingchu Zhang, Zekun Xi, Gang Fu, Yong Jiang, Pengjun Xie, Fei Huang, and Jingren Zhou. Webdancer: Towards autonomous information seeking agency, 2025a. URL http:p:://axxiv.orggg org.
22648
Jialong Wu, Wenbiao Yin, Yong Jiang, Zhenglin Wang, Zekun Xi, Runnan Fang. Linhai Zhang, Yulan He, Deyu Zhou, Pengjun Xie, and Fei Huang. WebWalker: Benchmarking LLMs in web traversal. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume I: Long Papers). pp. 10290 10305, Vienna, Austria, jul 2025b. Association for Com- putational Linguistics. ISBN 979- 89166-51-77... doi: 10. 18253// lon.o..558.. URL attts::/acclanin www.antthhooo.....ooooooooooooom www.y.org/2225.cc 508/
Zhitian Xie, Qintong Wu, Chengyue Yu, Chenyi Zhuang, and Jinjie Gu. Aworld: Dynamic multi-agent system with stable maneuvering for robust gaia problem solving. arXiv preprint arXiv:2508. 09889, 2025.
Renjun Xu and Jingwen Peng. A comprehensive survey of deep research: Systems, methodologies, and applications, 2025. URL
wtt.orggggb////////e 12594
Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, and Yongfeng Zhang. A-mem: Agentic memory for LLM agents. In The Thirty-ninth Annual Conference on Neural Information Process- ing Systems, 2025. URL /tttps://operreviiee
net/ Furum? F=F F.FFiMMMMge..
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, Yugiong Liu, Zekun Wang, Zeyu Cui, Zhennu Zhang, Zhipeng Zhou, and Zihan Qiu. Qwen3 technical report, 2025a. URL https: /tt.ria.vvv///////////..//..aa.. wrgg abs 2201/555500333
An Yang. Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, Huan Lin, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang. Jingren Zhou, Junyang Lin, Kai Dang, Keming Lu, Keqin Bao, Kexin Yang, Le Yu, Mei Li, Mingfeng Xue, Pei Zhang, Qin Zhu, Rui Men, Runji Lin. Tianhao Li. Tianyi Tang, Tingyu Xia, Xingzhang Ren, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yu Wan, Yuqiong Liu, Zeyu Cui, Zhenru Zhang, and Zihan Qiu. Qwen2.5 technical report, 2025b. URL fttps:://arxin org/ abs 2412.122111 15115
Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models, 2023. URL https://arxix:
org/abs/2210. 03629
Guibin Zhang, Muxin Fu, Kun Wang, Guancheng Wan, Miao Yu, and Shuicheng YAN. G-memory: Tracing hierarchical memory for multi-agent systems, In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025a. httphtttss///ppeeeeet
net forum?
Id=mnIAp3cVSD
Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, Xiong-Hui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, Bingnan Zheng, Bang Liu, Yuyu Luo, and Chenglin Wu. AFlow: Automating agentic workflow generation. In The Thirteenth International Confer- ence on Learning Representations, 2025b. URL htttps://opeeeee//////
net/ forum?idd
25VVAKmm
13

---

Published as a conference paper at ICLR 2026
Chengqi Zheng, Jianda Chen, Yueming Lyu, Wen Zheng Terence Ng, Haopeng Zhang, Yew-Soon Ong. Ivor Tsang, and Haiyan Yin. Mermaidflow: Redefining agentic workflow generation via safety-constraiied evolutionary programming. arXiv preprint arXiv:2505.22967, 2025a. URL
htttps://axxiv.. /ttp///wwww...rraa/////.....2.
Yuxiang Zheng, Dayuan Fu, Xiangkun Hu, Xiaojie Cai, Lyumanshan Ye, Pengrui Lu, and Pengfei Liu. Deepresearcher: Scaling deep research via reinforcement learning in real-world environ- ments, 2025b. URL httph: arxiv. org/ /ttpbb//25050 03160
14

---

Published as a conference paper at ICLR 2026
A
DEFINITIONS AND NOTATIONS
The notations and definitions are presented in Table
Table 4: Notations and definitions used in the FlowSearcher methodology.
Notation
Definition
Q
The original query (main research question).
The predicted answer aggregated from workflow executions.
f4s
Sub-question at step i, decomposed from Q.
== {mi, GiD
Solution trajectory consisting of sub-questions and their workflow graphs.
g.
Workflow graph composed of building blocks (e.g., search, browse, summarize).
(a, o)
Node representation: action sequence a and corresponding outputs
M
Structured hierarchical memory storing past task, graph, and node traces.
Prompt for sub-question decomposition.
0g
Prompt for workflow synthesis.
P(T MM)
Probability of generating a trajectory given query Q and initial mem- ory Moo
P(a, Mi-M
Probability of node execution (action-output sequence) conditioned on sub-question and memory.
B INFERENCE PROCESS
This section we going walk through typical pipeline of solving a task by FlowSearcher.
B. HIGH LEVEL: NEXT SUB-QUESTION GENERATION AND MEMORY-GUIDED WORKFLOW SYNTIESIS
Sub-question generation and experience retrieval. The inference procedure is organized in stepwise manner. At the beginning of each step, a sub-question is generated based on the aggregated observations and the original query. To guide the orchestration, three entries from the execution log are retrieved from memory. These logs are processed and passed to the instructor module, which distills them into at most three concise and transferable experiences on workflow orchestration. The resulting experiences then incorporated into the orchestrator prompt.
Workflow graph orchestration and validation. Once the workflow graph, represented YAML, orchestrated, the system's graph validation module is invoked to verify whether the generated graph is valid (see Section C.2). validation fails, the orchestrator is prompted to regenerate the graph using the provided error message.
Conversion to executable code. After valid workflow is obtained, the converter module translates the YAML graph specification into executable Python files.
Workspace creation. Finally, a workspace folder created, into which all relevant files are stored, including the pre-execution metadata (original question, current sub-question, aggregated observa- tions, and tool-call details), the YAML configuration file, and the generated executables.
A high-level process demonstration is presented in Algorithm
15

---

Published as a conference paper at ICLR 2026
Algorithm FlowSearcher High-Level Inference Process
Require: Original Query Qorig
Ensure: Final Answer final
1: Initialize Aggregated Observations O 0
2: Fimal_ansuse www.werre-ooudddeeeeee. + false
3: while not final answer -ound do
Sub-question Generation and Memory-Guided Workflow Synthesis-
4: Generate sub-question sub based on Qorig and O.
5:
Retrieve execution logs from memory and distill into experiences F.
Workflow Graph Orckestration and Validation repeat
6:
7:
Orchestrate workflow graph G (YAML) using Qsat and E. is _validd arror_msg + ValidateGraph(GG.
8:
9:
not is_valid then
10:
Regenerate G with feedback from error Jssg. end
11:
12:
until is_valid
Conversion and Workspace Setup
13:
Convert valid graph G into executable Python files Fezee-
14:
Create workspace and store metadata, G, and Fexee-
15:
Call EXECUTE WIRKUUTWWRKKLLOWCC (Quab, Fezecs O)
Final Verification Determine if Qorig can be answered with the updated observations O.
17:
if Qorig is answerable then
final Lnnswer foond true
19: end if
If not, the loop continues to generate the next sub-question.
20:
end while
Execution and Result Aggregation
21: Invoke the Finalizer Block.
22: Identify the most relevant references Ryat within O.
23: Verify factual consistency between Ry and the summary in O.
24: Synthesize the final answer A final by reasoning the verified summary.
25: return A Ainal
16

---

Published as a conference paper at ICLR 2026
B.2 Low LEVEL: MEMORY-GUIDER WORKELOW EXECUTION
Execution of Searcher Blocks. Searcher blocks are responsible for generating search keywords, performing searches, and selecting relevant search results. URLs from the selected results are passed directly to the browser blocks for further processing.
Execution of Browser Blocks. Browser blocks navigate the webpages provided by the searcher blocks and extract information from them. In the case of in-depth browsing, additional links on the page are also collected. All extracted content is organized as list of references, each containing the original information and its source URL.
Execution of Summarizer Blocks. Summarizer blocks select the most relevant references and produce concise summary that addresses the current sub-question and contributes to the overall answer. The updated summary is then stored for subsequent use.
Verification Process
1. Sub-question Verification: Check if the current sub-question has been successfully ad- dressed.
If verification fails, repeat the workflow until conditions are met.
2. Final Verification: If the sub-question is verified, determine whether the original question can now be answered:
yes, activate the aggregation module to produce the final answer.
If no, generate the next sub-question and continue the high-level control flow.
We present the low-level process as shown in Algorithm 2
Algorithm FlowSearcher Low-Level Workflow Execution
procedure EXECUTEWORKFLOWWE sub: Fewee: O)
2:
repeat
Block Execution
3:
Searcher Blocks: Generate keywords, perform search, and select results (URLs).
4: Browser Blocks: Navigate URLs, extract content, and organize as references.
5: Summarizer Blocks: Select relevant references and generate summary for Qoub.
6: Store the new summary and references the aggregated observations O.
Sub-question Verification
7: Check if Qaub has been successfully addressed by the generated summary.
8: until Q addressed
9:
end procedure
B.3 EXECUTION AND RESULT AGGREGATION
When the accumulated summary and references pass the final verification stage, the finalizer block invoked to derive a concise answer to the original query. The finalizer operates in two steps. First, it identifies the subset of references most relevant the query and verifies the factual consistency between these references and the constructed summary. Subsequently. reasons over the verified portion of the summary and synthesizes concise, accurate answer.
C IMPLEMENTATION DETAILS
FlowSearcher implemented through Langgrapi In this section, we present the implementation details of FlowSearcher.
C.1 BUILDING BLOCKS
In FlowSearcher, building blocks are categorized into these types:
https//wwww..nggchhin.cmmgggggg
17

---

Published as a conference paper at ICLR 2026
1. Searcher: Responsible for retrieving relevant information from external sources, such databases, search engines, or knowledge bases, based on the current query or sub-question. It provides the raw material for further reasoning and analysis.
2. Browser: Navigates through the retrieved resources to extract structured and unstructured informa- tion. The browser interprets web pages, documents, or other content, and transforms them into form usable by downstream modules.
Summarizer: Condenses the collected information into concise, coherent summaries. filters out irrelevant details, highlights key points, and prepares the content for verification and higher-level reasoning.
4. Verifier:
Checks the factuality and consistency of the summarized content against the original sources or cross-references. It ensures that the information used for reasoning is accurate and trust- worthy.
5. Finalizer:
Integrates verified information to produce coherent and concise answer to the main query. The finalizer synthesizes evidence from multiple sources and ensures that the resulting answer is accurate, complete, and well-structured.
Performs high-level reasoning and problem-solving. It can generate sub-questions. plan multi-step workflows, and determine which tools or blocks should be invoked to solve complex tasks.
Thinker:
Now are presenting the two most important functional block types: Searcher and Browser.
C.I.1 SEARCHER-TYL TYPE BLOCKS
The searcher blocks receive the original question (OverallState messages [C] cont ent) and the current summary @Dverallstate current. s summa ry) as input. Upon completion of their execution, all fields within SearcherState are updated to reflect the results of the search process. The state structure demonstrated in C.4
General Searcher first generates up to 5 search queries, performs search and collects search results for each query. The prompts for generating search queries and collecting search results for each query are follows:
Search Query Generation Prompt
You are a query writer agent that operates a workflow that solves a question step by step.
You are given:
The main question
The sub-goal of the current step
Some used keywords or phrases used the previous searches
A summary containing current found information
** Your *a
The current summary (if provided) fails to reach the sub-gon goal
Output some keywords or phrases that have the potential to find other useful information outside of the current summary and related to the sub-goal Don't output more than (query count) keywords or phrases
**Extra *
If no used keywords and summary provided, that means you need think about the first keywords to search
The current date **current_date*** be careful when it's necessary to specify time in the search keywords
experiences
Main question:
Sub-goal:
18

---

Published as a conference paper at ICLR 2026
(sub Juub_question]
Used search queries:
(used search keywords and phrases)
Current summary:
Search Result Selection Prompt
You search result selection agent that operates in workflow that solves question step by step.
You are given:
The main question
The sub-goal of the current step
Search results obtained by searching for (query)
**
Your tasks:**
Select relevant search results and only output their URLs and snippets
no relevant search results provided, output an empty list
The current date is **{curren ]ate) **, be careful when the question requires updated information
(experiences)
Main question:
poriginal_questionn
Sub-goal:
{sub_quessi {ub_qquettion]
Search results:
)esults)
First-Hit Searcher only generates one search query and performs one search, the search result selection process is the same General Searcher. The query generation prompt is follows:
Goal Break-Down Prompt
You query writer agent that operates in workflow that solves question step by step. You are given:
The main question
The sub-goal the current step
Some used keywords or phrases used in the previous searches
A summary containing current found information
*ourur tasks;*
The current summary (if provided) fails to answer the sub-goal
Output one search query that has the potential find other useful information outside of the current summary and related to the sub-goal **Extra **
If no used keywords and summary provided, that means you need to think about the first keyword to search
The current date is ** **(current date]** **, be careful when it's necessary to specify time in the search keyword
19

---

Published as a conference paper at ICLR 2026
(experiences)
Main question:
Sub-goal: {sub queb_qqestion]
Used search queries:
www.serrrc..kwrrrra..o phraassss
Current summary: (current summary)
Parallel Searcher. Specifically, given sub-goal, the block first decomposes it into structured list of finer-grained goals that can each be independently addressed. For every goal, the block automatically generates one more search queries tailored to the goal's intent and retrieves the corresponding candidate results. To ensure consistency and reliability, all retrieved outputs are sub- sequently processed through unified result selection procedure that ranks, filters, and consolidates the candidate results into a coherent evidence set. This design enables the block to operate as a self-containee unit that bridges abstract sub-goals with concrete, high-quality information.
Break-down Goal Prompt
You are helper agent breaking down goal into list of ready-to-search sub-goaks that operates in workflow that solves question step by step. The workflow is solving the question using search engine.
You are given:
The main question
The sub-goal of the current step
Your ta
Break down the current sub-goal into a list of ready-to-search sub-goals If the sub-goal is already specific enough conduct search it, just output the sub-goal as a single item in the list
The current date is ** **(current.date] be careful when the question requires updated information
Main question:
{question) }
Sub-goal:
{sub-goal}
Example:
Main question: "Help me find character who constantly breaks the fouth wall and has backstory of being saved by an ascetic"
Sub-goal: "Find which characters from this list have backstory of being saved by an ascetic:
A. B, C, D. E"
List of ready-to-searte search sub-goals:
"Find A's backstory and determine if A is saved by ascetic".
"Find B's backstory and determine if B is saved by ascetic"
"Find C's backstory and determine C is saved by an ascetic"
"Find D's backstory and determine if D is saved by an ascetic".
"Find E's backstory and determine if E is saved by an ascetic"
20

---

Published as a conference paper at ICLR 2026
C.1.2 BROWSER-TYPE BLOCKS
The browser blocks receive search results from the orchestrated searcher blocks, visit the URLs, and extract relevant information. Webpage content is split into chunks, and each step, browser blocks must decide whether to continue visiting the next chunk.
General Browser. The general browser block selects up five URLs and sequentially extracts information from each page it visits.
URL Selection Prompt
You are agent that selects next relevant URLs to browse when solving a question step by step.
You given:
-The main question
'The sub-goal of the current step
A list of URLs and their snippets **Your tasks:#
Check through the list of URLs and their snippets and determine what kind of information is being provided relevant to the sub-goal
Select the URLs that have the potential to provide useful information relevant to the sub-goal, you select them all if you think they are all relevant
The current date is ** * (current_ } be careful when the question requires updated infor- mation
**Extra notes:**
**RRITICAL: Pay close attention specific requirements in the question** (c.g.. "official script", "official website", "primary source", "government data", etc.)
**Prorritize URLs that match the specific source requirements mentioned in the question** If the question asks for "official" sources, prioritize URLs from official organizations, gov- ernment sites, or primary sources over fan sites, transcripts, or secondary sources
**Souree Priority Guidelines:
Official/Primary sources:
Government sites (ggov,, official organization websites, original
publishers, etc.
Secondary sources: News sites, academic sites, established databases
Tertiary sources: Fan sites, transcripts, wikis, forums (use only if no better sources available) (experiences)
Main question:
(original question] Sub-goal:
(sub questionn List of URLs and their snippets:
Information Extraction Prompt
You are an information extractor agent that operates a workflow that solves question step by step.
You are given:
The main question
TTee sub-goal the current step
-Part of the content of webpage, you will be given the number of parts and the index of the
current part *ourur tasks:*
Extract ONLY information that directly relevant to answering the sub-goal or the main question
Be selective and focused avoid extracting tangential information like version histories, con- tributor lists, or general background unless specifically needed
21

---

Published as a conference paper at ICLR 2026
The current date ** (current_date) ** be careful when the question requires updated infor- mation
**What NOT to extract:**
Version histories or release notes unless the question specifically asks about versions
Contributor lists or acknowledgments unless the question asks about contributors
General background information that doesn't 't directly relate to the question
Marketing content, testimonials, or promotional material
Navigation elements, headers, footers, UI text
Repeated information that has already been captured
Main question:
Sub-goal:
{uu_qquestion] Webpage content:
(webpage content]
First-Hit Browser. The first-hit browser block selects the single most reliable URL, and stops im- mediately after retrieving the relevant information.
First-hit hit Information Extraction Prompt
You are an information extractor agent that operates in workflow that solves question step by step.
You are given:
The main question
The sub-goal of the current step
Part of the content of webpage, you will be given the number of parts and the index of the current part Yourur task:
Browse through the webpage content and look for the information that contains the answer to the sub-goal or the original question Extract that information #*in its ORIGINAL FORM, don't paraphrase modify the infor- *ation**
When you can't t find the information from the current part, decide whether you should con- tinue browsing the next part of the webpage
The current date is ** [current date] ** be careful when the question requires updated infor- mation
**Extra #
If no information founded, leave the information field as ***
Make sure the answer can be clearly extracted from the information without any ambiguity Main question:
(original.question) } Sub-goal:
(sub question} Wehpage content:
ceeepagee.conentt.arg
Parallel Browser. The parallel browser block visits all URLs returned by the current search results concurrently. It uses the same prompts as General Browser with multi-threadiig
In-depth Browser. The in-depth browser block selects to three root URLs, extracts both rele- vant URLs and information from each page, maintains a queue of discovered pages, and continues visiting until the queue is empty or predefined visit limit is reached.
22

---

Published as a conference paper at ICLR 2026
Root URL Selection Prompt
You are helper agent that selects the root URLs browse when solving a question step by step.
You are given:
A question
The sub-goal the current step
A list of URLs and their snippets
**Your tasks:*
Select the root URLs that potentially have tabs and buttons to direct to pages with useful in- formation relevant to the sub-goal
If you think some URLs directly provide the information you need, you also select them The current date is "=ccurrent_date) , be careful when the question requires updated infor- mation ** Extra notes:**
Pay close attention to specific requirements in the question** (e.g., "official script", "official website", "primary source", "govermment data". etc.)
*CRITICAL:
**Piorittzee URLs that match the specific source requirements mentioned in the question**
If the question asks for "official" sources, prioritize URLs from official organizations, gov- ermment sites, or primary sources over fan sites, transcripts, or secondary sources
{experiences}
Question:
{question] Sub-goal:
goab_goal> List of URLs and their snippets:
(list of urls and snippets}
In-depth Browsing Prompt
You helper agent that browses the web to find useful information when solving question
step by step.
You given:
A question
The sub-ge of the current step
A part of the content of a webpage
Yourur tasks:
Extract ALL information that could be relevant to answering the question or achieving the sub-goal
Look for specific details like names, numbers, dates, relationships, lists, tables, and factual data
Pay special attention to structured data (tables, lists, rosters, directories) that might contain answers
Find links present in the webpage that can potentially direct to pages with useful information
relevant to the sub-goal
You given the part index and the total number of parts of the webpage
You need to decide whether to keep browsing the next part of the webpage if there is still part left
Be generous in what you consider "relevant" include information that might be indirectly useful
The current date is ** (currentt_aate **, #, be careful when the question requires updated infor- mation
Question:
{question]
Sub-goal:
23

---

Published as a conference paper at ICLR 2026
(sub-goal)
Webpage content: (webpage_content)
C.2 QUERY WRITER AND ORCHESTRATOR
The query writer is in charge of decomposing and generating the next query based the current information summary and the original question.
Next Query Writer Prompt
You are an advisor agent that operates a workflow that solves a question step by step using
search engine.
You are given:
A question
summary containing the current found information
** YYuur tasks:*
Review the current summary to see what information has already been found Identify what key information is still missing answer the main question completely
Write comprehensive aob-goal that encompasses all the information agents can start to find given the summary's context
If no summary provided, start with the first logical sub-goal needed to answer the main ques- tion, the first sub-goal can be exactly the same as the main question, if you think the main question is focused enough on one specific goal *#Instructions:** **
Create sub-goal that maximizes information gathering potential don't limit the scope (Ex- ample: "Find list...")
When there are several possible sub-goals, choose the one that is easier to reach using search engine
However, the new sub-goal still needs to be based on the current summary' context, missing context would mislead the workflow
The sub-goal must encompass queries about all relevant information that can be discovered based on the current summary's ' context
Stay focused on the main question your sub-goal should be necessary step toward answer- ing it
Use information from the current summary context for the next sub-goal (e.g., if the sum- mary identifies city, use that city name in your next goal) The current date ** [current ** #* be careful when the question requires updated infor- mation
** Key principle:** Always use specific information from the current summary in your next sub-goal rather than generic placeholders.
Question:
(question) Summary:
(current summary)
The orchestrator in charge of orchestrate the workflow from a pre-defined set of building blocks.
Workflow Orchestration Prompt
You orchestrator agent that designs search workflows answer sub-questions using specialized building blocks.
** **Deciion Logic:**
24

---

Published as a conference paper at ICLR 2026
Can sub-goal be answered without web searches? - ""Thinner-Summarizer"""
Need new information from web? + SSearcher-Browser-Suee
ENCOURAGE DIVERSE COMBINATIONS
**Searcher Options** * serreserr searcher, advanced_searchhe
**Browser Options*** * hast_browser, browser,
deep browser
** Summmarizer Options**: summarizer, advanced _smmmarizer
REQUIREMENTS
*uunction names must match exact "block_name' from block list**
**Output complete YAML with "'yaml and "* tags
**DO NOT modify the rest of the YAML template only fill the highlighteddplaccholderr parts**
**ONLY use these node types*#: 'searcher', 'browser', 'summarizer', 'thinker' (and their variants)
**DO NOT us 'verifier' or 'finalizer' these are handled automatically
**YAML template:**
"'yaml
{yaml template) {experiences) IIMPRTTTTT** Only modify the highlighted/place-
holder sections in the template above. The rest of the YAML structure must remain unchanged.
**The original question:**
(original question] ** current sub-goal:
{question) * **Current summary of the found information:** ** (current >ummaryy **List of pre-defined building blocks:** [fist.o..building bllodigg
C.3 YAML CONVERTER MODULE
In FlowSeecher, the orchestrator orchestrates the workflows by fill in YAML template that already contains the verification logic as below:
YAML Template
nodes:
** Your selected building *
name: verifirr
function: verifier config:
verifier variant: sub
name: final verifier
function: verifier config:
verifier-variants final
name: finalizer
function: finalizer
edges:
START - **The first building block to execute when solving the question**
**
Your orchestrated edges**
**The last building block to execute when solving the question** ** sub. verifier
finalizer END
conditional.edee
from: sub_verifier
condition: state.get( saatc.et((subb.vet vebiviifieed"
25

---

Published as a conference paper at ICLR 2026
routes:
false: **The first building block to execute when solving the question**
true: final verifier
from: final_verifies
condition: state.get( verifie")
routes:
false: END
true: finalizer
C.4 AGENTIC WORKFLOW CREATION AND EXECUTION
The workflow is created state graph with every agentic action altering part of fields of an overall state object.
Agentic Workflow State
Overall State:
messages: list of messages (auto-append new messages)
current sub question: string
current wtw.suuuuuuuuoa.a..eeeeerrss wtliguuiineeteaatiiieeo
ittration: integer
current.sume summary: string
final answer: string
sub verified: boolean
veril.ve: boolean
searcher.stane state: SearcherState (updated automatically)
browser
state: state: BrowserState (updated automatically)
instruction.state: InstructionState
SearcherState:
search_count integer
used keywors: list of strings
history_search searrc.results: list of SearchResult
search results: list of SearchResult
search_cacher dictionary
BrowserState:
visit_count: integer
Usited_urls: list of strings
history found references: list of Reference
found references: list of Reference
iisitccacher dictionary
InstructionState:
orchestrator instructions: list of strings
searcher instructions: list of strings
jonsurrinstructions::
of strings
When a workflow is successfully generated, a folder named "workspace" will be created with graph settings and executables. When workflow is executed successfully, the final state is saved to the same "workspace" folder.
The structure of the folder is follows:
26

---

Published as a conference paper at ICLR 2026
Workspace Structure after Successful Execution
sample.workspace/
jffer.state..jon before.state. json graph.py graph. yaml
run.py
C.5 MEMORY STRUCTURE AND PROMPT INJECTION
FlowSearcher maintains a multi-level memory structured as the below schema:
FlowSearcher Execution Memory
Overall State:
execution id: string
question: string
sub question: string
before before-summaan summary: string
summary: string
can answennwwuu auuuser.su..uuustio::
qqestion: boolean
can answer question: boolean
workflow: string (YAMI. representation)
paarcher_xecuttio_meenne
SearcherficcuttonMeenrry (updated automatically)
browser.executine : BrowsefExcccttionMMemrr (updated automatically)
question embedding: list of floats
sub wtw..guionn.eeediiiiiiee embedding: list of floats
SearcherrxxeuttinMeenn:::
search_count integer
new www.keywords.addee addee:: list of strings
new www.search_resulte list of SearchResult
BrowserrxeeutionMemmry:
visit_count: integer
new.visited.urg .urls: list of strings
new new.references list of Reference
When a new sub-query generated, we retrieve the relevant memory entries with weighted sum of main question and sub-question similarity with default weights set to 0.5 and 0.5.
Then we pass the graph-level and node-level traces to the instructor module. The trace schemas are as follows:
Orchestrator Execution History Template
Original question: (question)
Sub-goal: (sub_goal)
Before summary: [pefore_summary)
After summary: (after_summary)
Orchestrated workflow: [workflow)
Successful: (successful)
27

---

Published as a conference paper at ICLR 2026
Search Execution History Template
Original question: (question)
Sub-goal: (sub_goal)
Search keywords: (search [eaarch_eeywods]]
Search results: seearch_reeulle Successful: (successful)
Browse Execution History Template
Original question: (question)
Sub-goal: (sub_goai)
New found references: Lnew_found_referrness Successful: (succesaful)
Then, pass the history traces of these format the instructor module, gain the actionable expe- riences and inject them to corresponding prompts' placeholders.
D CASE STUDY
In this section, we present two specific cases of our system performing different types of tasks with GPT-4o-mini backbone.
D.1 EXAMPLE OF PERFORMING WEB NAVIGATION TASK
Below is example exccution of web navigation task from GPT-4o-mini backbone. The workflow settings are First-hit Searcher + In-depth Browser + General Summarizer.
Example Web Navigation Task
Original Question: According to GitHub, when was the Regression label added to the oldest closed numpy polynomial issue, in MM/DD/VD /Y format?
Summary from Previous Steps: found a filtered GitHub Issues view for NumPy repos- itory, showing issues labeled "06 Regression" that are closed. This label is used to track regressions, i.c, cases where something that previously worked in NumPy became broken in later version. The results limited the first page of closed regression issues, only subset is visible.
Current Sub-goal:
Identify the oldest
issue
involving the component
numpy compy-polie www moolynoial..
Orchestrated Workflow: First-hit Searcher In-depth Browser General Summarizer.
Execution Process:
First-hit Searcher performs a search: numpy polynomial issues Regression label GitHub
In In-depth Browser processes the Regression label issue page:
found page button: [20]
navigated the target page
found link to the oldest issue: Issue #291
visited the link
extracted information
General Summa r zer incrementally updates the summary: ... The oldest closed Regression issue on GitHub #291, opened on Jun 5, 2012. However, this issue does not appear to be directly relevant to numpy polynomial. (A new iteration started.)
28

---

Published as a conference paper at ICLR 2026
D.2 EXAMPLE OF PERFORMING COMPREHENSIVE SURVEYING TASK
Below is an example execution of performing a comprehensive surveying task, the workflow settings Advanced Searcher + Advanced Browser + Advanced Summarizer.
Example Comprehensive Surveying Task
Original Question: An African author tragically passed away in tragic road accident. As a child, he'd d wanted to police officer. He lectured at a private university from 2018 until his death. In 2018, this author spoke about writing stories that have sell by date in interview. One of his books was selected to be a compulsory school reading in an African country in 2017. Which years did this author work
probation officer?
Summary from Previous Steps: The initial step is to deconstruct the user's query to iden- tify the author in question. The key identifying facts are: an African author who died in road accident, lectured at private university from 2018 until his death, had a book become compulsory reading an African country in 2017, and gave a specific interview in 2018. The final goal is to determine the years this author worked as probation officer.
Current Sub-goal: Find a list of Arican writers who had lecturer career.
Orchestrated Workflow: Advanced Searcher + Advanced Browser Advanced Summarizer.
Execution Process:
Advanced Searche: performs 25 searches: "African author lecturer died in acci- dent", "Nigerian author book compulsory reading 2017", "Pius Adesanmi biography", "Pius Adesanmi career", "Pius Adesanmi probation officer employment history"
Advanced Browser processes the 58 pages:
found informations from 25 pages:
Pius Adesanmi was a Nigerian-Canadinn author and professor at Carleton Univer- sity. He died in the Ethiopian Airlines Flight 302 crash March 10, 2019. He was an active lecturer in 2018 until his death. His book "Naija No Dey Carry Last" was highly acclaimed and recommended for school curricula in Nigeria. A review of his CV and multiple biographies shows career exclusively in academia and literature, with no mention him working as a probation officer.
Advanced Summarizes zer ensembles and updates the summary: The author described is identified as Pius Adesanmi based on his profile as a Nigerian author, lecturer, the timing of his death in accident, and the status of his book. After thorough review of his employment history, there is no evidence that he ever worked as a probation officer. The premise of the original question appears to be incorrect. (A new iteration started.)
E ACKNOWLEDGMENT ON LLM USAGE
We acknowledged the use of large language models (LLMs) specifically for language polishing, rephrasing, and improving readability, which helped us present our demonstrations more clearly. These tools were employed solely for stylistic refinement and did not contribute to the conceptual- ization, design, or methodological development of this work. All ideas, experiments, analyses, and conclusions remain entirely the result of the authors' own efforts.
29


Reviews:
[{"review_id": "b71rYJbEtC", "reviewer": "Reviewer_oxdo", "summary": "The paper introduces FlowSearcher, a web search framework that performs dynamic workflow generation overcoming the limitations of step-wise workflows prevalent in React-style web search agents. Further, the approach retrieves structured workflows from previous episodes to enable to the model to leverage insights from past experiences. Experimental results show that the proposed memory-augmented workflow design approach outperforms vanilla and trained React-style agentic approaches on various Deep Research benchmarks.", "questions": "1) The authors store both successful and unsuccessful episodes in the memory. What doesthe performance looks like from using only successful vs only unsuccessful episodes?", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "1) The methodology for generating structured workflows and storing historic episodes is well-designed and thoroughly explained.\n2) The approach to leverage past workflows by generating insights from these experiences is very interesting and can generalize to other agentic tasks, apart from Deep Research.", "weaknesses": "1) The ablation analysis (mainly centered around workflow generation) does not show any controlled experiments demonstrating the benefit of incorporating memory by leveraging historic episodes, which has been claimed as one of the key contributions of the paper. There are a lot of questions here that need to be answered. For e.g. How many structured workflows from past episodes are useful? \n\n2) The paper doesn't discuss the cost/latency considerations of the proposed approach. Do the new workflows have more tool calls / steps than existing React-sytle approches? Also, how much cost/token usage does the memory creation + augmentation add to overall inference cost.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "3BoOTB576B", "reviewer": "Reviewer_kvwa", "summary": "It decomposes a complex query into subgoals and for each of them synthesizes a tailored workflow graph that determines how to search, browse, summarize, or verify information. A contribution here is its hierarchical memory, storing past workflows and tool executions at three levels and reuses them to guide future planning and execution. The performance of the system is significantly higher as compared to baselines considered.", "questions": "Please see Weaknesses", "limitations": "", "rating": 6, "confidence": 3, "soundness": 2, "presentation": 2, "contribution": 3, "strengths": "- I like how the paper brings in a multi-level memory which guides the synthesis and execution of future trajectories by using experience from the past\n- Further the paper brings in multiple different research principles such as self-evolution (reusing past experiences), tool reasoning, query decomposition and hierarchical planning, memory etc into a single system that works quite well\n- the results are quite impressive, as well the ablations are good enough\n\n\nThat being said, I have some concerns, please see the weakness section", "weaknesses": "1. The paper has a lot going on, and an illustrative example would help the reader. For example a simple illustration showing the structure of the memory visually would help a lot. It was hard to parse what the authors are trying to say at multiple places\n\n2. I want to see cost comparison here, because the context is much more dense (more tokens) than simple react - without seeing the cost and latency of doing this operation, it is hard to justify such a complicated system\n\n3. Line 118 - the authors claim that this offers a cost-effective solution - but if this only talks about cost as compared to train an agent, that argument ignores the long-term cost of inferencing with a complex system which has really long prompts. The overall token consumption could be really high. \n\n4. I have some serious concerns in the writing of the paper. I feel that multiple places could have been phrased in much simpler words , and are unnecessarily verbose, making it very difficult for a reader. (lines 46-49 for example). I would urge the authors to rephrase things to address a larger audience, at the current shape, it is quite hard to follow", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "W09spbmtup", "reviewer": "Reviewer_kcjm", "summary": "FlowSearcher introduces a novel framework for web information seeking that replaces rigid, linear tool-use patterns with dynamic, memory-guided workflow synthesis. It employs a hierarchical memory system to reuse past execution traces, enabling adaptive planning and execution for complex, multi-step queries. By learning from experience rather than relying on fine-tuning, FlowSearcher achieves strong performance across benchmarks like GAIA and BrowseComp.", "questions": "- How does FlowSearcher handle catastrophic memory accumulation or aliasing across unrelated tasks? Are there retrieval errors or long-term drift issues, and how are these handled? (For example, when the retrieved memory is wrong, or it needs a larger K in top-K retrieve algorithm)\n- Can this memory algorithm transform to general agentic tasks such as WebShop, WebArena?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "- It precisely identifies the rigidity and memorylessness of prevailing ReAct-style agents as a core bottleneck for complex web-search tasks.\n- A three-level (task/graph/node) compositional memory enables fine-grained reuse of both successful and failed execution traces, going far beyond simple retrieval augmentation.\n- Consistent gains over strong baselines (WebThinker, WebDancer, Search-o1) on GAIA, BrowseComp and GPQA-Diamond demonstrate clear practical impact.", "weaknesses": "- The memory-retrieval function uses a cosine similarity threshold that is fixed across all query types, it's not clear whether or not the  hyper-parameter works when transfer the framework to other domains.\n- Lack of cost and latency analysis as it's a prompt-based method and the context may be extremely long.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "5AlBhKdD8Z", "reviewer": "Reviewer_iEBS", "summary": "This paper introduces FlowSearcher, a framework designed to overcome the structural rigidity and lack of experience reuse in conventional ReAct-style web agents. The core idea is \"agentic workflow synthesis,\" where the system decomposes complex queries into sub-goals and dynamically orchestrates a tailored, non-linear workflow graph for each.\nA key innovation is its hierarchical memory (at task, graph, and node levels), which distills past execution traces into structured experience. An \"instructor\" module then uses these insights to guide both high-level workflow orchestration (structural design) and low-level tool execution (behavioral refinement).\nExperiments on GAIA, BrowseComp, and GPQA show that FlowSearcher consistently outperforms strong agentic baselines. The authors argue this demonstrates that structural flexibility, achieved via memory-guided planning, is more decisive and cost-efficient than expensive RL fine-tuning.", "questions": "Same as the weeknesses", "limitations": "", "rating": 4, "confidence": 4, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "- Flexible Workflow Synthesis: The paper effectively moves beyond rigid, linear ReAct-style paradigms. Its core contribution—dynamically synthesizing tailored workflow graphs for each sub-goal—provides significant structural flexibility to handle diverse and complex queries.\n\n- Novel Hierarchical Memory Mechanism: The introduction of a three-level (task, graph, node) memory is a key strength. This allows the agent to learn from structural experience (i.e., how it solved a problem), not just content, enabling genuine experience reuse and adaptation.\n\n- Strong Empirical Results without Fine-Tuning: FlowSearcher achieves consistent, significant gains over strong baselines on difficult benchmarks (GAIA, BrowseComp). It does so purely through experience-driven planning, demonstrating a more cost-efficient and scalable alternative to expensive RL fine-tuning methods.", "weaknesses": "1. Lack of Direct Efficiency Evaluation: The paper's primary argument for efficiency is one of cost-efficiency, asserting that its experience-driven planning approach avoids the high costs associated with RL fine-tuning (as seen in baselines like WebThinker-RL). While this is a valid point, the methodology (Section 2.1) also claims the system is designed to enhance \"efficiency and effectiveness\". However, the experimental results (Section 4) are entirely missing direct quantitative metrics to support this claim. There is no evaluation of:\n - End-to-end Latency: The total time taken to answer a query.\n - Token Cost: The total number of tokens consumed by the orchestrator, instructor, and executor modules.\n - Computational Steps: The total number of LLM inferences or tool calls required to reach a solution.\nWithout these metrics, it is impossible to assess whether the proposed hierarchical framework, with its added complexity of memory retrieval, instruction distillation, and graph synthesis, is actually more computationally efficient at runtime than a simpler, linear ReAct-style agent.\n\n2. Limited Novelty of Core Components: While the integration of the components is well-executed, the core ideas themselves: task decomposition, hierarchical memory, and DAG-based workflow execution, are not fundamentally new. The contribution appears to be more of a sophisticated engineering and system-building effort rather than the introduction of a novel algorithm or principle. The paper could be strengthened by more clearly positioning its contribution relative to existing works that use these individual concepts, justifying why this specific combination provides a breakthrough.\n\n3. Questionable Generalization and Over-reliance on Pre-defined Blocks: The system's entire capability is strictly bounded by its pre-defined library of \"building blocks.\" The ablation study (Table 2) demonstrates this clearly: when the set of available blocks is restricted, performance plummets. This raises two major concerns about generalization: (1) Task-level Generalization: It is unclear how FlowSearcher would perform on a fundamentally new task that requires a tool or workflow not representable by the existing blocks. (2) Block Synthesis: The framework does not include any mechanism for learning, discovering, or synthesizing new building blocks. This limits its long-term autonomy and adaptability.\n\n4. Vagueness of the \"Instructor\" Module: A critical component, the \"Instructor\" module (Section 2.3), is treated as a black box. This module is responsible for \"distilling\" raw execution traces from memory into \"concise insights\" that are then \"injected\" into the orchestrator and executor prompts. The paper fails to explain how this distillation process works. Is it another LLM call with a specific prompt? Is it a rule-based summarizer? This lack of detail obscures a key mechanism that bridges memory and action, making the work difficult to reproduce and its effectiveness hard to analyze.\n\n5. Unverified Effectiveness of Memory Retrieval: The entire \"memory-guided\" premise hinges on the ability of the retrieval mechanism (Section 2.2) to fetch relevant and high-quality experiences from memory. The paper states this is done via textual embedding similarity (a standard approach) but provides no analysis to validate its effectiveness. Key questions are left unanswered:\n- Retrieval Quality: What is the hit rate or precision@k of the memory retrieval?\n- Impact of Poor Retrieval: How does the system perform when retrieval fails or, worse, retrieves irrelevant or misleading (e.g., from a failed-but-structurally-similar task) exemplars? This could actively harm the orchestrator's planning.\nThe paper assumes the retrieved memory is always beneficial, which is hard to be true in practice.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)