Looped language models have shown promising results on reasoning benchmarks, yet their potential for agentic tool use remains largely unexplored. We study this question in compositional tool-calling settings, where models must coordinate multiple API calls, maintain intermediate state, and preserve dependencies across tool interactions. We evaluate native and retrofitted looped language models on API-Bank, BFCL, and NESTful, comparing looped and non-looped models trained under matched supervised fine-tuning recipes and varying recurrent depth at inference time. In controlled experiments, recurrent computation generally benefits compositional and dependency-aware tool use, while providing smaller and more model-dependent gains on isolated API invocation. Accuracy on multi-step tool use generally increases with recurrent depth; adaptive inference, however, achieves a more favorable compute-performance trade-off by allocating additional computation only when needed. Our results suggest that looped language models are a promising architecture for agentic systems that require reliable planning, coordination, and execution of compositional tool use workflows.
Figures & tables
Model
Training
Simple
Multiple
Parallel
Par.-Mult.
Overall
Ouro-1.4B
Base
65.3
67.0
35.0
44.5
55.4
SFT
91.8
90.0
67.5
55.5
79.3
Ouro-2.6B
Base
80.5
75.5
2.0
1.0
47.9
SFT
92.3
88.0
83.0
76.5
86.4
Qwen3-1.7B
Base
1.5
0.0
0.0
0.0
0.6
SFT
67.0
57.0
3.0
9.5
40.7
Table 1: BFCL semantic AST correctness (%; higher is better). Overall is the aggregate score across all task categories. The lower block compares looped and non-looped variants of each backbone, fine-tuned using identical data and optimization settings; looped variants use a fixed inference depth of 8 loop iterations. Base checkpoints omitted from the lower block score near zero throughout.
Model
Training
Function F1
Parameter F1
Partial
Full
Win Rate
Ouro-1.4B
Base
0.905
0.539
0.149
0.091
0.110
SFT
0.899
0.566
0.219
0.131
0.191
Ouro-2.6B
Base
0.920
0.595
0.207
0.128
0.190
SFT
0.922
0.680
0.295
0.204
0.371
Qwen3-1.7B
Base
0.000
0.000
0.000
0.000
0.000
SFT
0.000
0.000
0.000
0.000
0.000
Table 2: NESTful official evaluation (higher is better). Win Rate is the primary metric.
Table 3: API-Bank evaluation (%; higher is better). (a) Controlled comparison between looped and non-looped models trained using identical supervised fine-tuning recipes. The lower block pairs each retrofitted backbone with its non-looped counterpart; looped variants are evaluated at a fixed inference depth of 8 loop iterations. (b) Comparison against publicly released instruction-tuned checkpoints. Call Correctness measures functional API-call correctness, Exact requires an exact API-name-and-argument match, and Parse reports valid call generation.
Figure 2: BFCL semantic AST accuracy by task category as fixed recurrent depth increases. Each curve reports accuracy on Simple, Multiple, Parallel, and Parallel-Multiple tasks.
Figure 3: NESTful Win Rate as fixed recurrent depth increases. Native recurrent Ouro models benefit from additional recurrent computation, whereas the retrofitted recurrent Llama baseline remains substantially weaker.
Figure 4: Adaptive recurrent computation on BFCL and NESTful. The x-axis reports the mean recurrent depth per generated token. Adaptive stopping improves the compute-performance frontier by allocating additional recurrent iterations only when beneficial. On BFCL, adaptive stopping matches or slightly exceeds the best fixed-depth operating point while executing fewer recurrent iterations on average. On NESTful, Ouro-2.6B reaches the same Win Rate as fixed depth 4 while using fewer recurrent iterations per generated token.
Figure 5: Iterative refinement across recurrent depths. Ouro-1.4B on a two-step NESTful composition task. Calls are shown as function(argument=value) -> answer . At depth 1 the model emits a single call to a function absent from the tool catalogue and omits the dependent call; at depth 2 it recovers the two-call structure but the first function is again absent from the catalogue and the variable reference is invalid. Depths 3 and 4 match the gold sequence, including the output-to-input reference var1.output0 .
Appendix figures & tables5 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 6: Ordering and spurious-call correction. At depth 1 the output is malformed, emitting tool specifications rather than call arguments (excerpt shown truncated). At depth 2 both gold functions appear but in reversed order, followed by a call to multiply , which is absent from the tool catalogue, and an invalid variable reference. Depths 3 and 4 match the gold sequence, differing from each other only in label naming.
Figure 7: Argument correction. At depth 1 the model selects the correct first function but names its argument input_str , a parameter of a different tool in the same catalogue, duplicates it as input_str_2 , and omits the dependent call. Depths 2 through 4 match the gold sequence and are identical to one another.
Figure 8: Two distinct incorrect attempts before recovery. Depths 1 and 2 each emit a single call to a function absent from the tool catalogue and omit the required dependent call. At depth 1, the model also uses an argument name belonging to a different tool in the catalogue. Depths 3 and 4 select both gold functions and correctly pass var1.output0 , differing only in argument-key order.
Figure 9: Isolated recovery of a missing dependent call. Depth 1 emits an object with no function name, returning a computed literal, so the parser yields no calls. Depth 2 emits a first call that matches the gold sequence exactly but stops there. Depths 3 and 4 leave that first call unchanged and add the dependent call with the reference var1.output0 , isolating the recovery of the dependency from any change in function selection.
Benchmark
Candidate tools
Call structure
Dependencies
Primary challenge
API-Bank
one or more
typically ∣Cx∣=1
Ex=∅
Tool and argument grounding
BFCL Simple
∣Tx∣=1
∣Cx∣=1
Ex=∅
Argument grounding
BFCL Multiple
∣Tx∣>1
∣Cx∣=1
Ex=∅
Function selection
BFCL Parallel
one or more
∣Cx∣>1
Ex=∅
Independent call generation
BFCL Parallel-Multiple
∣Tx∣>1
∣Cx∣>1
Ex=∅
Selection and call composition
NESTful
multiple
∣Cx∣>1
typically ∣Ex∣>0
Dependency-aware execution
Appendix
Table 4: Structural comparison of the evaluated tool-calling benchmarks under the solution representation Gx=(Cx,Ex) . API-Bank emphasizes individual-call grounding, BFCL evaluates increasingly complex independent call sets, and NESTful introduces explicit output-to-input dependencies.
High-quality tool-use data is critical for training language models to interact effectively with external tools. However, existing synthetic approaches typically follow a generate-then-filter paradigm with static post-hoc verification, often yielding inefficient data with imbalanced feature distributions. We propose ToolLoop, a closed-loop framework that decomposes synthesis into three progressive stages: (1) sampling function name combinations as ground truth; (2) backward derivation of user queries; and (3) forward derivation of tool calls. At each stage, dynamic self-feedback iteratively guides the model toward high-quality generation, realizing a transition from generate-then-filter to generate-verify-refine. On the Berkeley Function Calling Leaderboard (BFCL), a 4B parameter model trained with our 11K synthetic examples achieves 86.40% accuracy in non-reasoning mode, while an Isolate variant that removes BFCL-overlapping candidate functions still reaches 86.07%. Cross-benchmark evaluation on ACEBench further demonstrates strong generalization, with 72.1% overall accuracy using only 18.3% of baseline training data.
Tool-augmented LLM agents commonly rely on step-wise atomic tool calls, where each invocation, observation, and value transfer is exposed in the main reasoning trace. This creates an execution-granularity mismatch: locally deterministic tool workflows are unfolded into repeated model-visible decisions, consuming context and forcing the model to manage low-level dataflow in the trace. We introduce HyperTool, a unified executable MCP-style tool interface that changes the model-visible unit of tool execution. A model invokes HyperTool with a code block that can call existing tools through their original schemas, manipulate returned values, and pass intermediate results locally, folding deterministic tool subroutines into a single outer call. To train models to use this interface, we synthesize HyperTool-format trajectories from cross-tool compositional tasks and verify them in real MCP environments. On MCP-Universe, HyperTool improves average accuracy from 15.69% to 35.29% on Qwen3-32B and from 9.93% to 33.33% on Qwen3-8B, and surpass GPT-OSS and Kimi-k2.5 on average accuracy, showing that our HyperTool can substantially improve multi-step tool use.
Yaxin Du, Yifan Zhou, Yujie Ge +7
Shanghai Jiao Tong University · IQuest Research · Beijing University of Aeronautics and Astronautics
When a tool-calling agent picks the wrong tool, the failure is invisible until execution: the email gets sent, the meeting gets missed. As agents take on consequential actions, one bad tool call can do real damage. We currently have no way to look inside the model and catch the mistake before it happens; this paper shows that we can. Inside the model, the choice of tool is carried by a single direction in activation space, one direction per pair of tools. Adding that direction during generation switches which tool the model picks. Across 12 instruction-tuned and 6 base models spanning Gemma 3, Qwen 3, Qwen 2.5, and Llama 3.1 (270M to 27B), this works at 83-100% accuracy on 4B+ instruction-tuned models on a 15-tool synthetic benchmark and at 77-94% on the real-API benchmark τ-bench airline. The JSON arguments that follow automatically adapt to the new tool's schema, so flipping the name is enough. The same per-tool directions also flag likely errors before they happen: queries where the model is unsure between two tools fail 21x more often than queries where it is not (Gemma 3 27B). This is not just topic injection: random vectors at the same magnitude give a 0% switch rate, and a probe within a single domain (14 airline tools that share one topic) still reads which tool the model will call at top-1 61-89% across five 4B-14B models. Even base models already carry the right tool internally before they can emit it: reading the chosen tool off the model's internal state (cosine readout) recovers 61-82% accuracy on BFCL while base generation lands at 2-10%, suggesting pretraining forms the representation and instruction tuning later wires it to the output. Our results cover single-turn, fixed-menu settings; on multi-turn agent loops the same intervention is less stable (matched-baseline gain or loss of up to 30 percentage points with no consistent direction).
Zekun Wu, Ze Wang, Seonglae Cho +4
University College London · Holistic AI · Imperial College London