TreeFlex: Policy-Directed Navigation of Resumable Search Trees

Why People Wanted It

An agent working on a long task accumulates context, and one unproductive line of work can consume that context without leaving a useful way back. A flat history makes every next step inherit the same past; folding history can compress it, but compression risks losing details needed to resume. So the real question was not simply how to fit more turns into a prompt. It was how to preserve alternative lines of work and let the agent decide which one deserves attention next.

The Core Move

TreeFlex saves each completed segment as a resumable node, then lets the model choose a node and instruction for the next segment. A node is a parent-linked record $v=(p_v,s_v,m_v,e_v)$: its parent, a summary card, model context, and environment state. The model navigates; the harness saves and restores.

Why the Tree Stores Segments, Not Turns

Now the version for readers who want more of the machinery: a node represents an entire Execution segment, not an individual model turn. The root stores the task and initial environment; each later node is created when a segment checkpoints or proposes a solution. The node’s parent records where that segment began, so selecting an older node can create a sibling branch rather than overwrite later work.

The saved state has distinct jobs. The card $s_v$ is the compact account Reflection can use to compare branches. The context state $m_v$ supplies the resumable conversation, and $e_v$ restores the task environment—for example, a repository snapshot. These are not interchangeable: a card helps choose a path, while the context and environment let Execution actually continue it.

Why Reflection and Execution See Different Things

Here is the part that gets technical: the two roles are the same model operating over different views and tool permissions. Reflection sees the task and a global record of node identifiers, parents, and cards, but not the raw context of each segment. Execution sees only the restored path to its selected node, that node’s environment, and its instruction. It uses domain tools and ends by checkpointing or committing a proposal.

This separation makes the choice of role consequential. Reflection can compare branch summaries and decide what to do next, but it cannot edit a proposal using evidence it cannot see. Execution has path-specific evidence and can do the work, but it cannot directly inspect competing branches. In deep research the path context uses cards; in SWE it uses raw context because diffs and error traces are harder to summarize faithfully.

Why Navigation Is the Search Policy

Now the deeper control-flow detail: Reflection’s action is either $\text{navigate}(v,i)$—resume node $v$ with instruction $i$—or, when a proposal is available, approve it. Navigation creates no node by itself. The next Execution segment creates a child of the chosen node when it checkpoints or commits; thus resuming the latest node deepens a line, while resuming an earlier one opens a sibling branch.

This lets one policy enact depth-first, breadth-first, or best-first behavior without the harness imposing a traversal rule. A proposal is saved as a node and remains available if Reflection chooses to keep searching; approval accepts that proposal unchanged and ends the search. The harness validates actions and restores state, but does not choose the next branch.

Minimal Causal Code

This plain loop makes the state transition visible: Reflection chooses a saved node; Execution works from that node’s path and environment; a checkpoint or proposal becomes a child. It omits prompts, tool validation, and context limits.

# nodes store parent, card, context, and environment
nodes = {"root": root_state}
pending_proposals = {}

while not limit_reached():
    record = global_cards_and_parents(nodes)
    action = reflect(task, record, pending_proposals)

    if action.kind == "approve":
        return pending_proposals[action.node]

    parent = action.node
    context, environment = restore_path(nodes, parent)
    result = execute(context, environment, action.instruction)

    if result.kind in ("checkpoint", "commit"):
        child = save_child(
            parent=parent,
            card=result.card,
            context=result.context,
            environment=result.environment,
        )
        nodes[child.id] = child
        if result.kind == "commit":
            pending_proposals[child.id] = result.solution

What You Gain, and What You Lose

The tree gives an agent somewhere to return to when a line of work stalls, and lets it compare compact records before spending more work on a branch. Path-specific restoration also avoids handing every segment the raw history of every alternative. But the design depends on useful cards and accurate saved context and environment; a misleading summary can steer Reflection badly, while a restored path does not magically provide evidence from sibling branches. Search is sequential, and a model must spend decisions on navigation and review as well as task work.

For deep research, TreeFlex’s reported comparisons include higher accuracy than flat ReAct and FoldAgent under the stated setup; on SWE, the reported system comparison also favors TreeFlex over FoldAgent. Those outcomes do not make the tree a free speedup: it trades a single growing history for state management, branch selection, and proposal review. The separate training treatment for complete searches is covered in the companion module.