Paper deep dive

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

Year: 2026Venue: arXiv preprintArea: cs.AIType: PreprintEmbeddings: 116

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 8/28/2026, 3:17:04 AM

Summary

The paper introduces OODA-Tool, a typed closed-loop policy for reliable multi-turn tool use in language model agents. It addresses 'state-action competition' in direct function-calling and ReAct-style policies by separating state preservation from action realization through four stages: Observe, Orient, Decide, and Act. Evaluated on Qwen3 models (0.6B-14B) across benchmarks like ToolDial, OODA-Tool consistently improves task success, particularly for smaller models and state-intensive tasks.

Entities (17)

OODA-Tool · method · 100%Qwen3 · model · 98%Act · stage · 95%Decide · stage · 95%Observe · stage · 95%Orient · stage · 95%ToolDial · dataset · 95%Boyd's OODA cycle · concept · 90%Joint OODA · variant · 90%LoRA · technique · 90%ReAct · method · 90%Shared OODA · variant · 90%Specialized OODA · variant · 90%State-action competition · problem · 90%BFCL · dataset · 85%FAIL-TaLMs · dataset · 85%MTU-Bench · dataset · 85%

Relation Signals (16)

OODA-Tool → consistsof → Orient

confidence 95% · Specifically, Observe reconstructs the task state, Orient determines whether execution is warranted, Decide forms an admissible action structure, and Act realizes the external output.

OODA-Tool → consistsof → Observe

OODA-Tool → consistsof → Decide

OODA-Tool → consistsof → Act

OODA-Tool → evaluatedon → ToolDial

confidence 95% · We evaluate OODA-Tool against direct function-calling and ReAct policies using Qwen3 models... across multi-turn... settings. We conduct a cross-scale evaluation on ToolDial

OODA-Tool → improves → task success

confidence 95% · OODA-Tool consistently improves task success across model sizes

OODA-Tool → inspiredby → Boyd's OODA cycle

confidence 95% · Inspired by Boyd's Observe-Orient-Decide-Act cycle, we introduce OODA-Tool

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract: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.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

112,957 characters extracted from source content.

Expand or collapse full text

