State Before Action: OODA-Tool Puts a Control Layer Between Context and Execution

TL;DR for operators

A tool-using agent can remember the right customer, constraint, or prior result and still make the wrong call. From State to Action: OODA-Tool for Reliable Multi-Turn Tool Use¹ treats that gap as an architectural problem rather than only a prompting problem.

Its strongest configuration separates four jobs: reconstruct the active task state, decide whether execution is actually warranted, choose a permitted action structure, and only then bind concrete arguments. On ToolDial, Specialized OODA beats Direct-LoRA at every tested Qwen3 scale, by 4.48 to 6.99 percentage points in Task Success. The gains are largest where state must survive long histories, missing information, changed values, constraints, or sequential dependencies.

The result is not well explained by extra inference alone. At Qwen3-1.7B, Direct-SC@4 also spends four samples yet reaches 78.90% Task Success, versus 85.46% for Specialized OODA. Component ablations instead point to readiness gating, typed state, and the separation of action selection from argument realization.

For higher-consequence API workflows, Cognaptus would interpret this as a case for explicit control interfaces before execution. The boundary is equally concrete: the strongest OODA configuration runs at 2.36× Direct-LoRA latency at 1.7B, its advantage narrows with larger backbones, and parallel-call expansion remains comparatively weak.

The failure can happen after the agent remembers correctly

Consider a multi-step workflow in which an agent has been told that a customer changed accounts, one required field is still missing, and a later tool expects an internal record ID rather than the customer-facing identifier used earlier.

There are several distinct decisions buried inside what looks like one function call. The agent must preserve the latest state, recognize whether it has enough information to proceed, choose the appropriate operation, and bind the exact fields expected by the API. A model can get the first of those right and still fail at the last.

That distinction is central to OODA-Tool. The authors call the broader problem state-action competition: reconstructing the current operational state and producing the next action are handled inside the same autoregressive trajectory, so pressure to emit a plausible call can interfere with the state that should constrain it.

The paper’s strongest diagnostic makes this concrete. Its State-Action Contradiction Rate is calculated only on turns where the relevant task state and response mode have already been reconstructed correctly. Specialized OODA records a 3.9% contradiction rate on that eligible subset. Remove the separation between deciding the action structure and realizing its arguments, and the rate rises to 10.7%.

The implication is narrow but consequential: correct state representation is not sufficient evidence that execution will remain consistent with that state.

Four stages turn hidden reasoning into checked interfaces

OODA-Tool decomposes the path from conversation to execution into four typed stages.

Observe reconstructs the active task state, including provenance and distinctions between current and superseded values. Orient determines whether execution is warranted or whether required information is still missing. Decide selects an action structure compatible with that readiness state. Act binds concrete arguments and emits the authorized tool call or non-tool response.

A controller checks the handoffs. It can reject a proposed action structure that conflicts with readiness, validate schemas and argument grounding, retry contract failures, or reroute a readiness violation.

This is materially different from asking a model to produce more free-form reasoning before calling a tool. The intermediate representations are typed and stage-specific, and later actions are constrained by earlier outputs.

The ablations help identify which pieces are doing work. On the 1,250-turn mechanism set, Full OODA reaches 85.0% Task Success. Removing Orient drops success to 77.6%; removing the Decide-Act split produces 79.5%; replacing typed states with free-form states yields 82.7%; and sharing adapters across stages yields 83.5%.

Orient produces the largest single ablation loss, with missing-information Task Success falling from 83% to 66%. That result gives execution readiness a more specific role than generic planning: it prevents the system from treating “I know what tool would eventually be needed” as equivalent to “I am authorized and sufficiently informed to call it now.”

More inference is not the main explanation

A staged architecture inevitably spends more computation, so a natural alternative explanation is that OODA simply benefits from having more chances to generate an answer.

The paper includes a useful comparator. At Qwen3-1.7B, Direct-SC@4 uses four samples and 752 generated output tokens per turn. It achieves 78.90% Task Success. Specialized OODA also uses four nominal calls, generates 421 tokens, and reaches 85.46%.

