Source-linked AI summary
From State to Action: OODA-Tool for Reliable Multi-Turn Tool Use
Rongfeng Guo, Yinxuan Huang, Yusen Wu, Maoqing Zhong, Yunlu Chen, Meng Tang, Teng Long, Vincent Tao Hu
TL;DR
Multi-turn tool use requires agents to preserve evolving task state, yet existing policies jointly learn state tracking and action generation. OODA-Tool separates these processes through controller-checked stages and improves task success across model scales, especially for smaller models and state-intensive tasks.
Problem
Multi-turn tool use lacks reliable state-consistent behavior because call validity depends on an evolving interaction state.
Method
OODA-Tool uses typed, controller-checked Observe, Orient, Decide, and Act stages to separate task-state preservation from grounded action realization.
Results
Specialized OODA improves Task Success over Direct-LoRA across Qwen3 scales, with gains of 6.86, 6.79, 6.99, 5.94, and 4.48 points from 0.6B to 14B.
Takeaways & Limitations
OODA-Tool is most useful for smaller models and tasks involving incomplete information, changing constraints, or sequential tool dependencies.
Takeaways & Limitations
Gains are smaller on parallel calls, where action expansion and cross-call binding errors remain challenges.
Abstract
from arXiv · showhide
Reliable multi-turn tool use requires an agent to preserve an evolving task state and ensure that each action remains consistent with it. However, direct function-calling and ReAct-style policies learn state tracking and action generation within the same autoregressive trajectory. This coupling creates state-action competition: the pressure to produce the next call can overwrite or ignore information accumulated earlier in the interaction. Inspired by Boyd's Observe-Orient-Decide-Act cycle, we introduce OODA-Tool, a typed closed-loop policy designed to mitigate this competition by separating state preservation from action realization. Rather than generating an action directly from the interaction history, OODA-Tool routes each decision through controller-checked intermediate states, ensuring that the final output remains grounded in the current task state. Specifically, Observe reconstructs the task state, Orient determines whether execution is warranted, Decide forms an admissible action structure, and Act realizes the external output. We evaluate OODA-Tool against direct function-calling and ReAct policies using Qwen3 models ranging from 0.6B to 14B across multi-turn, multi-tool, and incomplete-information settings. OODA-Tool consistently improves task success across model sizes, with larger gains on smaller models and on tasks whose actions depend strongly on information accumulated across turns and prior tool results. Controlled variants, stage-level ablations, and transfer evaluations further demonstrate the robustness of these improvements.
Introduction
The introduction identifies state-action competition as a central challenge in multi-turn tool use and proposes OODA-Tool, a typed closed-loop policy that separates state preservation from action realization. Its staged design is predicted and shown to help most on state-intensive tasks, especially for smaller models, while parallel-call realization remains a limitation.
- Motivation: Multi-turn tool calls are difficult because their validity depends on an interaction state that changes throughout the task.Single-turn performance may not transfer to stateful, long-horizon interactions, and final success can conceal inconsistent intermediate decisions.
- Motivation: Direct function-calling policies create state-action competition by mapping interaction history to an immediate call, which can disrupt preserving accumulated task state.Most agent designs leave the connection between accumulated state and the next action implicit.
- Method: OODA-Tool uses four typed stages—Observe, Orient, Decide, and Act—with controller-checked handoffs to reconstruct state, gate execution, plan admissible actions, and realize grounded outputs.Act produces either a schema-valid tool call or an authorized user-facing response.
- Results: Specialized OODA improves Task Success over Direct-LoRA by 6.86, 6.79, 6.99, 5.94, and 4.48 points on Qwen3 models with 0.6B, 1.7B, 4B, 8B, and 14B parameters, respectively.The gains are larger on hard and out-of-distribution slices, consistent with the prediction that benefits concentrate on state carried across turns and sequential tool dependencies.
- Evaluation: The evaluation reports consistent gains on state-intensive tasks while identifying parallel-call realization as a key limitation.Controlled variants, stage ablations, typed-state bottleneck analyses, and cross-scale evaluation are used to separate typed supervision, multi-pass inference, and stage specialization effects.
Methodology
OODA-Tool separates multi-turn tool use into typed, controller-validated stages that preserve task state before realizing an external action. Its closed-loop design reconstructs state, assesses readiness, selects an admissible action structure, and grounds execution in schemas and current evidence.
- Typed OODA policy: OODA-Tool separates task-state reconstruction, execution-readiness assessment, action selection, and output realization into typed intermediate states.This addresses the coupling present in monolithic policies, which perform these functions inside one implicit representation.
- Closed-loop execution: Each turn runs Observe, Orient, Decide, and Act under central-controller validation, then appends tool results, errors, or user updates to initiate the next cycle.The controller constrains Decide to structures permitted by the readiness state.
- Observe: task-state reconstruction: Observe builds a provenance-aware state containing goals, entities, values, evidence, constraints, unfinished subgoals, recent tool facts, and state changes.It includes only information available before the current action, while current-turn supervision excludes post-action observations.
- Orient: execution readiness: Orient predicts five response modes and blocks action-structure selection when evidence is insufficient or clarification, recovery, direct response, or termination is required.The modes are SOLVABLE_WITH_TOOL, NEED_CLARIFICATION, RESPOND_DIRECTLY, RECOVER_FROM_FAILURE, and DONE.
- Decide and Act: Decide selects a single call, sequential chain, or parallel action set, while Act binds state-derived values, resolves references, and verifies schema-required keys and formats.For non-tool modes, Act emits the authorized clarification, recovery, direct response, or termination output.
- Implementation variants: Joint OODA serializes all stages in one call, Shared OODA uses four calls with one shared LoRA adapter, and Specialized OODA uses one LoRA adapter per stage over a frozen backbone.These variants isolate typed supervision, stage-wise inference, and stage-specific parameterization.
Experiments
Across model scales and evaluation settings, Specialized OODA consistently improves multi-turn tool-use reliability, with the largest benefits on smaller models and state-dependent turns. Ablations and grounding analyses attribute these gains to typed, staged separation of state reconstruction, decision formation, and action realization, while revealing costs and limits for action expansion.
- Capacity and scale: Specialized OODA achieves the best Task Success across all model scales, with its advantage largest for smaller backbones and narrowing as capacity grows.Tool Exact follows the same pattern, while Ask–Act Accuracy is near saturation for structured methods.
- Capacity and scale: Specialized OODA remains strongest across hard and out-of-distribution subsets, although its margin over the strongest size-matched one-pass baseline steadily narrows with scale.Absolute performance improves with scale, suggesting larger backbones partially recover explicitly supplied state-tracking and decision capacity.
- Task structure: OODA’s gains concentrate on long histories, missing information, state changes, active constraints, and deeper tool dependencies, but are smaller for parallel calls.Parallel-call errors primarily involve call expansion and cross-call argument binding rather than dialogue-state reconstruction.
- Ablations: Removing Orient causes the largest ablation degradation, while removing the Decide–Act split especially harms missing-information and multi-tool turns.Removing typed states remains competitive in aggregate but degrades sharply on structured subsets.
- Execution grounding: Specialized OODA achieves the lowest premature-call and stale-or-ungrounded-argument rates on a fixed 500-turn rare-error sample.The staged typed state improves both call timing and whether arguments are supported by the interaction history.
- Transfer and efficiency: At 1.7B, Specialized OODA transfers modestly across MTU-Bench, is saturated or best on FAIL-TaLMs, and shows its clearest BFCL benefit for smaller backbones.At 1.7B it uses four sequential calls with 2.36× normalized latency relative to Direct-LoRA; gains are smaller on BFCL Multi-turn and ToolDial parallel calls.
- State–action alignment: The State–Action Contradiction Rate falls from 7.8% for Joint and 5.6% for Shared OODA to 3.9% for Specialized OODA, but rises to 10.7% without the Decide–Act split.A ToolDial identifier-grounding example shows OODA resolving osm_id_001 to Wikidata xid Q123456, preventing crossfield identifier substitution.
Conclusion
OODA-Tool improves reliable multi-turn tool use by separating task-state preservation from action realization through controller-checked stages. Its gains are strongest for smaller models and state-intensive tasks, with ablations attributing improvements to typed state construction and readiness–action separation.
- Method: OODA-Tool separates task-state preservation from action realization through controller-checked Observe, Orient, Decide, and Act stages.This typed closed-loop policy is designed to mitigate state–action competition.
- Findings: OODA-Tool improves multi-turn tool use across model scales, especially for smaller models and state-intensive tasks.These tasks involve incomplete information, changing constraints, and sequential dependencies.
- Ablations: Ablations identify typed state construction and readiness–action separation as drivers of OODA-Tool’s gains.