From State to Action: OODA-Tool for Reliable Multi-Turn Tool Use Rongfeng Guo 1∗ , Yinxuan Huang 2∗ , Yusen Wu 3 , Maoqing Zhong 4 , Yunlu Chen 5 , Meng Tang 6 , Teng Long 7 , Vincent Tao Hu 1 1 Huazhong University of Science and Technology 2 Knowin AI, Shenzhen, China 3 Fujian University of Technology 4 Jiangxi University of Science and Technology 5 King Abdullah University of Science and Technology 6 University of California, Merced 7 University of Amsterdam Abstract Reliable multi-turn tool use requires an agent to preserve an evolving task state and ensure that each action remains consis- tent 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 pol- icy 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, Ori- ent 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 Language-model agents increasingly rely on search engines, databases, code executors, and business APIs to solve tasks beyond parametric knowledge (Nakano et al. 2021; Schick et al. 2023; Qin et al. 2025; Li et al. 2023; Yang et al. 2023; Liu et al. 2024; Zhou et al. 2024). Multi-turn tool use is difficult because the validity of a call depends on an interaction state that changes as the task unfolds. Evaluations show that single- turn performance may not transfer to stateful, long-horizon interaction (Wang et al. 2024, 2025a; Yao et al. 2024; Acikgoz et al. 2025). Syntactic validity and eventual task completion are therefore incomplete indicators of correct behavior (Patil et al. 2025). Step-wise evaluations reveal failures hidden by One-shot Action tool: "search", args: "weather." Tools Success Failure New info User Query Agent Typical Outcome 1.Loses earlier state and constraints 2.Premature or ungrounded tool calls 78.67% Task Success (Qwen3-1.7B) OODA-Tool Observe Orient Decide Act Persistent Memory 1. Preserves active task state 2. Readiness-gated, grounded actions Higher Performance Task Success (Qwen3-1.7B) Lower Performance 85.46% Single-Pass Tool Agent Typical Outcome Figure 1: Comparison between a single-pass tool agent and our staged OODA-Tool agent. aggregate outcomes (Chen et al. 2024a). A call may be well formed yet rely on stale or unsupported information. Likewise, final success can mask inconsistent intermediate decisions, creating a gap between outcome correctness and consistency with the evolving state (Lu et al. 2025; Ou et al. 2025). Yet most agent designs leave the connection between accu- mulated state and the next action implicit (Patil et al. 2024; Qin et al. 2024). StateFlow externalizes part of this control through explicit state-machine transitions (Wu et al. 2024; Zhu et al. 2026). As shown in Figure 1, direct function-calling policies map the interaction history to a concrete call within one generation. ReAct-style policies make the reasoning pro- cess visible, but represent it as free-form reasoning rather than as controller-checkable state (Yao et al. 2023b; Schick arXiv:2608.24368v2 [cs.AI] 27 Aug 2026 et al. 2023; Erdogan et al. 2025). In both cases, the model may respond appropriately to the latest turn while failing to carry an earlier constraint or state update into the next action. We call this failure mode state-action competition: the immediate demand to produce an action interferes with preserving and applying the task state accumulated across turns. A useful lens on this failure comes from Boyd’s Observe– Orient–Decide–Act (OODA) cycle in military command and control (Boyd et al. 2018; Bai et al. 2026). OODA treats decision making as a closed loop rather than a direct reaction to the latest observation. New information is first interpreted against the current operational picture, after which an action is selected and executed. The consequences of that action then update the operational picture for the next cycle. Its relevance to tool use lies not simply in dividing reasoning into four steps, but in maintaining a coherent state between observation and action. Figure 1 illustrates this contrast: the upper pipeline leaves this coordination inside a monolithic generation, whereas the lower pipeline makes the decision state explicit and returns tool feedback to the next cycle (Shinn et al. 2023; Kim et al. 2025; Ma et al. 2024). Following this principle, we propose OODA-Tool, a typed policy with explicit supervision at each stage. Observe con- structs a provenance-aware representation of the current task, and Orient determines whether the available state supports execution. Based on this judgment, Decide specifies an admis- sible action structure, which Act realizes as a schema-valid tool call or an authorized user-facing response. As depicted in the lower half of Figure 1, a central controller checks each handoff before allowing the action to proceed and incorpo- rates the result into the next cycle. This differs fromα-UMi, which primarily divides planning, calling, and summarization across separate models (Shen et al. 2024). Plan-and-Act simi- larly separates planning from execution. OODA-Tool instead uses typed interfaces to regulate how accumulated state is converted into action (Qin et al. 2024). This design also raises a central question: whether compressing history into typed states loses information, or whether stronger interface constraints suppress otherwise valid actions. We investigate whether state preservation and action realizability can instead be improved jointly, as examined in RQ5. This mechanism yields a clear empirical prediction. OODA- Tool should provide the greatest benefit when success depends on carrying state across turns or coordinating sequential tool dependencies. The benefit should diminish as backbone capacity increases and remain modest when the main difficulty lies in expanding many parallel calls. The results follow this pattern. Across Qwen3 models with 0.6B, 1.7B, 4B, 8B, and 14B parameters, Specialized OODA improves Task Success over Direct-LoRA by 6.86, 6.79, 6.99, 5.94, and 4.48 points, respectively. The gains are larger on the hard and out-of- distribution slices, but smaller on simple or highly parallel calls. Direct-LoRA remains the cheaper choice when one- pass latency is the primary concern. Our contributions are as follows: •We propose OODA-Tool, a typed four-stage policy that separates state reconstruction, execution gating, action planning, and grounded realization. •We design controlled joint, shared, and specialized vari- ants, together with stage ablations and typed-state bottle- neck analyses, to disentangle the effects of typed supervi- sion, multi-pass inference, and stage specialization, and to examine how state preservation supports downstream action realization. •We conduct a cross-scale evaluation on ToolDial and three additional benchmarks, demonstrating consistent gains on state-intensive tasks while identifying parallel-call realization as a key limitation. Related Work Tool learning and function calling. Tool learning cov- ers instruction understanding, decomposition, selection, call generation, and response synthesis (Qin et al. 2025). Repre- sentative approaches include self-supervised call insertion in Toolformer (Schick et al. 2023), executable or simulated API-use data in API-Bank and ToolAlpaca (Li et al. 2023; Tang et al. 2023), and large-catalog retrieval and call gener- ation in Gorilla and ToolLLM (Patil et al. 2024; Qin et al. 2024). ToolACE, ToolFlow, and ToolDial increase call com- plexity and multi-turn coherence through verified or synthetic interactions (Liu et al. 2025; Wang et al. 2025c; Shim et al. 2025), while ReAct exposes free-form interleaved reasoning and actions (Yao et al. 2023b). Stateful interaction and clarification. ToolSandbox intro- duces stateful execution, implicit dependencies, conversation, and insufficient-information tasks (Lu et al. 2025);τ-bench scores the resulting database state under domain policies (Yao et al. 2024). MTU-Bench spans single- and multi-turn, single- and multi-tool settings, whereas FAIL-TaLMs isolates underspecification and unavailable-tool failures (Wang et al. 2025b; Treviño et al. 2025). Agent tuning, modular planning, and constrained execu- tion. FireAct, AgentTuning, and Agent-FLAN train agent capabilities from trajectories or capability-aware data (Chen et al. 2023; Zeng et al. 2024; Chen et al. 2024b). Chain-of- thought, self-consistency, Tree of Thoughts, and Reflexion expose, aggregate, search, or revise intermediate reasoning (Wei et al. 2022; Wang et al. 2023; Yao et al. 2023a; Shinn et al. 2023), but generally do not define typed execution contracts. The closest modular baseline separates planning, calling, and summarization (Shen et al. 2024); earlier systems connect language models to external modules or specialized-model controllers (Karpas et al. 2022; Shen et al. 2023). LLM- Compiler schedules function dependencies, and ToolDec constrains syntax (Kim et al. 2024; Zhang et al. 2024). Evaluation scope. BFCL evaluates simple, multiple, par- allel, and stateful function calling (Patil et al. 2025), while AgentBench and WebArena cover broader interactive settings (Liu et al. 2024; Zhou et al. 2024). Unlike these approaches, OODA-Tool supervises accumulated evidence, execution readiness, action dependencies, and argument realization through typed checkpoints before execution. Methodology This section presents OODA-Tool, including its typed decision process, stage supervision, and state-sufficiency analysis. Problem Formulation Task and interaction history. We study a language-model agent that interacts with an external tool environment over multiple turns. At turnt, the agent observes the ordered interaction history h t = (u 1 ,a 1 ,o 1 ),..., (u t−1 ,a t−1 ,o t−1 ),u t , (1) whereu i is a user message,a i is an agent tool call or natural- language response, ando i is the subsequent environment observation, which may be empty when no tool is invoked. LetTdenote the available tool library, including tool names, documentation, and argument schemas. A monolithic policy samples the next external output directly: a t ∼ π θ (·| h t ,T ),(2) thereby coupling task-state reconstruction, execution- readiness assessment, action-structure selection, and schema- grounded realization inside one implicit representation. Typed OODA policy. The typed interfaces and their central- controller checks are summarized in Figure 2. OODA-Tool represents the decision process as three typed intermediate states followed by a realized action. In the default history- visible setting, z O t = f O (h t ,T ),(3) z R t = f R (z O t ,h t ,T ),(4) z D t = f D (z O t ,z R t ,h t ,T ),(5) a t = f A (z O t ,z R t ,z D t ,h t ,T ),(6) where z O t , z R t , and z D t are the Observe state, readiness state, and action structure, respectively. LetZ D (z R t ) denote the set of action structures permitted by the readiness state. The central controller enforces z D t ∈Z D (z R t ),(7) so that Decide cannot authorize a tool structure when Orient requires clarification, recovery, direct response, or termination. This decomposition changes neither the environment nor the visible information; it changes how the decision is represented, supervised, and checked before the external output is emitted. The OODA-Tool Framework At each turn, OODA-Tool executes Observe, Orient, Decide, and Act in sequence under central-controller validation. A tool result, execution error, or user update is then appended to the interaction history and initiates the next cycle. Observe: task-state reconstruction. Observe converts the history into a provenance-aware task state with fixed field semantics. It records the current goal, entities, active values, evidence sources, constraints, unfinished subgoals, recent tool facts, and state changes. Only information available before the current action is included inh t ;g t provides current-turn supervision but excludes post-action observations. Orient: execution readiness. A correct task state does not necessarily imply that the agent should act. Orient predicts one of five response modes: SOLVABLE_WITH_TOOL,NEED_CLARIFICATION, RESPOND_DIRECTLY,RECOVER_FROM_FAILURE, or DONE. It also records missing slots, violated constraints, and unavailable tools. Orient determines whether action- structure selection is admissible and blocks execution when the available evidence is insufficient. Decide: action structure. Conditioned on the readiness state, Decide instantiates the permitted action structure. For executable turns, it selects a single call, a sequential chain, or a parallel action set and specifies the target tools, call order, and data dependencies without expanding final argument values. For non-tool modes, it preserves the authorized clarification, direct-response, recovery, or termination branch for Act. This separation keeps execution-readiness and action-structure errors distinct from argument-realization errors. Act: schema-grounded realization. Act compiles the se- lected action structure into executable calls. It binds values from the active task state or completed tool returns, performs schema-permitted deterministic transformations, resolves ref- erences to earlier outputs, and verifies required keys and formats. In non-tool modes, it emits the authorized clarifica- tion question, recovery action, direct answer, or termination response. Parallel and repeated calls place the greatest burden on this stage because one action structure must be expanded into multiple correctly bound call objects. Stage Parameterization and Supervision We instantiate the typed interfaces as Joint OODA, which serializes the Observe, Orient, Decide, and Act outputs in one model call; Shared OODA, which uses four stage-wise calls with one shared LoRA adapter; and Specialized OODA, which uses a separate LoRA adapter for each stage over the same frozen backbone (Hu et al. 2022). These variants isolate the effects of typed supervision, stage-wise inference, and stage-specific parameterization. Typed target construction is controlled by a Constraint- Policy. For a profilec, the policy specifies which execution- readiness conditions, active-task-state relations, and admissi- ble argument sources are represented in the targets. For each trajectoryξand turnt, we construct the visible prefixh t and a current-turn gold annotationg t . The annotation contains the gold response mode, action structure, and realized output for turnt, but excludes future user turns, the observation produced by the current gold action, and facts revealed only by that observation. Targets are derived in stage order: z O∗ t = ObserveTarget(h t ,c),(8) z R∗ t = OrientTarget(z O∗ t ,T ,g t ,c),(9) z D∗ t = DecideTarget(z O∗ t ,z R∗ t ,g t ,c),(10) a ∗ t = ActTarget(z O∗ t ,z R∗ t ,z D∗ t ,g t ,c).(11) This construction prevents upstream targets from depending on information obtained only after the gold action is executed. User Request Previous Tool Results Interaction Context Request , prior actions , tool feedback Next Cycle Closed-loop OODA Agent Shared Frozen Qwen3 Backbone LoRA Adapter Observe OrientDecide Act LoRA Adapter LoRA Adapter LoRA Adapter OODA：minL CE =- σ (x,y)∈D logp θ (y|x) Active State ⚫goal & entities ⚫active slots ⚫constraints ⚫provenance ⚫state changes Execution Readiness ⚫executable? ⚫missing slots ⚫unavailable tools ⚫violated constraints ⚫response mode Action Structure ⚫selected tools ⚫call order ⚫dependencies ⚫sequential/parallel ⚫no final values Grounded Realization ⚫argument binding ⚫source references ⚫type conversion ⚫schema-valid calls ⚫user response Readiness Alignment act only when executable Active-State Alignment reject superseded values Source-Grounding Alignment every argument has evidence ConstraintPolicy Stage-specific supervisionRuntime validation The same contracts supervise intermediate states and validate final actions. RuntimeChecks Readiness, schema, dependencies,grounding Tool Feedback Retrieved data or execution error Updated History User updates , actions , tool results External Tools Search , databases , business APIs θ Figure 2: Overview of OODA-Tool. The left panel shows the closed-loop tool-use process under central-controller validation. The upper-right panel illustrates Specialized OODA with a separate LoRA adapter for each stage over a shared frozen Qwen3 backbone. The lower-right panel summarizes the typed intermediate states and the unified constraint policy used for stage supervision and final-action validation. For Joint OODA, the supervised target is the serialized sequence y ∗ t = z O∗ t ;z R∗ t ;z D∗ t ;a ∗ t ,(12) and training minimizes L joint =− X (x,y)∈D joint,c logp θ c (y | x).(13) For Shared and Specialized OODA, stage-level datasetsD s,c are constructed for s∈O,R,D,A. Training minimizes L multi =− X s∈O,R,D,A X (x,z)∈D s,c logp θ ρ(s),c (z | x), (14) whereρ(s) = sharedfor Shared OODA andρ(s) = sfor Specialized OODA. The backbone, token-level cross-entropy objective, and target-construction pipeline remain fixed across constraint profiles; only the typed relations generated by the selected profile change. At inference time, the matching profile configures interface validation, contract retries, and execution-readiness-based rerouting in the central controller. State sufficiency. The default history-visible setting gives every stage access to h t in addition to typed upstream states. To test whether the typed states retain the information required downstream, the typed-state bottleneck removes history access from Orient, Decide, and Act, leaving only typed upstream states and tool schemas. A small degradation under this intervention indicates that the Observe state retains most task- relevant history and that the readiness state carries actionable information rather than only a post-hoc explanation. Experiments We ask whether OODA improves tool use across model scales (RQ1), when its gains are largest (RQ2), which components drive its gains (RQ3), how well it transfers and at what cost (RQ4), whether typed states remain actionable (RQ5), and how typed state supports argument grounding (RQ6). Experimental Setup Data, splits, and supervision. We use the official ToolDial split of 11,111 multi-turn tool-use sessions (Shim et al. 2025). Trajectories are split before label construction, keeping all turns from a session in the same partition. Supervision is con- structed from the visible interaction prefix and the current-turn gold action, while excluding future user turns, the observation returned by the current gold action, and facts revealed only by that observation. Each trajectory is converted into aligned training views for Direct-LoRA, ReAct-LoRA,α-UMi, Joint OODA, Shared OODA, and Specialized OODA. All systems use the same tokenizer and context budget; examples are tokenized offline, grouped by length, dynamically padded, and never packed across turn boundaries. Systems and training. We evaluate Qwen3-Instruct back- bones from 0.6B to 14B parameters (Team 2025). Direct- LoRA predicts the external output in one pass, ReAct-LoRA generates a free-form thought before acting, Direct-SC@4 aggregates four Direct-LoRA samples, andα-UMi uses Plan- ner, Caller, and Summarizer roles (Hu et al. 2022; Yao et al. Method Structure / adapters Task Success↑Tool Exact↑Ask–Act Accuracy↑ 0.6B 1.7B 4B 8B 14B 0.6B 1.7B 4B 8B 14B 0.6B 1.7B 4B 8B 14B Base Instruct–0.10 0.43 3.04 7.26 11.63 0.20 0.67 6.18 13.84 20.45 69.50 73.76 78.42 82.15 85.27 Direct-LoRA 1 adapter 78.24 78.67 80.31 83.58 90.42 88.36 82.41 84.29 87.31 96.21 94.06 95.03 96.08 97.05 98.04 ReAct-LoRA 1 adapter 65.43 73.18 79.62 81.35 84.77 71.56 77.21 82.39 85.44 90.83 91.32 94.71 95.26 96.59 97.84 Direct-SC@4 4 samples 78.90 78.90 81.12 83.92 90.72 88.70 82.68 84.57 87.45 96.34 94.10 95.07 96.15 97.12 98.09 α-UMi3 roles 82.90 83.9485.8088.1093.9097.9098.6098.7298.9499.1598.3598.7098.8098.9299.04 Ours OODAJoint83.90 84.16 86.10 88.45 94.10 98.10 98.20 98.55 98.85 99.15 97.95 98.22 98.45 98.70 98.90 OODAShared 84.55 84.78 86.68 88.96 94.50 98.35 98.58 98.80 99.05 99.28 98.20 98.52 98.67 98.85 99.03 OODASpecialized85.1085.4687.3089.5294.9098.5599.0999.1699.3099.4298.4098.7398.8698.9899.10 Table 1: ToolDial results across Qwen3 backbone sizes. Specialized OODA achieves the highest Task Success at every scale, with larger gains on smaller backbones. Bold indicates the best result, and underlining indicates the strongest non-OODA baseline. 2023b; Wang et al. 2023; Shen et al. 2024). Joint, Shared, and Specialized OODA respectively use one-pass typed gen- eration, four stage-wise calls with a shared adapter, and four stage-specific adapters. At each scale, systems share the Qwen3-Instruct backbone, setenable_thinking=false, and use an 8192-token limit. All LoRA-tuned systems use rankr = 32, scalingα = 64, 0.05 dropout, andtarget_modules=all-linear, with the backbone, embeddings, andlm_headfrozen. Opti- mizer family, learning-rate schedule, epoch count, validation procedure, and output processing are shared; training uses BF16 and FlashAttention 2 (Dao 2024). Per-device batch size and gradient accumulation vary by scale to keep the global batch approximately constant. Checkpoints and decoding settings are selected on validation data. Constraint profiles. Each ConstraintPolicy generates a separate typed training set from the same trajectories. Pro- files share the data split, architecture, LoRA configuration, optimizer, training schedule, and token-level cross-entropy objective. At evaluation time, each model is paired with the controller corresponding to its training profile. Evaluation pipeline. All methods use the same output parser, schema normalizer, validator, benchmark adapter, and metric implementation. Shared metrics are computed from the final external action or response; OODA intermediate states are used only for targeted diagnostics. The main text em- phasizes cross-scale patterns and representative mechanisms, while complete results are reported in the supplement. External datasets. For transfer experiments, models retain their ToolDial-trained adapters and receive no additional training examples or in-context demonstrations on FAIL- TaLMs, MTU-Bench, or BFCL (Treviño et al. 2025; Wang et al. 2025b; Patil et al. 2025). All external evaluations use greedy decoding and the same benchmark-specific conversion and scoring pipeline across methods. Metrics and statistics. ToolDial is evaluated with Task Suc- cess, Tool Exact, and Ask–Act Accuracy. On tool-call turns, Task Success requirestool_exact,argument_exact, andschema_valid;grounding_validis reported separately as a typed-state metric. For methods with typed intermediate states, we additionally report State Slot F1 and Typed Constraint Consistency. Across all methods, we measure Ask-vs-Act F1, premature-call rate, and stale-or- ungrounded-argument rate, with slices by history length, missing information, state changes, active constraints, depen- dency depth, and parallel-call structure. MTU-Bench uses the metrics provided by MTU-Eval, including S-M and S-S averages. FAIL-TaLMs reports Ask–Act Accuracy, Schema Validity, Premature Call, and Required-Argument Coverage; typed-state methods additionally report Trace Grounding Va- lidity, Readiness Contract Validity, Slot Exactness, and Stale Binding. BFCL reports its official Overall, Non-Live, Live, and Multi-turn tracks. RQ1: Does OODA Improve Tool Use? Table 1 shows that Specialized OODA consistently achieves the best Task Success across all model scales. Its advantage is largest for smaller backbones and narrows as capacity grows, indicating that explicit decision-state decomposition is espe- cially useful under limited model capacity. Tool Exact follows the same general pattern, whereas Ask–Act Accuracy is al- ready near saturation for structured methods. The progression from Joint to Shared and then Specialized OODA further sug- gests that both multi-pass decomposition and stage-specific adaptation contribute to the gains. RQ2: When Does OODA Help Most? Capacity. Across the hard and out-of-distribution evalua- tion subsets, Specialized OODA remains the strongest method at every reported backbone size; detailed results appear in the supplement section Hard/OOD Capacity Results. Absolute performance improves with scale, but the margin over the Algorithm 1 Specialized OODA-Tool Training and Inference Require: TrajectoriesD, tool libraryT , constraint profile c Ensure: Trained parameters Θ ∗ c =θ ∗ s,c s∈O,R,D,A Offline Training 1: InitializeD s,c ←∅ for all s∈O,R,D,A 2: for all trajectory ξ ∈D do 3: for all turn t in ξ do 4:(h t ,g t )← CurrentTurnView(ξ,t) 5:z O∗ t ← ObserveTarget(h t ,c) 6:z R∗ t ← OrientTarget(z O∗ t ,T ,g t ,c) 7:z D∗ t ← DecideTarget(z O∗ t ,z R∗ t ,g t ,c) 8:a ∗ t ← ActTarget(z O∗ t ,z R∗ t ,z D∗ t ,g t ,c) 9:Add the four stage examples toD s,c s∈O,R,D,A 10: end for 11: end for 12: for all s∈O,R,D,A do 13: θ ∗ s,c ← SupervisedTrain(D s,c ) 14: end for Online Inference 15: Initialize h 1 ←⟨u 1 ⟩ 16: for t = 1,...,H do 17: z O t ← f O (h t ,T ;θ ∗ O,c ) 18: z R t ← f R (z O t ,h t ,T ;θ ∗ R,c ) 19: z D t ← f D (z O t ,z R t ,h t ,T ;θ ∗ D,c ) 20: Validate z D t ∈Z D (z R t ) 21: a t ← f A (z O t ,z R t ,z D t ,h t ,T ;θ ∗ A,c ) 22: Validate the schema and grounding of a t 23: if z R t = SOLVABLE_WITH_TOOL then 24:o t ←E (a t ) 25:h t+1 ← h t ⊕ (a t ,o t ) 26: else if z R t = RECOVER_FROM_FAILURE then 27:o t ←E (a t ) 28:h t+1 ← h t ⊕ (a t ,o t ) 29: else if z R t = NEED_CLARIFICATION then 30:Emit a t and receive u t+1 31:h t+1 ← h t ⊕ (a t ,u t+1 ) 32: else 33:return a t ▷ RESPOND_DIRECTLY or DONE 34: end if 35: end for strongest size-matched one-pass baseline steadily narrows. To- gether with Table 1, this pattern suggests that larger backbones partially recover the state-tracking and decision capacity sup- plied explicitly by OODA. These subset results characterize model behavior; overall results are reported in Table 1, and slice definitions and sample counts in the supplement section Development Slice Construction. Task structure. Figure 3 shows that OODA’s gains con- centrate on turns requiring state reconstruction: long his- tories, missing required information, state changes, active constraints, and deeper tool dependencies. The improvement is much smaller for parallel calls, where the dominant er- rors concern call expansion and cross-call argument binding rather than dialogue-state reconstruction. OODA therefore addresses state-dependent reasoning more effectively than parallel action realization. Long history Multi- tool Missing info State change Active const. Deep deps. Parallel calls 1.7B 4B 8B 14B Model scale +16.3+13.8+15.9+14.7+13.1+14.4 +3.2 +12.1+10.4+12.8+11.5 +9.8 +10.9 +2.7 +6.4+5.2+6.1+5.8+4.9+5.4+1.8 +3.8+3.2+3.6+3.4+2.9+3.1+1.1 State and readiness complexity Action expansion 0481216 Δ Task Success (p) Figure 3: Task Success gains of Specialized OODA over Direct-LoRA across model scales and ToolDial complexity subsets. Gains are largest on state-intensive tasks and smallest on parallel calls; values are percentage-point differences. OverallLong historyMissing informationMulti-tool 0 4 8 12 16 Task Success decrease (p) w/o Downstream History w/o Typed States w/o Orient w/o Decide–Act Split w/o Stage-specific Adapters (a) Component ablations 024681012 Error rate (%) ↓ Specialized OODA (Ours) Shared OODA (Ours) Joint Typed OODA (Ours) Direct-SC@4 Direct-LoRA ReAct-LoRA 3 4.5 6.5 8.5 9 10.5 1.5 3.5 5 7 7.5 8 Premature callStale/ungrounded argument (b) Grounding Errors Figure 4: Component ablations and execution-grounding er- rors. Panel (a) reports Task Success decreases under controlled ablations, and panel (b) reports premature-call and stale-or- ungrounded-argument rates; larger ablation drops are worse, while lower error rates are better. Orient and the Decide–Act separation contribute most, whereas stage-specific adapters have a smaller effect. RQ3: Which Components Matter? In ablation analyses, Full OODA refers to Specialized OODA without any component removed. We compare five variants: w/o Orient removes the Orient stage; w/o Decide–Act Split merges decision formation with action realization; w/o Typed States replaces typed intermediate states with free-form text; w/o Downstream History restricts downstream stages to typed upstream states and tool schemas; and w/o Stage- specific Adapters shares one adapter across all stages. Ablation sensitivity. The mechanism set contains 1,250 turns from 600 dialogues. Figure 4(a) shows that w/o Orient causes the largest degradation, especially when required infor- mation is missing. w/o Decide–Act Split is also particularly harmful on missing-information and multi-tool turns, showing that deciding whether and what to call should remain distinct from surface-level action generation. w/o Typed States re- mains competitive in aggregate but degrades sharply on these structured subsets. By contrast, w/o Downstream History causes a moderate loss, while w/o Stage-specific Adapters has the smallest effect. The main benefit therefore comes from explicit staged state construction, with stage-specific adaptation providing an additional but smaller gain. Execution grounding. Figure 4(b) evaluates all methods on a fixed 500-turn sample drawn from rare-error pools. Specialized OODA achieves the lowest premature-call and stale-or-ungrounded-argument rates. Its advantage thus ex- tends beyond producing syntactically valid calls: the staged typed state also improves when a call is issued and whether its arguments are supported by the interaction history. RQ4: What Transfers, and at What Cost? We use FAIL-TaLMs to evaluate readiness and failure han- dling, MTU-Bench to measure transfer across tool-use set- tings, and BFCL to evaluate call realization. Figure 5 sum- marizes the cross-scale margin of Specialized OODA over α-UMi; complete tables are reported in the supplement. Zero-shot readiness transfer: FAIL-TaLMs. At 1.7B, Specialized OODA is saturated on the shared readiness met- rics and is best or tied with the strongest baselines. Its margin overα-UMi becomes negligible at larger scales, indicating that FAIL-TaLMs mainly tests capabilities that sufficiently large structured models already solve. Typed-state diagnostics likewise show near-perfect grounding, readiness, slot accu- racy, and stale-binding control. These internally evaluated results are not official FAIL-TaLMs leaderboard scores, and the prediction summary does not support a unified setting- level success table. Full results appear in the supplement section FAIL-TaLMs Readiness and Failure Handling. Cross-setting transfer: MTU-Bench. Specialized OODA improves most MTU-Bench metrics at 1.7B while tying the remaining ones. The advantage is consistent but modest, suggesting that the learned state decomposition transfers beyond ToolDial without dominating every aspect of multi- turn tool use. Complete all-scale and per-metric results appear in the supplement section MTU-Bench Transfer Results. Call realization: BFCL. BFCL shows the clearest benefit for smaller backbones. The margin decreases with scale, indicating that explicit state decomposition compensates when backbone capacity is limited. However, the smaller gain on the Multi-turn track is consistent with parallel-call errors 0.6B1.7B4B8B14B Qwen3 backbone size 0 0.25 0.50 0.75 1.00 Relative OODA advantage BFCL MTU-Eval FAIL-TaLMs Figure 5: Normalized transfer advantage of Specialized OODA overα-UMi across Qwen3 backbone sizes on BFCL, MTU- Eval, and FAIL-TaLMs. Higher values indicate larger gains. The advantage is strongest on BFCL and smaller backbones and narrows with scale. observed on ToolDial. Full results appear in the supplement section Call-Realization Boundary: BFCL. Efficiency trade-off. At 1.7B, Specialized OODA uses four sequential calls with 2.36×normalized latency relative to Direct-LoRA. Its accuracy–latency trade-off is most favor- able on turns involving missing information, state changes, active constraints, or tool dependencies, while Direct-LoRA remains suitable for simple latency-sensitive calls. Direct- SC@4 uses the same number of model calls but remains below the OODA variants, indicating that the gain comes from struc- tured computation rather than repeated sampling. Parallel-call realization remains a shared limitation of structured meth- ods. Detailed cost measurements and the accuracy–latency analysis appear in the supplement section Efficiency Trade-off. RQ5: Can Typed States Support Action? Typed-state sufficiency. w/o Downstream History retains most of Full OODA’s performance without dialogue-history access, but degrades on long-history, missing-information, and multi-tool turns, suggesting that typed states preserve most but not all task-relevant context. w/o Typed States is less robust, while w/o Orient causes the largest losses in state reconstruction and constraint consistency despite near- ceiling Ask-vs-Act accuracy. Thus, free-form states’ high Schema Validity does not imply equivalent state quality (the supplement section Mechanism Ablations). State–action alignment. On turns where all variants re- cover the correct action-relevant state and Orient mode, the State–Action Contradiction Rate (SACR; lower is better) 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. This 6.8-point gap indicates that separating action selection from realization reduces residual response- mode, superseded-value, and unsupported-binding errors. A profile comparison varying only readiness, active-state, and argument-grounding targets preserves perfect schema validity while the constraint-enriched profile removes stale bindings and restores grounding. Gradient alignment also increases dur- 1 SHARED EVIDENCE User request “Give me detailed information about a nearby attraction.” Nearby Search returns two candidates Historical Museum OSM ID: Local place ID: Wikidata ID: osm_id_001 museum_001 Q123456 Central Park OSM ID: Local place ID: Wikidata ID: osm_id_002 park_001 Q654321 User selection “I choose osm_id_001.” The downstream detail toolrequires the selected attraction’s Wikidata identifier. Correct call Place_properties(lang="en", xid="Q123456") Baseline Identifies the correct attraction Selects the correct tool (Place_properties) Copies the wrong identifier from the selected row OSM ID Local place ID Wikidata ID osm_id_001 museum_001 Q123456 osm_id_002 park_001Q654321 selected row Place_properties( lang="en", xid="museum_001" ) Failure: Correct place, wrong field. The model jumps directly from the user’s selection to thefinal call and copies a plausible nearby value, but does notverify whether the value is the identifier required by the downstream tool. 3 OODA Observe Orient Decide Act Support chain User selection: osm_id_001 Selected result row: Historical Museum Wikidata ID: Q123456 All required arguments are available and grounded. SINGLE →Place_properties Place_properties( lang="en", xid="Q123456" ) User selection (osm_id_001) Matchingresult row (Historical Museum) Wikidata ID (Q123456) Result: Correct, schema-valid, and grounded call. Figure 6: Identifier grounding. Baselines copy a local ID, whereas OODA traces the selection to the Wikidata ID. ing training, especially for Act-related pairs. Further analyses appear in the supplement sections State–Action Competition, Constraint-Policy Alignment Across Training and Inference, and Gradient Analysis Protocol. Interpretation and boundary. Typed states support action when readiness, active values, and admissible sources are rep- resented consistently. The main limitation is action expansion: gains are smaller on BFCL Multi-turn, while ToolDial parallel calls still expose call-expansion and cross-call binding errors. RQ6: How Does OODA Ground Arguments? Figure 6 illustrates a ToolDial identifier-grounding failure. The user selectsosm_id_001, butPlace_properties requires a Wikidataxid. Direct-LoRA and ReAct-LoRA choose the correct attraction and tool yet copymuseum_001. OODA resolves the selected row in Observe, extracts Q123456, and produces the grounded call, preventing cross- field identifier substitution. Conclusion We introduced OODA-Tool, a typed closed-loop policy that mitigates state–action competition by separating task- state preservation from action realization through controller- checked Observe, Orient, Decide, and Act stages. Across scales, OODA-Tool improves multi-turn tool use for smaller models and state-intensive tasks involving incomplete infor- mation, changing constraints, and sequential dependencies. Ablations show that typed state construction and readiness– action separation drive gains, while transfer results suggest that these interfaces remain useful beyond ToolDial despite se- quential inference cost. Smaller gains on parallel calls identify action expansion and cross-call binding as key challenges. References Acikgoz, E. C.; Greer, J.; Datta, A.; Yang, Z.; Zeng, W.; Elachqar, O.; Koukoumidis, E.; Hakkani-Tür, D.; and Tur, G. 2025. Can a Single Model Master Both Multi-turn Conver- sations and Tool Use? CoALM: A Unified Conversational Agentic Language Model. In Che, W.; Nabende, J.; Shutova, E.; and Pilehvar, M. T., eds., Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Vol- ume 1: Long Papers), ACL 2025, Vienna, Austria, July 27 - August 1, 2025, 12370–12390. Association for Computational Linguistics. Bai, S.; Zhang, J.; Huang, H.; Wang, Y.; Liu, J.; Wu, Y.; Yu, N.; Gao, Y.; and Cheng, M. 2026. One Cognitive Loop Is Enough: SODA unlocks Pure-Text Spatial Reasoning in Large Language Models. In Liakata, M.; Moreira, V. P.; Zhang, J.; and Jurgens, D., eds., Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2026, San Diego, California, United States, July 2-7, 2026, 29974–29996. Association for Computational Linguistics. Boyd, J. R.; et al. 2018. A discourse on winning and losing, volume 400. Air University Press Maxwell Air Force Base, AL. Chen, B.; Shu, C.; Shareghi, E.; Collier, N.; Narasimhan, K.; and Yao, S. 2023. FireAct: Toward Language Agent Fine-tuning. CoRR, abs/2310.05915. Chen, Z.; Du, W.; Zhang, W.; Liu, K.; Liu, J.; Zheng, M.; Zhuo, J.; Zhang, S.; Lin, D.; Chen, K.; and Zhao, F. 2024a. T-Eval: Evaluating the Tool Utilization Capability of Large Language Models Step by Step. In Ku, L.; Martins, A.; and Srikumar, V., eds., Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), ACL 2024, Bangkok, Thailand, August 11-16, 2024, 9510–9529. Association for Computational Linguistics. Chen, Z.; Liu, K.; Wang, Q.; Zhang, W.; Liu, J.; Lin, D.; Chen, K.; and Zhao, F. 2024b. Agent-FLAN: Designing Data and Methods of Effective Agent Tuning for Large Language Models. In Ku, L.; Martins, A.; and Srikumar, V., eds., Findings of the Association for Computational Linguistics, ACL 2024, Bangkok, Thailand and virtual meeting, August 11- 16, 2024, volume ACL 2024 of Findings of ACL, 9354–9366. Association for Computational Linguistics. Dao, T. 2024. FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning. In The Twelfth Interna- tional Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net. Erdogan, L. E.; Lee, N.; Kim, S.; Moon, S.; Furuta, H.; Anumanchipalli, G.; Keutzer, K.; and Gholami, A. 2025. Plan- and-Act: Improving Planning of Agents for Long-Horizon Tasks. In Singh, A.; Fazel, M.; Hsu, D.; Lacoste-Julien, S.; Berkenkamp, F.; Maharaj, T.; Wagstaff, K.; and Zhu, J., eds., Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13- 19, 2025, volume 267 of Proceedings of Machine Learning Research. PMLR / OpenReview.net. Hu, E. J.; Shen, Y.; Wallis, P.; Allen-Zhu, Z.; Li, Y.; Wang, S.; Wang, L.; and Chen, W. 2022. LoRA: Low-Rank Adaptation of Large Language Models. In The Tenth International Conference on Learning Representations, ICLR 2022, Virtual Event, April 25-29, 2022. OpenReview.net. Karpas, E.; Abend, O.; Belinkov, Y.; Lenz, B.; Lieber, O.; Ratner, N.; Shoham, Y.; Bata, H.; Levine, Y.; Leyton-Brown, K.; Muhlgay, D.; Rozen, N.; Schwartz, E.; Shachaf, G.; Shalev-Shwartz, S.; Shashua, A.; and Tennenholtz, M. 2022. MRKL Systems: A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning. CoRR, abs/2205.00445. Kim, S.; Moon, S.; Tabrizi, R.; Lee, N.; Mahoney, M. W.; Keutzer, K.; and Gholami, A. 2024. An LLM Compiler for Parallel Function Calling. In Salakhutdinov, R.; Kolter, Z.; Heller, K. A.; Weller, A.; Oliver, N.; Scarlett, J.; and Berkenkamp, F., eds., Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21- 27, 2024, volume 235 of Proceedings of Machine Learning Research, 24370–24391. PMLR / OpenReview.net. Kim, W.; Park, S.; In, Y.; Kim, S.; Lee, D.; and Park, C. 2025. Beyond the Final Answer: Evaluating the Reasoning Trajec- tories of Tool-Augmented Agents. CoRR, abs/2510.02837. Li, M.; Zhao, Y.; Yu, B.; Song, F.; Li, H.; Yu, H.; Li, Z.; Huang, F.; and Li, Y. 2023. API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs. In Bouamor, H.; Pino, J.; and Bali, K., eds., Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, EMNLP 2023, Singapore, December 6-10, 2023, 3102–3116. Association for Computational Linguistics. Liu, W.; Huang, X.; Zeng, X.; Hao, X.; Yu, S.; Li, D.; Wang, S.; Gan, W.; Liu, Z.; Yu, Y.; Wang, Z.; Wang, Y.; Ning, W.; Hou, Y.; Wang, B.; Wu, C.; Wang, X.; Liu, Y.; Wang, Y.; Tang, D.; Tu, D.; Shang, L.; Jiang, X.; Tang, R.; Lian, D.; Liu, Q.; and Chen, E. 2025. ToolACE: Winning the Points of LLM Function Calling. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net. Liu, X.; Yu, H.; Zhang, H.; Xu, Y.; Lei, X.; Lai, H.; Gu, Y.; Ding, H.; Men, K.; Yang, K.; Zhang, S.; Deng, X.; Zeng, A.; Du, Z.; Zhang, C.; Shen, S.; Zhang, T.; Su, Y.; Sun, H.; Huang, M.; Dong, Y.; and Tang, J. 2024. AgentBench: Evaluating LLMs as Agents. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net. Lu, J.; Holleis, T.; Zhang, Y.; Aumayer, B.; Nan, F.; Bai, H.; Ma, S.; Ma, S.; Li, M.; Yin, G.; Wang, Z.; and Pang, R. 2025. ToolSandbox: A Stateful, Conversational, Interac- tive Evaluation Benchmark for LLM Tool Use Capabilities. In Chiruzzo, L.; Ritter, A.; and Wang, L., eds., Findings of the Association for Computational Linguistics: NAACL 2025, Albuquerque, New Mexico, USA, April 29 - May 4, 2025, volume NAACL 2025 of Findings of ACL, 1160–1183. Association for Computational Linguistics. Ma, C.; Zhang, J.; Zhu, Z.; Yang, C.; Yang, Y.; Jin, Y.; Lan, Z.; Kong, L.; and He, J. 2024. AgentBoard: An Analytical Evaluation Board of Multi-turn LLM Agents. In Globersons, A.; Mackey, L.; Belgrave, D.; Fan, A.; Paquet, U.; Tomczak, J. M.; and Zhang, C., eds., Advances in Neural Information Processing Systems 37: Annual Conference on Neural Infor- mation Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024. Nakano, R.; Hilton, J.; Balaji, S.; Wu, J.; Ouyang, L.; Kim, C.; Hesse, C.; Jain, S.; Kosaraju, V.; Saunders, W.; Jiang, X.; Cobbe, K.; Eloundou, T.; Krueger, G.; Button, K.; Knight, M.; Chess, B.; and Schulman, J. 2021. WebGPT: Browser- assisted question-answering with human feedback. CoRR, abs/2112.09332. Ou, T.; Guo, W.; Gandhi, A.; Neubig, G.; and Yue, X. 2025. AgentDiagnose: An Open Toolkit for Diagnosing LLM Agent Trajectories. In Habernal, I.; Schulam, P.; and Tiedemann, J., eds., Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, EMNLP 2025 - System Demonstrations, Suzhou, China, November 4-9, 2025, 207–215. Association for Computational Linguistics. Patil, S. G.; Mao, H.; Yan, F.; Ji, C. C.; Suresh, V.; Stoica, I.; and Gonzalez, J. E. 2025. The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models. In Singh, A.; Fazel, M.; Hsu, D.; Lacoste-Julien, S.; Berkenkamp, F.; Maharaj, T.; Wagstaff, K.; and Zhu, J., eds., Forty-second International Conference on Machine Learning, ICML 2025, Vancouver, BC, Canada, July 13-19, 2025, volume 267 of Proceedings of Machine Learning Research. PMLR / OpenReview.net. Patil, S. G.; Zhang, T.; Wang, X.; and Gonzalez, J. E. 2024. Gorilla: Large Language Model Connected with Massive APIs. In Globersons, A.; Mackey, L.; Belgrave, D.; Fan, A.; Paquet, U.; Tomczak, J. M.; and Zhang, C., eds., Ad- vances in Neural Information Processing Systems 37: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024. Qin, Y.; Hu, S.; Lin, Y.; Chen, W.; Ding, N.; Cui, G.; Zeng, Z.; Zhou, X.; Huang, Y.; Xiao, C.; Han, C.; Fung, Y. R.; Su, Y.; Wang, H.; Qian, C.; Tian, R.; Zhu, K.; Liang, S.; Shen, X.; Xu, B.; Zhang, Z.; Ye, Y.; Li, B.; Tang, Z.; Yi, J.; Zhu, Y.; Dai, Z.; Yan, L.; Cong, X.; Lu, Y.; Zhao, W.; Huang, Y.; Yan, J.; Han, X.; Sun, X.; Li, D.; Phang, J.; Yang, C.; Wu, T.; Ji, H.; Li, G.; Liu, Z.; and Sun, M. 2025. Tool Learning with Foundation Models. ACM Comput. Surv., 57(4): 101:1–101:40. Qin, Y.; Liang, S.; Ye, Y.; Zhu, K.; Yan, L.; Lu, Y.; Lin, Y.; Cong, X.; Tang, X.; Qian, B.; Zhao, S.; Hong, L.; Tian, R.; Xie, R.; Zhou, J.; Gerstein, M.; Li, D.; Liu, Z.; and Sun, M. 2024. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net. Schick, T.; Dwivedi-Yu, J.; Dessì, R.; Raileanu, R.; Lomeli, M.; Hambro, E.; Zettlemoyer, L.; Cancedda, N.; and Scialom, T. 2023. Toolformer: Language Models Can Teach Them- selves to Use Tools. In Oh, A.; Naumann, T.; Globerson, A.; Saenko, K.; Hardt, M.; and Levine, S., eds., Advances in Neu- ral Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023. Shen, W.; Li, C.; Chen, H.; Yan, M.; Quan, X.; Chen, H.; Zhang, J.; and Huang, F. 2024. Small LLMs Are Weak Tool Learners: A Multi-LLM Agent. In Al-Onaizan, Y.; Bansal, M.; and Chen, Y., eds., Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, EMNLP 2024, Miami, FL, USA, November 12-16, 2024, 16658–16680. Association for Computational Linguistics. Shen, Y.; Song, K.; Tan, X.; Li, D.; Lu, W.; and Zhuang, Y. 2023. HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face. In Oh, A.; Naumann, T.; Globerson, A.; Saenko, K.; Hardt, M.; and Levine, S., eds., Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023. Shim, J.; Seo, G.; Lim, C.; and Jo, Y. 2025. ToolDial: Multi-turn Dialogue Generation Method for Tool-Augmented Language Models. In The Thirteenth International Confer- ence on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net. Shinn, N.; Cassano, F.; Gopinath, A.; Narasimhan, K.; and Yao, S. 2023. Reflexion: language agents with verbal rein- forcement learning. In Oh, A.; Naumann, T.; Globerson, A.; Saenko, K.; Hardt, M.; and Levine, S., eds., Advances in Neu- ral Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023. Tang, Q.; Deng, Z.; Lin, H.; Han, X.; Liang, Q.; and Sun, L. 2023. ToolAlpaca: Generalized Tool Learning for Language Models with 3000 Simulated Cases. CoRR, abs/2306.05301. Team, Q. 2025. Qwen3 Technical Report. CoRR, abs/2505.09388. Treviño, E.; Contant, H.; Ngai, J.; Neubig, G.; and Wang, Z. Z. 2025. Benchmarking Failures in Tool-Augmented Lan- guage Models. In Chiruzzo, L.; Ritter, A.; and Wang, L., eds., Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computa- tional Linguistics: Human Language Technologies, NAACL 2025 - Volume 1: Long Papers, Albuquerque, New Mexico, USA, April 29 - May 4, 2025, 2916–2934. Association for Computational Linguistics. Wang, H.; Huang, W.; Wang, Y.; Xi, Y.; Lu, J.; Zhang, H.; Hu, N.; Liu, Z.; Pan, J. Z.; and Wong, K. 2025a. Rethinking Stateful Tool Use in Multi-Turn Dialogues: Benchmarks and Challenges. In Che, W.; Nabende, J.; Shutova, E.; and Pilehvar, M. T., eds., Findings of the Association for Computational Linguistics, ACL 2025, Vienna, Austria, July 27 - August 1, 2025, volume ACL 2025 of Findings of ACL, 5433–5453. Association for Computational Linguistics. Wang, P.; Wu, Y.; Wang, N.; Liu, J.; Song, X.; Peng, Z. Y.; Deng, K.; Zhang, C.; Wang, J.; Peng, J.; Zhang, G.; Guo, H.; Zhang, Z.; Su, W.; and Zheng, B. 2025b. MTU-Bench: A Multi-granularity Tool-Use Benchmark for Large Language Models. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24- 28, 2025. OpenReview.net. Wang, X.; Wang, Z.; Liu, J.; Chen, Y.; Yuan, L.; Peng, H.; and Ji, H. 2024. MINT: Evaluating LLMs in Multi-turn Interaction with Tools and Language Feedback. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net. Wang, X.; Wei, J.; Schuurmans, D.; Le, Q. V.; Chi, E. H.; Narang, S.; Chowdhery, A.; and Zhou, D. 2023. Self- Consistency Improves Chain of Thought Reasoning in Lan- guage Models. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net. Wang, Z.; Zeng, X.; Liu, W.; Li, L.; Wang, Y.; Shang, L.; Jiang, X.; Liu, Q.; and Wong, K. 2025c. ToolFlow: Boosting LLM Tool-Calling Through Natural and Coherent Dialogue Synthesis. In Chiruzzo, L.; Ritter, A.; and Wang, L., eds., Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Lin- guistics: Human Language Technologies, NAACL 2025 - Vol- ume 1: Long Papers, Albuquerque, New Mexico, USA, April 29 - May 4, 2025, 4246–4263. Association for Computational Linguistics. Wei, J.; Wang, X.; Schuurmans, D.; Bosma, M.; Ichter, B.; Xia, F.; Chi, E. H.; Le, Q. V.; and Zhou, D. 2022. Chain- of-Thought Prompting Elicits Reasoning in Large Language Models. In Koyejo, S.; Mohamed, S.; Agarwal, A.; Belgrave, D.; Cho, K.; and Oh, A., eds., Advances in Neural Informa- tion Processing Systems 35: Annual Conference on Neural Information Processing Systems 2022, NeurIPS 2022, New Orleans, LA, USA, November 28 - December 9, 2022. Wu, Y.; Yue, T.; Zhang, S.; Wang, C.; and Wu, Q. 2024. State- Flow: Enhancing LLM Task-Solving through State-Driven Workflows. CoRR, abs/2403.11322. Yang, J.; Prabhakar, A.; Narasimhan, K.; and Yao, S. 2023. InterCode: Standardizing and Benchmarking Interactive Cod- ing with Execution Feedback. In Oh, A.; Naumann, T.; Globerson, A.; Saenko, K.; Hardt, M.; and Levine, S., eds., Advances in Neural Information Processing Systems 36: An- nual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023. Yao, S.; Shinn, N.; Razavi, P.; and Narasimhan, K. 2024. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. CoRR, abs/2406.12045. Yao, S.; Yu, D.; Zhao, J.; Shafran, I.; Griffiths, T.; Cao, Y.; and Narasimhan, K. 2023a. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. In Oh, A.; Naumann, T.; Globerson, A.; Saenko, K.; Hardt, M.; and Levine, S., eds., Advances in Neural Information Processing Systems 36: Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, New Orleans, LA, USA, December 10 - 16, 2023. Yao, S.; Zhao, J.; Yu, D.; Du, N.; Shafran, I.; Narasimhan, K. R.; and Cao, Y. 2023b. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net. Zeng, A.; Liu, M.; Lu, R.; Wang, B.; Liu, X.; Dong, Y.; and Tang, J. 2024. AgentTuning: Enabling Generalized Agent Abilities for LLMs. In Ku, L.; Martins, A.; and Srikumar, V., eds., Findings of the Association for Computational Lin- guistics, ACL 2024, Bangkok, Thailand and virtual meeting, August 11-16, 2024, volume ACL 2024 of Findings of ACL, 3053–3077. Association for Computational Linguistics. Zhang, K.; Chen, H.; Li, L.; and Wang, W. 2024. Don’t Fine- Tune, Decode: Syntax Error-Free Tool Use via Constrained Decoding. arXiv:2310.07075. Zhou, S.; Xu, F. F.; Zhu, H.; Zhou, X.; Lo, R.; Sridhar, A.; Cheng, X.; Ou, T.; Bisk, Y.; Fried, D.; Alon, U.; and Neubig, G. 2024. WebArena: A Realistic Web Environment for Building Autonomous Agents. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net. Zhu, J.; Zhang, G.; Ma, X.; Xu, L.; Zhang, M.; Yang, R.; Wang, S.; Qiu, K.; Wu, Z.; Dai, Q.; Ma, R.; Liu, B.; Yang, Y.; Luo, C.; Yang, Z.; Li, L.; Wang, L.; Chen, W.; Geng, X.; and Guo, B. 2026. RE-TRAC: REcursive TRAjectory Compression for Deep Search Agents. CoRR, abs/2602.02486. Appendix Additional Experimental Results The following subsections expand RQ2–RQ4 with OOD ca- pacity results, hard-complexity trends, controlled mechanism ablations, zero-shot transfer, call-realization boundaries, and efficiency measurements. Table A2 reproduces the numerical values plotted in Main Figure 3, while the slice construc- tion protocol is documented separately inDevelopment Slice Construction. Hard/OOD Capacity Results Across the two OOD manifests, the OODA advantage is largest at the small-to-medium scales and narrows at 8B and 14B. The exact low-scale ordering varies by manifest: OOD-combo peaks at 1.7B, whereas OOD-domain-tool is essentially tied at 1.7B and 4B. Panel A: OOD-combo Task Success (n = 6,932) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B80.5450.8184.32+3.78 1.7B83.2479.7390.81+7.57 4B84.5983.2491.62+7.03 8B88.1086.7593.05+4.95 14B91.3090.4594.20+2.90 Panel B: Canonical Task Success (n = 6,590) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B87.3055.1491.08+3.78 1.7B90.8191.6297.84+6.22 4B91.8992.1598.38+6.23 8B94.0593.6098.92+4.87 14B96.2295.4199.19+2.97 Table A1: Results on two ToolDial OOD manifests. Panel A reports Task Success on OOD-combo, and Panel B reports Canonical Task Success on OOD-domain-tool (previously referred to as Hard Canonical Task Success). OODA−Best 1-Pass denotes OODA Specialized minus the stronger of Direct-LoRA and ReAct-LoRA at the same backbone scale. Scale Long History Multi-tool Missing Info. State Change Active Const. Deep Deps. Parallel Calls 1.7B16.313.815.914.713.114.43.2 4B12.110.412.811.59.810.92.7 8B6.45.26.15.84.95.41.8 14B3.83.23.63.42.93.11.1 Table A2: Numerical values plotted in Main Figure 3. Each cell is the mean Task Success gain of OODA Specialized over Direct-LoRA on the corresponding high-severity development slice, averaged over multiple training seeds and reported in percentage points. The first six columns characterize state and readiness complexity; Parallel Calls characterizes action expansion. Panel A: OOD Manifest Specification ManifestUnitHeld-out structureMetricSize OOD-comboinstancestool-use combinationsTask Success6,932 OOD-domain-toolinstancesdomain× toolCanonical Task Success6,590 Panel B: Execution-Grounding Error Breakdown MethodPremature CallStale/Ungrounded Argument Direct-LoRA45/500 (9.0%)38/500 (7.6%) ReAct-LoRA53/500 (10.6%)40/500 (8.0%) Direct-SC@443/500 (8.6%)35/500 (7.0%) OODA Joint33/500 (6.6%)25/500 (5.0%) OODA Shared23/500 (4.6%)18/500 (3.6%) OODA Specialized15/500 (3.0%)8/500 (1.6%) Table A3: Panel A specifies the two ToolDial OOD evaluation manifests. Panel B reports execution-grounding error counts and rates on the fixed 500-turn rare-error sample corresponding to Main Figure 4(b). Percentages in Panel B use all 500 turns as the denominator; lower is better. Appendix Additional Experimental Results The following subsections expand RQ2–RQ4 with OOD ca- pacity results, hard-complexity trends, controlled mechanism ablations, zero-shot transfer, call-realization boundaries, and efficiency measurements. Table A2 reproduces the numerical values plotted in Main Figure 3, while the slice construc- tion protocol is documented separately inDevelopment Slice Construction. Hard/OOD Capacity Results Across the two OOD manifests, the OODA advantage is largest at the small-to-medium scales and narrows at 8B and 14B. The exact low-scale ordering varies by manifest: OOD-combo peaks at 1.7B, whereas OOD-domain-tool is essentially tied at 1.7B and 4B. Panel A: OOD-combo Task Success (n = 6,932) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B80.5450.8184.32+3.78 1.7B83.2479.7390.81+7.57 4B84.5983.2491.62+7.03 8B88.1086.7593.05+4.95 14B91.3090.4594.20+2.90 Panel B: Canonical Task Success (n = 6,590) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B87.3055.1491.08+3.78 1.7B90.8191.6297.84+6.22 4B91.8992.1598.38+6.23 8B94.0593.6098.92+4.87 14B96.2295.4199.19+2.97 Table A1: Results on two ToolDial OOD manifests. Panel A reports Task Success on OOD-combo, and Panel B reports Canonical Task Success on OOD-domain-tool (previously referred to as Hard Canonical Task Success). OODA−Best 1-Pass denotes OODA Specialized minus the stronger of Direct-LoRA and ReAct-LoRA at the same backbone scale. Scale Long History Multi-tool Missing Info. State Change Active Const. Deep Deps. Parallel Calls 1.7B16.313.815.914.713.114.43.2 4B12.110.412.811.59.810.92.7 8B6.45.26.15.84.95.41.8 14B3.83.23.63.42.93.11.1 Table A2: Numerical values plotted in Main Figure 3. Each cell is the mean Task Success gain of OODA Specialized over Direct-LoRA on the corresponding high-severity development slice, averaged over multiple training seeds and reported in percentage points. The first six columns characterize state and readiness complexity; Parallel Calls characterizes action expansion. Panel A: OOD Manifest Specification ManifestUnitHeld-out structureMetricSize OOD-comboinstancestool-use combinationsTask Success6,932 OOD-domain-toolinstancesdomain× toolCanonical Task Success6,590 Panel B: Execution-Grounding Error Breakdown MethodPremature CallStale/Ungrounded Argument Direct-LoRA45/500 (9.0%)38/500 (7.6%) ReAct-LoRA53/500 (10.6%)40/500 (8.0%) Direct-SC@443/500 (8.6%)35/500 (7.0%) OODA Joint33/500 (6.6%)25/500 (5.0%) OODA Shared23/500 (4.6%)18/500 (3.6%) OODA Specialized15/500 (3.0%)8/500 (1.6%) Table A3: Panel A specifies the two ToolDial OOD evaluation manifests. Panel B reports execution-grounding error counts and rates on the fixed 500-turn rare-error sample corresponding to Main Figure 4(b). Percentages in Panel B use all 500 turns as the denominator; lower is better. Appendix Additional Experimental Results The following subsections expand RQ2–RQ4 with OOD ca- pacity results, hard-complexity trends, controlled mechanism ablations, zero-shot transfer, call-realization boundaries, and efficiency measurements. Table A2 reproduces the numerical values plotted in Main Figure 3, while the slice construc- tion protocol is documented separately inDevelopment Slice Construction. Hard/OOD Capacity Results Across the two OOD manifests, the OODA advantage is largest at the small-to-medium scales and narrows at 8B and 14B. The exact low-scale ordering varies by manifest: OOD-combo peaks at 1.7B, whereas OOD-domain-tool is essentially tied at 1.7B and 4B. Panel A: OOD-combo Task Success (n = 6,932) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B80.5450.8184.32+3.78 1.7B83.2479.7390.81+7.57 4B84.5983.2491.62+7.03 8B88.1086.7593.05+4.95 14B91.3090.4594.20+2.90 Panel B: Canonical Task Success (n = 6,590) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B87.3055.1491.08+3.78 1.7B90.8191.6297.84+6.22 4B91.8992.1598.38+6.23 8B94.0593.6098.92+4.87 14B96.2295.4199.19+2.97 Table A1: Results on two ToolDial OOD manifests. Panel A reports Task Success on OOD-combo, and Panel B reports Canonical Task Success on OOD-domain-tool (previously referred to as Hard Canonical Task Success). OODA−Best 1-Pass denotes OODA Specialized minus the stronger of Direct-LoRA and ReAct-LoRA at the same backbone scale. Scale Long History Multi-tool Missing Info. State Change Active Const. Deep Deps. Parallel Calls 1.7B16.313.815.914.713.114.43.2 4B12.110.412.811.59.810.92.7 8B6.45.26.15.84.95.41.8 14B3.83.23.63.42.93.11.1 Table A2: Numerical values plotted in Main Figure 3. Each cell is the mean Task Success gain of OODA Specialized over Direct-LoRA on the corresponding high-severity development slice, averaged over multiple training seeds and reported in percentage points. The first six columns characterize state and readiness complexity; Parallel Calls characterizes action expansion. Panel A: OOD Manifest Specification ManifestUnitHeld-out structureMetricSize OOD-comboinstancestool-use combinationsTask Success6,932 OOD-domain-toolinstancesdomain× toolCanonical Task Success6,590 Panel B: Execution-Grounding Error Breakdown MethodPremature CallStale/Ungrounded Argument Direct-LoRA45/500 (9.0%)38/500 (7.6%) ReAct-LoRA53/500 (10.6%)40/500 (8.0%) Direct-SC@443/500 (8.6%)35/500 (7.0%) OODA Joint33/500 (6.6%)25/500 (5.0%) OODA Shared23/500 (4.6%)18/500 (3.6%) OODA Specialized15/500 (3.0%)8/500 (1.6%) Table A3: Panel A specifies the two ToolDial OOD evaluation manifests. Panel B reports execution-grounding error counts and rates on the fixed 500-turn rare-error sample corresponding to Main Figure 4(b). Percentages in Panel B use all 500 turns as the denominator; lower is better. Appendix Additional Experimental Results The following subsections expand RQ2–RQ4 with OOD ca- pacity results, hard-complexity trends, controlled mechanism ablations, zero-shot transfer, call-realization boundaries, and efficiency measurements. Table A2 reproduces the numerical values plotted in Main Figure 3, while the slice construc- tion protocol is documented separately inDevelopment Slice Construction. Hard/OOD Capacity Results Across the two OOD manifests, the OODA advantage is largest at the small-to-medium scales and narrows at 8B and 14B. The exact low-scale ordering varies by manifest: OOD-combo peaks at 1.7B, whereas OOD-domain-tool is essentially tied at 1.7B and 4B. Panel A: OOD-combo Task Success (n = 6,932) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B80.5450.8184.32+3.78 1.7B83.2479.7390.81+7.57 4B84.5983.2491.62+7.03 8B88.1086.7593.05+4.95 14B91.3090.4594.20+2.90 Panel B: Canonical Task Success (n = 6,590) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B87.3055.1491.08+3.78 1.7B90.8191.6297.84+6.22 4B91.8992.1598.38+6.23 8B94.0593.6098.92+4.87 14B96.2295.4199.19+2.97 Table A1: Results on two ToolDial OOD manifests. Panel A reports Task Success on OOD-combo, and Panel B reports Canonical Task Success on OOD-domain-tool (previously referred to as Hard Canonical Task Success). OODA−Best 1-Pass denotes OODA Specialized minus the stronger of Direct-LoRA and ReAct-LoRA at the same backbone scale. Scale Long History Multi-tool Missing Info. State Change Active Const. Deep Deps. Parallel Calls 1.7B16.313.815.914.713.114.43.2 4B12.110.412.811.59.810.92.7 8B6.45.26.15.84.95.41.8 14B3.83.23.63.42.93.11.1 Table A2: Numerical values plotted in Main Figure 3. Each cell is the mean Task Success gain of OODA Specialized over Direct-LoRA on the corresponding high-severity development slice, averaged over multiple training seeds and reported in percentage points. The first six columns characterize state and readiness complexity; Parallel Calls characterizes action expansion. Panel A: OOD Manifest Specification ManifestUnitHeld-out structureMetricSize OOD-comboinstancestool-use combinationsTask Success6,932 OOD-domain-toolinstancesdomain× toolCanonical Task Success6,590 Panel B: Execution-Grounding Error Breakdown MethodPremature CallStale/Ungrounded Argument Direct-LoRA45/500 (9.0%)38/500 (7.6%) ReAct-LoRA53/500 (10.6%)40/500 (8.0%) Direct-SC@443/500 (8.6%)35/500 (7.0%) OODA Joint33/500 (6.6%)25/500 (5.0%) OODA Shared23/500 (4.6%)18/500 (3.6%) OODA Specialized15/500 (3.0%)8/500 (1.6%) Table A3: Panel A specifies the two ToolDial OOD evaluation manifests. Panel B reports execution-grounding error counts and rates on the fixed 500-turn rare-error sample corresponding to Main Figure 4(b). Percentages in Panel B use all 500 turns as the denominator; lower is better. Panel A: OOD-combo Task Success (n = 6,932) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B80.5450.8184.32+3.78 1.7B83.2479.7390.81+7.57 4B84.5983.2491.62+7.03 8B88.1086.7593.05+4.95 14B91.3090.4594.20+2.90 Panel B: Canonical Task Success (n = 6,590) Scale Direct-LoRA ReAct-LoRA OODA Specialized OODA− Best 1-Pass 0.6B87.3055.1491.08+3.78 1.7B90.8191.6297.84+6.22 4B91.8992.1598.38+6.23 8B94.0593.6098.92+4.87 14B96.2295.4199.19+2.97 Table A1: Results on two ToolDial OOD manifests. Panel A reports Task Success on OOD-combo, and Panel B reports Canonical Task Success on OOD-domain-tool (previously referred to as Hard Canonical Task Success). OODA−Best 1-Pass denotes OODA Specialized minus the stronger of Direct-LoRA and ReAct-LoRA at the same backbone scale. Scale Long History Multi-tool Missing Info. State Change Active Const. Deep Deps. Parallel Calls 1.7B16.313.815.914.713.114.43.2 4B12.110.412.811.59.810.92.7 8B6.45.26.15.84.95.41.8 14B3.83.23.63.42.93.11.1 Table A2: Numerical values plotted in Main Figure 3. Each cell is the mean Task Success gain of OODA Specialized over Direct-LoRA on the corresponding high-severity development slice, averaged over multiple training seeds and reported in percentage points. The first six columns characterize state and readiness complexity; Parallel Calls characterizes action expansion. Panel A: OOD Manifest Specification ManifestUnitHeld-out structureMetricSize OOD-comboinstancestool-use combinationsTask Success6,932 OOD-domain-toolinstancesdomain× toolCanonical Task Success6,590 Panel B: Execution-Grounding Error Breakdown MethodPremature CallStale/Ungrounded Argument Direct-LoRA9.0%7.5% ReAct-LoRA10.5%8.0% Direct-SC@48.5%7.0% OODA Joint6.5%5.0% OODA Shared4.5%3.5% OODA Specialized3.0%1.5% Table A3: Panel A specifies the two ToolDial OOD evaluation manifests. Panel B reports execution-grounding error rates on the fixed 500-turn rare-error sample corresponding to Main Figure 4(b). Rates are rounded to the nearest 0.5 percentage point to match the visualization; lower is better. Mechanism Ablations Throughout this subsection, Full OODA denotes OODA Specialized without any component removed. We compare five controlled variants: w/o Orient removes the Orient stage; w/o Decide–Act Split merges decision formation with action realization; w/o Typed States replaces typed intermediate states with free-form text; w/o Downstream History restricts downstream stages to typed upstream states and tool schemas; and w/o Stage-specific Adapters shares one adapter across all stages. Table A4 separates the overall mechanism metrics from the three task-structure slices used in Main Figure 4(a). Setting Task Success State Slot F1TCC Ask-vs- Act F1 Long History Missing Info. Multi- tool Full OODA85.082.099.098.084.083.081.0 w/o Downstream History81.580.096.096.080.578.077.0 w/o Typed States82.7–98.681.074.075.0 w/o Orient77.669.486.297.175.066.072.0 w/o Decide–Act Split79.578.094.095.577.573.071.0 w/o Stage-specific Adapters83.580.598.097.582.080.079.0 Table A4: Mechanism analysis on 1,250 development turns from 600 dialogues (%). The first four metrics use the full analysis set; the final three columns report Task Success on the corresponding subsets. TCC denotes Typed Constraint Consistency. Schema Validity for w/o Typed States is 99.6%. Normalized Transfer Advantage Definition For the BFCL and MTU-Eval curves in Main Figure 5, we compare OODA Specialized withα-UMi at each backbone scale. For benchmarkb, scales, and reported metricj, define the direction-normalized margin d b,s,j = η j S (b) OODA,j (s)− S (b) α-UMi,j (s) ,(A1) whereη j = +1for higher-is-better metrics andη j =−1 for lower-is-better metrics. The benchmark-level margin is the arithmetic mean over the metric setJ b used by the main-paper visualization: m b,s = 1 |J b | X j∈J b d b,s,j .(A2) The normalized transfer advantage is NTA b,s = m b,s max s ′ m b,s ′ .(A3) Normalization is performed independently within each benchmark. MTU-Eval uses the six headline columns in Table A6. BFCL uses the arithmetic mean of the four track- wise OODA-minus-α-UMi margins in Table A8: Overall, Non-Live, Live, and Multi-turn. Scale BFCLMTU-Eval Mean Margin NTA Mean Margin NTA 0.6B 6.100 1.000 0.410 0.628 1.7B 5.395 0.884 0.653 1.000 4B4.100 0.672 0.550 0.842 8B2.875 0.471 0.412 0.630 14B1.900 0.311 0.300 0.459 Table A5: Underlying margins and benchmark- wise normalized values. Margins are OODA Spe- cialized minusα-UMi after direction normaliza- tion and averaging over the metric set defined above. MTU-Bench Transfer Results Models retain their ToolDial-trained adapters and are eval- uated without MTU-Bench training examples or in-context demonstrations. We use the full M-M, M-S, S-M, and S- S splits from the local MTU-Instruct/MTU-Eval snapshot. The API catalog embedded in each question is parsed and normalized before evaluation. Scores are computed with the officialMTU-Eval/cal_score.pyimplementation. All methods use greedy decoding, and OODA Specialized uses the history-grounded controller. The six-metric mean margin used in Main Figure 5 peaks at 1.7B and decreases from 4B through 14B. Improvements in task success are smaller than the gains in turn-, tool-, and parameter-level metrics. S-M remains the lowest-scoring single-turn category at every scale. MTU metric key. M-M, M-S, S-M, and S-S denote multi- turn multi-tool, multi-turn single-tool, single-turn multi-tool, and single-turn single-tool. Tool Sel. and Param Sel. denote the official tool-selection and parameter-selection submetrics. Turn Rate, Soft Turn, and Task Process are reproduced directly from the official MTU-Eval output; S-M Avg. and S-S Avg. are the scorer’s category averages. Values are reported in percentage points without additional rescaling. Call-Realization Boundary: BFCL All systems retain their ToolDial-trained adapters and are evaluated without BFCL training examples or in-context demonstrations. We use greedy decoding and score the Over- all, Non-Live, Live, and Multi-turn tracks withbfcl-eval 2026.3.23. Direct-LoRA and ReAct-LoRA use one model call, Direct-SC@4 uses four samples, andα-UMi uses its Planner, Caller, and Summarizer modules. OODA Joint uses one pass, OODA Shared uses one shared adapter across four stages, and OODA Specialized uses a separate adapter for each stage. OODA Specialized obtains the highest score on every reported BFCL track and backbone scale. Mechanism Ablations Throughout this subsection, Full OODA denotes OODA Specialized without any component removed. We compare five controlled variants: w/o Orient removes the Orient stage; w/o Decide–Act Split merges decision formation with action realization; w/o Typed States replaces typed intermediate states with free-form text; w/o Downstream History restricts downstream stages to typed upstream states and tool schemas; and w/o Stage-specific Adapters shares one adapter across all stages. Table A4 separates the overall mechanism metrics from the three task-structure slices used in Main Figure 4(a). Setting Task Success State Slot F1TCC Ask-vs- Act F1 Long History Missing Info. Multi- tool Full OODA85.082.099.098.084.083.081.0 w/o Downstream History81.580.096.096.080.578.077.0 w/o Typed States82.7–98.681.074.075.0 w/o Orient77.669.486.297.175.066.072.0 w/o Decide–Act Split79.578.094.095.577.573.071.0 w/o Stage-specific Adapters83.580.598.097.582.080.079.0 Table A4: Mechanism analysis on 1,250 development turns from 600 dialogues (%). The first four metrics use the full analysis set; the final three columns report Task Success on the corresponding subsets. TCC denotes Typed Constraint Consistency. Schema Validity for w/o Typed States is 99.6%. Normalized Transfer Advantage Definition For the BFCL and MTU-Eval curves in Main Figure 5, we compare OODA Specialized withα-UMi at each backbone scale. For benchmarkb, scales, and reported metricj, define the direction-normalized margin d b,s,j = η j S (b) OODA,j (s)− S (b) α-UMi,j (s) ,(A1) whereη j = +1for higher-is-better metrics andη j =−1 for lower-is-better metrics. The benchmark-level margin is the arithmetic mean over the metric setJ b used by the main-paper visualization: m b,s = 1 |J b | X j∈J b d b,s,j .(A2) The normalized transfer advantage is NTA b,s = m b,s max s ′ m b,s ′ .(A3) Normalization is performed independently within each benchmark. MTU-Eval uses the six headline columns in Table A6. BFCL uses the arithmetic mean of the four track- wise OODA-minus-α-UMi margins in Table A8: Overall, Non-Live, Live, and Multi-turn. Scale BFCLMTU-Eval Mean Margin NTA Mean Margin NTA 0.6B 6.100 1.000 0.410 0.628 1.7B 5.395 0.884 0.653 1.000 4B4.100 0.672 0.550 0.842 8B2.875 0.471 0.412 0.630 14B1.900 0.311 0.300 0.459 Table A5: Underlying margins and benchmark- wise normalized values. Margins are OODA Spe- cialized minusα-UMi after direction normaliza- tion and averaging over the metric set defined above. MTU-Bench Transfer Results Models retain their ToolDial-trained adapters and are eval- uated without MTU-Bench training examples or in-context demonstrations. We use the full M-M, M-S, S-M, and S- S splits from the local MTU-Instruct/MTU-Eval snapshot. The API catalog embedded in each question is parsed and normalized before evaluation. Scores are computed with the officialMTU-Eval/cal_score.pyimplementation. All methods use greedy decoding, and OODA Specialized uses the history-grounded controller. The six-metric mean margin used in Main Figure 5 peaks at 1.7B and decreases from 4B through 14B. Improvements in task success are smaller than the gains in turn-, tool-, and parameter-level metrics. S-M remains the lowest-scoring single-turn category at every scale. MTU metric key. M-M, M-S, S-M, and S-S denote multi- turn multi-tool, multi-turn single-tool, single-turn multi-tool, and single-turn single-tool. Tool Sel. and Param Sel. denote the official tool-selection and parameter-selection submetrics. Turn Rate, Soft Turn, and Task Process are reproduced directly from the official MTU-Eval output; S-M Avg. and S-S Avg. are the scorer’s category averages. Values are reported in percentage points without additional rescaling. Call-Realization Boundary: BFCL All systems retain their ToolDial-trained adapters and are evaluated without BFCL training examples or in-context demonstrations. We use greedy decoding and score the Over- all, Non-Live, Live, and Multi-turn tracks withbfcl-eval 2026.3.23. Direct-LoRA and ReAct-LoRA use one model call, Direct-SC@4 uses four samples, andα-UMi uses its Planner, Caller, and Summarizer modules. OODA Joint uses one pass, OODA Shared uses one shared adapter across four stages, and OODA Specialized uses a separate adapter for each stage. OODA Specialized obtains the highest score on every reported BFCL track and backbone scale. Mechanism Ablations Throughout this subsection, Full OODA denotes OODA Specialized without any component removed. We compare five controlled variants: w/o Orient removes the Orient stage; w/o Decide–Act Split merges decision formation with action realization; w/o Typed States replaces typed intermediate states with free-form text; w/o Downstream History restricts downstream stages to typed upstream states and tool schemas; and w/o Stage-specific Adapters shares one adapter across all stages. Table A4 separates the overall mechanism metrics from the three task-structure slices used in Main Figure 4(a). Setting Task Success State Slot F1TCC Ask-vs- Act F1 Long History Missing Info. Multi- tool Full OODA85.082.099.098.084.083.081.0 w/o Downstream History81.580.096.096.080.578.077.0 w/o Typed States82.7–98.681.074.075.0 w/o Orient77.669.486.297.175.066.072.0 w/o Decide–Act Split79.578.094.095.577.573.071.0 w/o Stage-specific Adapters83.580.598.097.582.080.079.0 Table A4: Mechanism analysis on 1,250 development turns from 600 dialogues (%). The first four metrics use the full analysis set; the final three columns report Task Success on the corresponding subsets. TCC denotes Typed Constraint Consistency. Schema Validity for w/o Typed States is 99.6%. Normalized Transfer Advantage Definition For the BFCL and MTU-Eval curves in Main Figure 5, we compare OODA Specialized withα-UMi at each backbone scale. For benchmarkb, scales, and reported metricj, define the direction-normalized margin d b,s,j = η j S (b) OODA,j (s)− S (b) α-UMi,j (s) ,(A1) whereη j = +1for higher-is-better metrics andη j =−1 for lower-is-better metrics. The benchmark-level margin is the arithmetic mean over the metric setJ b used by the main-paper visualization: m b,s = 1 |J b | X j∈J b d b,s,j .(A2) The normalized transfer advantage is NTA b,s = m b,s max s ′ m b,s ′ .(A3) Normalization is performed independently within each benchmark. MTU-Eval uses the six headline columns in Table A6. BFCL uses the arithmetic mean of the four track- wise OODA-minus-α-UMi margins in Table A8: Overall, Non-Live, Live, and Multi-turn. Scale BFCLMTU-Eval Mean Margin NTA Mean Margin NTA 0.6B 6.100 1.000 0.410 0.628 1.7B 5.395 0.884 0.653 1.000 4B4.100 0.672 0.550 0.842 8B2.875 0.471 0.412 0.630 14B1.900 0.311 0.300 0.459 Table A5: Underlying margins and benchmark- wise normalized values. Margins are OODA Spe- cialized minusα-UMi after direction normaliza- tion and averaging over the metric set defined above. MTU-Bench Transfer Results Models retain their ToolDial-trained adapters and are eval- uated without MTU-Bench training examples or in-context demonstrations. We use the full M-M, M-S, S-M, and S- S splits from the local MTU-Instruct/MTU-Eval snapshot. The API catalog embedded in each question is parsed and normalized before evaluation. Scores are computed with the officialMTU-Eval/cal_score.pyimplementation. All methods use greedy decoding, and OODA Specialized uses the history-grounded controller. The six-metric mean margin used in Main Figure 5 peaks at 1.7B and decreases from 4B through 14B. Improvements in task success are smaller than the gains in turn-, tool-, and parameter-level metrics. S-M remains the lowest-scoring single-turn category at every scale. MTU metric key. M-M, M-S, S-M, and S-S denote multi- turn multi-tool, multi-turn single-tool, single-turn multi-tool, and single-turn single-tool. Tool Sel. and Param Sel. denote the official tool-selection and parameter-selection submetrics. Turn Rate, Soft Turn, and Task Process are reproduced directly from the official MTU-Eval output; S-M Avg. and S-S Avg. are the scorer’s category averages. Values are reported in percentage points without additional rescaling. Call-Realization Boundary: BFCL All systems retain their ToolDial-trained adapters and are evaluated without BFCL training examples or in-context demonstrations. We use greedy decoding and score the Over- all, Non-Live, Live, and Multi-turn tracks withbfcl-eval 2026.3.23. Direct-LoRA and ReAct-LoRA use one model call, Direct-SC@4 uses four samples, andα-UMi uses its Planner, Caller, and Summarizer modules. OODA Joint uses one pass, OODA Shared uses one shared adapter across four stages, and OODA Specialized uses a separate adapter for each stage. OODA Specialized obtains the highest score on every reported BFCL track and backbone scale. Mechanism Ablations Throughout this subsection, Full OODA denotes OODA Specialized without any component removed. We compare five controlled variants: w/o Orient removes the Orient stage; w/o Decide–Act Split merges decision formation with action realization; w/o Typed States replaces typed intermediate states with free-form text; w/o Downstream History restricts downstream stages to typed upstream states and tool schemas; and w/o Stage-specific Adapters shares one adapter across all stages. Table A4 separates the overall mechanism metrics from the three task-structure slices used in Main Figure 4(a). Setting Task Success State Slot F1TCC Ask-vs- Act F1 Long History Missing Info. Multi- tool Full OODA85.082.099.098.084.083.081.0 w/o Downstream History81.580.096.096.080.578.077.0 w/o Typed States82.7–98.681.074.075.0 w/o Orient77.669.486.297.175.066.072.0 w/o Decide–Act Split79.578.094.095.577.573.071.0 w/o Stage-specific Adapters83.580.598.097.582.080.079.0 Table A4: Mechanism analysis on 1,250 development turns from 600 dialogues (%). The first four metrics use the full analysis set; the final three columns report Task Success on the corresponding subsets. TCC denotes Typed Constraint Consistency. Schema Validity for w/o Typed States is 99.6%. Normalized Transfer Advantage Definition For the BFCL and MTU-Eval curves in Main Figure 5, we compare OODA Specialized withα-UMi at each backbone scale. For benchmarkb, scales, and reported metricj, define the direction-normalized margin d b,s,j = η j S (b) OODA,j (s)− S (b) α-UMi,j (s) ,(A1) whereη j = +1for higher-is-better metrics andη j =−1 for lower-is-better metrics. The benchmark-level margin is the arithmetic mean over the metric setJ b used by the main-paper visualization: m b,s = 1 |J b | X j∈J b d b,s,j .(A2) The normalized transfer advantage is NTA b,s = m b,s max s ′ m b,s ′ .(A3) Normalization is performed independently within each benchmark. MTU-Eval uses the six headline columns in Table A6. BFCL uses the arithmetic mean of the four track- wise OODA-minus-α-UMi margins in Table A8: Overall, Non-Live, Live, and Multi-turn. Scale BFCLMTU-Eval Mean Margin NTA Mean Margin NTA 0.6B 6.100 1.000 0.410 0.628 1.7B 5.395 0.884 0.653 1.000 4B4.100 0.672 0.550 0.842 8B2.875 0.471 0.412 0.630 14B1.900 0.311 0.300 0.459 Table A5: Underlying margins and benchmark- wise normalized values. Margins are OODA Spe- cialized minusα-UMi after direction normaliza- tion and averaging over the metric set defined above. MTU-Bench Transfer Results Models retain their ToolDial-trained adapters and are eval- uated without MTU-Bench training examples or in-context demonstrations. We use the full M-M, M-S, S-M, and S- S splits from the local MTU-Instruct/MTU-Eval snapshot. The API catalog embedded in each question is parsed and normalized before evaluation. Scores are computed with the officialMTU-Eval/cal_score.pyimplementation. All methods use greedy decoding, and OODA Specialized uses the history-grounded controller. The six-metric mean margin used in Main Figure 5 peaks at 1.7B and decreases from 4B through 14B. Improvements in task success are smaller than the gains in turn-, tool-, and parameter-level metrics. S-M remains the lowest-scoring single-turn category at every scale. MTU metric key. M-M, M-S, S-M, and S-S denote multi- turn multi-tool, multi-turn single-tool, single-turn multi-tool, and single-turn single-tool. Tool Sel. and Param Sel. denote the official tool-selection and parameter-selection submetrics. Turn Rate, Soft Turn, and Task Process are reproduced directly from the official MTU-Eval output; S-M Avg. and S-S Avg. are the scorer’s category averages. Values are reported in percentage points without additional rescaling. Call-Realization Boundary: BFCL All systems retain their ToolDial-trained adapters and are evaluated without BFCL training examples or in-context demonstrations. We use greedy decoding and score the Over- all, Non-Live, Live, and Multi-turn tracks withbfcl-eval 2026.3.23. Direct-LoRA and ReAct-LoRA use one model call, Direct-SC@4 uses four samples, andα-UMi uses its Planner, Caller, and Summarizer modules. OODA Joint uses one pass, OODA Shared uses one shared adapter across four stages, and OODA Specialized uses a separate adapter for each stage. OODA Specialized obtains the highest score on every reported BFCL track and backbone scale. SizeMethod M-M Task M-M Turn M-S Task M-S Turn S-M Avg. S-S Avg. 0.6BDirect-LoRA1.2750.101.1836.800.0021.80 ReAct-LoRA1.2749.502.3540.600.0022.50 α-UMi2.5351.202.9441.700.0023.10 OODA Specialized2.5352.103.5342.300.2723.20 1.7BDirect-LoRA3.8056.223.5342.170.0025.00 ReAct-LoRA3.8055.385.8846.030.0025.96 α-UMi5.0656.277.0645.820.0026.44 OODA Specialized5.0657.288.2447.020.5326.44 4BDirect-LoRA7.5962.208.2449.801.0629.33 ReAct-LoRA8.8661.509.4152.901.6030.05 α-UMi8.8662.4010.0053.201.6030.55 OODA Specialized9.4963.3010.5953.802.1330.60 8BDirect-LoRA11.3967.4011.7655.402.1332.21 ReAct-LoRA12.6666.9012.9458.102.6632.93 α-UMi12.6667.6013.5358.502.9333.25 OODA Specialized13.1268.2014.1259.003.2033.30 14BDirect-LoRA15.1971.2015.2960.003.2034.85 ReAct-LoRA15.7270.8015.8862.303.6135.40 α-UMi15.7271.5016.1862.704.0035.65 OODA Specialized16.0272.0016.4763.104.2635.70 Table A6: MTU-Bench headline results (%) across Qwen3 scales, evaluated with the official MTU-Eval scorer. M-M and M-S denote multi-turn multi-tool and multi-turn single-tool settings; S-M and S-S denote single-turn multi-tool and single-turn single-tool settings. Panel A: M-M setting SizeMethod Task Success Turn Rate Soft Turn Task Process 0.6B α-UMi2.5351.2050.3048.80 OODA Specialized2.5352.1051.2049.70 1.7B α-UMi5.0656.2755.4854.14 OODA Specialized5.0657.2856.4755.08 4Bα-UMi8.8662.4061.5559.90 OODA Specialized9.4963.3062.4060.80 8Bα-UMi12.6667.6066.8065.10 OODA Specialized13.1268.2067.4065.70 14B α-UMi15.7271.5070.8069.10 OODA Specialized16.0272.0071.3069.60 Panel B: M-S and single-turn settings SizeMethod Task Success Tool Sel. Param Sel. Turn Rate Soft Turn Task Process S-M Avg. S-S Avg. 0.6B α-UMi2.9450.8044.0041.7034.8017.000.0023.10 OODA Specialized3.5352.4045.2042.3035.9018.200.2723.20 1.7B α-UMi7.0655.8149.8945.8238.7320.410.0026.44 OODA Specialized8.2458.1451.5947.0240.0821.700.5326.44 4B α-UMi10.0063.0057.0053.2046.0025.801.6030.55 OODA Specialized10.5964.1058.3053.8047.1027.202.1330.60 8B α-UMi13.5368.2063.2058.5051.2031.802.9333.25 OODA Specialized14.1269.1064.5059.0052.1033.003.2033.30 14B α-UMi16.1872.0067.8062.7055.9036.504.0035.65 OODA Specialized16.4772.8068.9063.1056.7037.504.2635.70 Table A7: MTU-Eval metric breakdown (%) for α-UMi and OODA Specialized. MethodOverallNon-LiveLiveMulti-turn Qwen3-0.6B-Instruct Direct-LoRA0.121.500.000.00 Direct-SC@43.4414.5510.800.07 ReAct-LoRA5.1121.0716.200.11 OODA Joint10.5042.5033.500.21 α-UMi11.2045.0036.000.25 OODA Shared12.7051.5043.800.32 OODA Specialized13.5055.0048.000.35 Qwen3-1.7B-Instruct Direct-LoRA0.474.690.000.00 Direct-SC@45.0920.6714.700.19 ReAct-LoRA7.4028.6622.050.28 OODA Joint15.1255.1646.300.57 α-UMi15.8757.9649.000.62 OODA Shared17.1663.7355.880.70 OODA Specialized17.8666.8359.590.75 Qwen3-4B-Instruct Direct-LoRA3.0022.005.000.10 Direct-SC@48.4936.4021.800.37 ReAct-LoRA11.2443.6030.200.51 OODA Joint20.6067.5058.500.95 α-UMi21.3070.0061.001.00 OODA Shared22.4174.2266.201.13 OODA Specialized23.0076.5069.001.20 Qwen3-8B-Instruct Direct-LoRA7.2038.0013.000.30 Direct-SC@412.6650.0029.800.61 ReAct-LoRA15.3956.0038.200.77 OODA Joint24.8076.0067.001.30 α-UMi25.4078.0069.001.35 OODA Shared26.2480.9272.581.48 OODA Specialized26.7082.5074.501.55 Qwen3-14B-Instruct Direct-LoRA11.5050.0022.000.60 Direct-SC@416.5159.9037.600.91 ReAct-LoRA19.0264.8545.401.07 OODA Joint27.7081.5072.501.61 α-UMi28.2083.0074.001.65 OODA Shared28.7984.9576.281.78 OODA Specialized29.1086.0077.501.85 Table A8: BFCL results across Qwen3 backbone sizes. Overall is the aggregate score; Non-Live, Live, and Multi-turn are the corresponding BFCL tracks. Bold values indicate the best result within each backbone block. Efficiency Trade-off Method Nominal calls Output tokensLatencyMemory Task Success Direct-LoRA11881.00×1.00×78.67 ReAct-LoRA14321.38×1.00×73.18 Direct-SC@447522.18×1.01×78.90 OODA Shared4 nominal4682.42×1.03×84.78 OODA Specialized4 nominal4212.36×1.05×85.46 Method Nominal calls Output tokensLatencyMemory Task Success Direct-LoRA11881.00×1.00×78.67 ReAct-LoRA14321.38×1.00×73.18 Direct-SC@447522.18×1.01×78.90 OODA Shared4 nominal4682.42×1.03×84.78 OODA Specialized4 nominal4212.36×1.05×85.46 Table A10: Reported 1.7B ToolDial inference cost (top) and Task Success versus normalized inference latency (bottom). Output tokens are the total generated tokens across all model invocations for a turn; latency and memory are normalized to Direct-LoRA. . 0102030405001020304050 Negative gradient-cosine rate (%) within each backbone - lower is better Observe-Act Orient-Act Decide-Act Observe-Orient Orient-Decide Observe-Decide -20.8 p -17.0 p -8.3 p -4.0 p -4.0 p +5.6 p -22.0 p -14.0 p -9.0 p -3.0 p -5.0 p +4.0 p 1.7B4B Legacy typed OODAConstraint-enforced OODA Figure A1: Stage-level negative gradient-cosine rates for OODA Shared models trained under the legacy and enriched profiles at 1.7B and 4B. For each stage pair, the rate is the fraction of 128 sampled examples per seed whose per-example gradient cosine is negative, averaged over three seeds. Annotations show the percentage-point change from the legacy to the enriched profile; lower is better. For each stage pair(i,j), we compute the per-example cosine: c (e) ij = (g (e) i ) ⊤ g (e) j ∥g (e) i ∥ 2 ∥g (e) j ∥ 2 .(A6) The negative-cosine rate for pair(i,j)within seedkis the fraction of theN = 128sampled examples whose per- example cosine is negative, r (k) ij = 1 N N X e=1 1[c (e,k) ij < 0].(A7) The figure reports the arithmetic mean ofr (k) ij over three training seeds. Each seed in Figure A2 uses 256 examples stratified by trajectory length. We average per-example cosines for each stage pair and length bucket at step 50 and step 13,000, take Table A9: Reported 1.7B ToolDial inference cost (top) and Task Success versus normalized inference latency (bottom). Output tokens are the total generated tokens across all model invocations for a turn; latency and memory are normalized to Direct-LoRA. Mechanism Diagnostics State–Action Competition We directly operationalize state–action competition on the 1,250-turn mechanism set drawn from 600 development dia- logues. A turn is eligible only when the model reconstructs the action-relevant Observe state correctly and predicts the correct Orient response mode. Action-relevant state correct- ness covers the selected entity, active slot–value assignments, inactive or superseded values, argument provenance, and missing required inputs. The Orient prediction must match one of five reference labels: Solvable_With_Tool, Need_Clarification, Re- spond_Directly, Recover_From_Failure, or Done. The analysis uses the intersection of eligible turns across OODA Joint, OODA Shared, OODA Specialized, and w/o Decide–Act Split. We define the State–Action Contradiction Rate (SACR) as SACR = N contradictory N eligible .(A4) Here,N contradictory counts eligible turns whose final action contradicts the correctly reconstructed state, andN eligible is the common eligible-turn count. Lower is better. A final action is contradictory if it satisfies at least one of three conditions. A response-mode contradiction produces a tool call or non-tool response incompatible with the correct Orient mode. A superseded-value contradiction binds a value marked inactive or superseded in the active state. An unsupported or wrong-field contradiction uses an argument that cannot be traced to active user evidence, a completed tool return, or an allowed deterministic transformation, or copies a value from the wrong entity, result row, or semantic field despite a correctly selected entity. When multiple conditions hold, the primary label is assigned in the order response mode, superseded value, then unsupported or wrong field. MethodReported SACR↓ OODA Joint7.8% OODA Shared5.6% OODA Specialized3.9% w/o Decide–Act Split10.7% Table A10: State–Action Contradiction Rates on the common eligible subset. Lower is better. SACR decreases from 7.8% for OODA Joint to 5.6% for OODA Shared and 3.9% for OODA Specialized. Removing the Decide–Act separation raises the rate to 10.7%, an ob- served increase of 6.8 percentage points relative to OODA Specialized. Constraint-Policy Alignment Across Training and Inference We compare Legacy typed OODA and Constraint-enforced OODA in the four-stage architecture. The two configura- tions differ in readiness, active-state, and argument-source constraints represented by ConstraintPolicy. Constraint- enforced OODA encodes execution readiness, distinguishes active from superseded values, and associates each realized argument with an admissible source. At inference time, these fields gate tool execution, block inactive bindings, and validate argument provenance. Configuration Schema Validity Grounded Realization Legacy typed OODA, 4B 500/500383/500 Constraint-enforced OODA, 4B 500/500500/500 Table A11: Rollout results for Legacy typed OODA and Constraint-enforced OODA. Both configurations produce 500/500 schema-valid outputs, while Constraint-enforced OODA raises grounded realization from 383/500 to 500/500. On the superseded-value-eligible subset, stale binding decreases from 100.0% to 0.0%. Across three seeds, the Constraint-enforced OODA Shared models show the largest reductions in negative gradient-cosine rates for pairs involving Act, where typed decision states are converted into concrete tool calls. Gradient Analysis Protocol For exampleeand stages, we backpropagate the stage-specific loss through the shared LoRA parameters: g (e) s =∇ θ LoRA L (e) s , s∈O,R,D,A.(A5) For each stage pair(i,j), we compute the per-example cosine: c (e) ij = (g (e) i ) ⊤ g (e) j ∥g (e) i ∥ 2 ∥g (e) j ∥ 2 .(A6) The negative-cosine rate for pair(i,j)within seedkis the fraction of theN = 128sampled examples whose per- example cosine is negative, r (k) ij = 1 N N X e=1 1[c (e,k) ij < 0].(A7) The figure reports the arithmetic mean ofr (k) ij over three training seeds. Each seed in Figure A2 uses 256 examples in each trajectory- length bucket. We average per-example cosines for each stage pair and bucket at step 50 and step 13,000, take the within-seed difference, and then average over the three seeds. RQ6: How Does OODA Ground Arguments? Case setup. We examine ToolDial test example tooldial:test:240:4using Qwen3-1.7B with seed 42. The user requests detailed information about a nearby attraction. The preceding Nearby Search result contains two candidates. The row for Historical Museum includes the OSM identifierosm_id_001, the local place identifier museum_001, and the Wikidata identifierQ123456; the row for Central Park contains a different identifier triple. The user then states, “I chooseosm_id_001.” The downstream detail tool,Place_properties, requires the selected attraction’s Wikidata identifier in itsxidargument. The cor- rect call is thereforePlace_properties(lang="en", xid="Q123456"). Direct-LoRA and ReAct-LoRA. Both Direct-LoRA and ReAct-LoRA identify the intended attraction and select the correctPlace_propertiestool, but instantiatexidwith museum_001. Their prediction is thus correct at the en- tity and tool levels but incorrect at the identifier-field level: museum_001is a plausible value from the selected row, yet it is the local place identifier rather than the Wikidata identi- fier required by the downstream schema. The failure reflects a direct jump from the user’s selection to action realization. Without an explicit intermediate mapping, the model copies a nearby identifier without verifying that its semantic type matches the required argument. OODA trace. OODA preserves the support chain be- fore realizing the call. Observe records the user’s se- lectionosm_id_001, resolves it to the matching His- torical Museum result row, and extracts the row’s Wiki- data identifier as the active valuePlace_properties. xid = Q123456. Orient then verifies that all re- quired arguments are available and grounded. De- cide selects a single call toPlace_properties, and Act producesPlace_properties(lang="en", xid="Q123456"). The realized argument is supported by an explicit chain from the user selection, through the matching search-result row, to the schema-compatible Wikidata field. Interpretation. The example shows that correct entity and tool selection does not guarantee identifier-field correctness. Method Nominal calls Output tokensLatencyMemory Task Success Direct-LoRA11881.00×1.00×78.67 ReAct-LoRA14321.38×1.00×73.18 Direct-SC@447522.18×1.01×78.90 OODA Shared4 nominal4682.42×1.03×84.78 OODA Specialized4 nominal4212.36×1.05×85.46 1.001.251.501.752.002.252.50 Normalized latency (Direct-LoRA = 1.0x) 72 74 76 78 80 82 84 ToolDial Task Success (%) Direct-LoRA ReAct-LoRA Direct-SC@4 Shared OODA Specialized OODA Observed Pareto frontier Table A10: Reported 1.7B ToolDial inference cost (top) and Task Success versus normalized inference latency (bottom). Output tokens are the total generated tokens across all model invocations for a turn; latency and memory are normalized to Direct-LoRA. The dashed line is the observed Pareto frontier. 0102030405001020304050 Negative gradient-cosine rate (%) within each backbone - lower is better Observe-Act Orient-Act Decide-Act Observe-Orient Orient-Decide Observe-Decide -20.8 p -17.0 p -8.3 p -4.0 p -4.0 p +5.6 p -22.0 p -14.0 p -9.0 p -3.0 p -5.0 p +4.0 p 1.7B4B Legacy typed OODAConstraint-enforced OODA Figure A1: Stage-level negative gradient-cosine rates for OODA Shared models trained under the legacy and enriched profiles at 1.7B and 4B. For each stage pair, the rate is the fraction of 128 sampled examples per seed whose per-example gradient cosine is negative, averaged over three seeds. Annotations show the percentage-point change from the legacy to the enriched profile; lower is better. For each stage pair(i,j), we compute the per-example cosine: c (e) ij = (g (e) i ) ⊤ g (e) j ∥g (e) i ∥ 2 ∥g (e) j ∥ 2 .(A6) The negative-cosine rate for pair(i,j)within seedkis the fraction of theN = 128sampled examples whose per- example cosine is negative, r (k) ij = 1 N N X e=1 1[c (e,k) ij < 0].(A7) The figure reports the arithmetic mean ofr (k) ij over three training seeds. Each seed in Figure A2 uses 256 examples stratified by trajectory length. We average per-example cosines for each stage pair and length bucket at step 50 and step 13,000, take Figure A1: Stage-level negative gradient-cosine rates for OODA Shared models trained as Legacy typed OODA and Constraint- enforced OODA at 1.7B and 4B. For each stage pair, the rate is the fraction of 128 sampled examples per seed whose per-example gradient cosine is negative, averaged over three seeds. Annotations show the percentage-point change from Legacy typed OODA to Constraint-enforced OODA; lower is better. O-RO-DO-AR-DR-AD-A 2049-4096 4097-6144 6145+ Token-length bucket +0.43+0.10+0.39+0.33+0.44 +0.52 +0.24+0.28+0.21+0.34+0.25 +0.48 +0.20+0.26+0.21+0.43+0.26 +0.54 0.000.200.400.56 Δ gradient cosine (final - early) Figure A2: Change in mean per-example stage-gradient cosine from step 50 to step 13k, stratified by trajectory length. Each cell first averages 256 per-example cosines within a seed, takes the final-minus-early difference, and then averages that difference over three seeds. Every cell increases. the within-seed difference, and then average over the three seeds. RQ6: How Does OODA Ground Arguments? Case setup. We examine ToolDial test example tooldial:test:240:4using Qwen3-1.7B with seed 42. The user requests detailed information about a nearby attraction. The preceding Nearby Search result contains two candidates. The row for Historical Museum includes the OSM identifierosm_id_001, the local place identifier museum_001, and the Wikidata identifierQ123456; the row for Central Park contains a different identifier triple. The user then states, “I chooseosm_id_001.” The downstream detail tool,Place_properties, requires the selected attraction’s Wikidata identifier in itsxidargument. The cor- rect call is thereforePlace_properties(lang="en", xid="Q123456"). Direct-LoRA and ReAct-LoRA. Both Direct-LoRA and ReAct-LoRA identify the intended attraction and select the correctPlace_propertiestool, but instantiatexidwith museum_001. Their prediction is thus correct at the en- tity and tool levels but incorrect at the identifier-field level: museum_001is a plausible value from the selected row, yet it is the local place identifier rather than the Wikidata identi- fier required by the downstream schema. The failure reflects a direct jump from the user’s selection to action realization. Without an explicit intermediate mapping, the model copies a nearby identifier without verifying that its semantic type matches the required argument. OODA trace. OODA preserves the support chain be- fore realizing the call. Observe records the user’s se- lectionosm_id_001, resolves it to the matching His- torical Museum result row, and extracts the row’s Wiki- data identifier as the active valuePlace_properties. xid = Q123456. Orient then verifies that all re- quired arguments are available and grounded. De- cide selects a single call toPlace_properties, and Act producesPlace_properties(lang="en", xid="Q123456"). The realized argument is supported by an explicit chain from the user selection, through the matching search-result row, to the schema-compatible Wikidata field. Interpretation. The example shows that correct entity and tool selection does not guarantee identifier-field correctness. FieldMeaning goalCurrent user objective or request known_factsUser, history, and tool facts with provenance entitiesEntities relevant to the current task filled_slotsActive argument slots, values, sources, and confidence unfinished_subgoals Subgoals not yet completed recent_tool_factsFacts established by recent tool outputs active_constraints Active temporal, cardinality, exclusion, and uniqueness constraints state_changesFields changed since the previous turn Table A13: Typed fields emitted by Observe. Reproducibility and Evaluation Details This section consolidates the state schema, leakage controls, implementation details, benchmark adapters, slice construc- tion, and metric definitions used throughout the paper and supplement. Observe State Fields Label Construction and Leakage Controls Stage labels use only the interaction prefix visible before the current decision. Observe is reconstructed from user turns, previous system actions, and completed tool returns. When a value changes, the old value is retained as superseded for provenance but cannot be reused. Orient is derived from this state and the current tool catalog. For executable turns, Decide is constructed from the gold tool-action structure. For non-tool modes, it encodes the authorized clarification, direct-response, recovery, or termination branch. Act contains the executed call or response and the source of each realized argument. Future user turns, the output of the current gold action, and facts revealed only after that action are excluded. An Act argument must come from an active state value, a completed tool return, or a deterministic transformation allowed by the schema. Training and Inference Details All systems use the native Qwen tokenizer with the configured context budget. We apply offline tokenization, length grouping, and dynamic padding, and disable cross-example packing. The backbone is frozen during LoRA training. OODA Shared reuses one adapter at every stage; OODA Specialized stores four adapters and activates the one assigned to the current stage. OODA variants use the four-stage controller described above. When validation fails, the controller applies at most one contract retry. If the failure is a readiness violation, it reroutes once through the readiness controller before continuing or returning an authorized non-tool mode. Direct-SC@4 uses a fixed aggregation rule. Figure A2: Change in mean per-example stage-gradient cosine from step 50 to step 13k, stratified by trajectory length. Each seed contributes 256 examples to each trajectory-length bucket. Each cell averages the corresponding per-example cosines within a seed, takes the final-minus-early difference, and then averages that difference over three seeds. Every cell increases. Reproducibility and Evaluation Details This section consolidates the state schema, leakage controls, implementation details, benchmark adapters, slice construc- tion, and metric definitions used throughout the paper and supplement. Observe State Fields FieldMeaning goalCurrent user objective or request known_factsUser, history, and tool facts with provenance entitiesEntities relevant to the current task filled_slotsActive argument slots, values, sources, and confidence unfinished_subgoals Subgoals not yet completed recent_tool_factsFacts established by recent tool outputs active_constraints Active temporal, cardinality, exclusion, and uniqueness constraints state_changesFields changed since the previous turn Table A12: Typed fields emitted by Observe. Label Construction and Leakage Controls Stage labels use only the interaction prefix visible before the current decision. Observe is reconstructed from user turns, previous system actions, and completed tool returns. When a value changes, the old value is retained as superseded for provenance but cannot be reused. Orient is derived from this state and the current tool catalog. For executable turns, Decide is constructed from the gold tool-action structure. For non-tool modes, it encodes the authorized clarification, direct-response, recovery, or termination branch. Act contains the executed call or response and the source of each realized argument. Future user turns, the output of the current gold action, and facts revealed only after that action are excluded. An Act argument must come from an active state value, a completed tool return, or a deterministic transformation allowed by the schema. Training and Inference Details All systems use the native Qwen tokenizer with the configured context budget. We apply offline tokenization, length grouping, 0102030405001020304050 Negative gradient-cosine rate (%) within each backbone - lower is better Observe-Act Orient-Act Decide-Act Observe-Orient Orient-Decide Observe-Decide -20.8 p -17.0 p -8.3 p -4.0 p -4.0 p +5.6 p -22.0 p -14.0 p -9.0 p -3.0 p -5.0 p +4.0 p 1.7B4B Legacy typed OODAConstraint-enforced OODA and dynamic padding, and disable cross-example packing. The backbone is frozen during LoRA training. OODA Shared reuses one adapter at every stage; OODA Specialized stores four adapters and activates the one assigned to the current stage. OODA variants use the four-stage controller described above. When validation fails, the controller applies at most one contract retry. If the failure is a readiness violation, it reroutes once through the readiness controller before continuing or returning an authorized non-tool mode. Direct-SC@4 uses a fixed aggregation rule. External Benchmark Protocols MTU-Bench. We evaluate the full M-M, M-S, S-M, and S-S splits from the local MTU-Instruct/MTU-Eval snapshot in a zero-shot setting. Models retain their ToolDial-trained adapters. The adapter parses and normalizes the API cat- alog embedded in each question. Scores use the official MTU-Eval/cal_score.pyimplementation. All meth- ods use greedy decoding; OODA Specialized uses the con- troller with one contract retry and one readiness reroute. BFCL. We usebfcl-eval2026.3.23 for all BFCL exper- iments and report the Overall, Non-Live, Live, and Multi-turn aggregates. Gorilla/OpenAI tool schemas are converted with BFCL’sconvert_to_toolutility and normalized before scoring. The adapter restores dotted BFCL function names after OSS-style prompt sanitization. Direct-LoRA, ReAct- LoRA, and OODA Joint schedule one model invocation; Direct-SC@4 schedules four, and the two multi-stage OODA variants schedule four nominal stage calls;α-UMi uses its Planner, Caller, and Summarizer modules. OODA uses the native four-stage prompt and the Constraint-enforced OODA configuration, with at most one contract retry and one readi- ness reroute. The four-track mean used for Main Figure 5 is defined in Normalized Transfer Advantage Definition. Development Slice Construction Table A1 reports two ToolDial OOD manifests. OOD-combo contains 6,932 instances and uses Task Success; OOD- domain-tool contains 6,590 instances and uses Canonical Task Success on OOD-domain-tool (previously referred to as Hard Canonical Task Success). The hard complexity analysis in Main Figure 3 is a separate development-slice analysis, and Table A2 reproduces its plot- ted mean differences over multiple training seeds evaluated on the same fixed slices. Its hard set is the union of turns marked for long history, missing required information, state change, multiple active constraints, multi-step tool dependencies, or parallel/multiple calls. Each full complexity manifest contains 100–150 turns. The figure uses the high-severity portion of each manifest, leaving 60–80 turns per dimension. Duplicate turns are counted once, and all qualifying turns are retained. The mechanism analysis contains 1,250 turns from 600 dis- tinct development dialogues. Table A4 reports the absolute re- sults for Full OODA and the five controlled variants on the full set and the long-history, missing-information, and multi-tool subsets. The Schema Validity of w/o Typed States is 99.6%. For rare execution errors, eligibility depends on the pred- icate and yields between 1,000 and 2,000 development turns. Main Figure 4(b) uses a fixed sample of 500 turns drawn from these pools. The same 500 turns are evaluated for all methods, and the reported rates use 500 as the denominator. Metric Definitions MetricDefinition Task SuccessEvaluator field task_success. Tool-call turns require tool_exact, argument_exact, and schema_valid; response turns follow response_correct. Tool ExactThe normalized external tool selection matches the reference tool. Schema ValidThe external call parses and satisfies the selected tool’s argument schema. Premature CallPercentage of records on which a tool is invoked before the request is executable; lower is better. Stale-or- Ungrounded Argument Percentage of turns that reuse an inactive or superseded value or contain an argument unsupported by active user evidence, a completed tool return, or an allowed deterministic transformation; lower is better. MetricDefinition Grounded Realization Percentage of turns whose realized Act arguments are supported by an active user value, completed tool return, or schema-permitted deterministic transformation. State–Action Contradiction Rate Fraction of common-eligible turns whose final action contradicts the correct action-relevant state and response mode. State Slot F1F1 over normalized active slot–value pairs; a superseded value predicted as active is a false positive. Typed Constraint Consistency Whether the final decision and realized arguments preserve explicit user constraints and tool preconditions. Ask-vs-Act F1F1 for the binary decision between tool execution and a non-tool response. Table A13: Definitions of final-output, typed-state, and diag- nostic metrics.

Instant research discovery