That comparison does not prove that every percentage point comes from the OODA decomposition. It does rule out the simplest interpretation that four generations by themselves account for the reported advantage.

The cross-scale results reinforce the architectural reading. Specialized OODA leads Direct-LoRA at all five Qwen3 sizes:

The narrowing margin at larger scales matters. Larger models appear to recover part of the capability that OODA imposes explicitly, which weakens any claim that the four-stage design should be treated as a universal replacement for direct function calling.

Syntax is not grounding

One appendix comparison exposes another operationally relevant distinction: a call can be perfectly schema-valid and still bind the wrong value.

In a reported 4B rollout comparison, both the legacy typed OODA configuration and a constraint-enforced version produce 500/500 schema-valid outputs. Yet grounded realization rises from 383/500 to 500/500 under the enforced constraint profile, while stale binding on the eligible subset falls from 100% to 0%.

This is best read as a mechanism test, not a second headline benchmark. Its purpose is to separate structural validity from whether arguments are actually supported by the active state and permitted provenance.

For an operator, that distinction maps directly to systems where several identifiers refer to the same entity: customer ID versus account ID, booking reference versus itinerary ID, database key versus display name. JSON validation cannot tell whether the model selected the field justified by the workflow state.

Where staged control earns its latency

The reported gains are concentrated rather than uniform. OODA helps most on long histories, missing-information cases, state changes, active constraints, and deeper sequential dependencies. Improvements are smaller on parallel calls, where the remaining difficulty is expanding one plan into several calls and correctly binding values across them.

That pattern suggests a selective deployment policy rather than an architectural mandate.

For a high-consequence workflow with mutable state, approvals, missing fields, or identifiers drawn from several sources, Cognaptus would favor exposing four machine-checkable artifacts: the current active state, an execution-readiness decision, the permitted action structure, and the provenance of bound arguments. These artifacts can also become useful audit and debugging records.

A low-risk, latency-sensitive request with little state may not justify the same path. At 1.7B, Specialized OODA reaches 85.46% Task Success versus 78.67% for Direct-LoRA, but runs at 2.36× normalized latency. Its normalized memory cost is much smaller at 1.05×, making sequential inference rather than memory the clearer operational penalty in that experiment.

The boundary is stateful sequential work, not tool use in general

The evidence is strong for comparative claims inside the evaluated setup: five Qwen3 sizes, matched baselines, component ablations, state-intensive slices, contradiction diagnostics, typed-state bottlenecks, external transfer tests, and explicit efficiency measurements all point in a similar direction.

The broader deployment claim remains less settled. Training and primary evaluation center on ToolDial and Qwen3. External evaluations retain ToolDial-trained adapters, and the FAIL-TaLMs results are internal rather than official leaderboard submissions. Typed states also do not fully replace raw history: removing downstream access to dialogue history lowers aggregate Task Success from 85.0% to 81.5%, with larger losses on long-history, missing-information, and multi-tool subsets.

Most importantly, better state control does not solve every execution problem. Parallel-call expansion and cross-call binding remain weak points. Organizations adopting this pattern would still need separate mechanisms for dependency scheduling, batch expansion, and coordination among concurrent calls.

Put a decision boundary before the API boundary

The paper changes a specific systems-design decision: whether an agent should be allowed to move directly from accumulated dialogue to executable calls.

For state-heavy or consequential workflows, the reported results favor an intermediate control layer. First reconstruct what is currently true. Then decide whether execution is warranted. Then constrain which action structure is admissible. Only after those checks should the system bind values and issue a call.

That separation matters because the paper finds failure on both sides of the usual assumption: agents can act before they are ready, and they can contradict a state they already reconstructed correctly.

The trade is not free. OODA-Tool buys reliability with sequential inference, and it buys less on workloads dominated by parallel call realization. That makes the architecture most compelling not as a default wrapper around every function call, but as a risk-sensitive control path for workflows where stale state, premature execution, or wrong-field binding carries an operational cost.

Cognaptus: Automate the Present, Incubate the Future.