PaperlayerView exact revision on arXiv

Source-linked AI summary

Looped Language Models Improve Compositional Tool Calling

Andrei Cristian Popescu, Haitz Sáez de Ocáriz Borde, Pietro Liò

arXiv:2608.18171v1cs.AIcs.LG

TL;DR

Compositional tool use requires models to coordinate calls, preserve intermediate state, and track dependencies, but looped models’ benefits for agentic tool use remain underexplored. This paper evaluates native and retrofitted looped models across tool-use benchmarks and finds the largest gains on multi-call and dependency-aware tasks, with adaptive inference improving the compute-performance trade-off.

  • Problem

    Evidence for looped language models in agentic, compositional tool use remains limited despite the need to coordinate calls, preserve state, and maintain dependencies.

  • Method

    The paper evaluates native and retrofitted looped models against non-looped models across API-Bank, BFCL, and NESTful while varying recurrent depth at inference.

  • Results

    Looped computation provides its largest benefits on multi-call and dependency-aware tasks, with accuracy generally increasing by recurrent depth and adaptive inference offering a better compute-performance trade-off.

  • Takeaways & Limitations

    Looped language models are promising for agentic systems requiring reliable planning, coordination, and execution of compositional tool-use workflows.

  • Takeaways & Limitations

    The evaluation uses static, single-turn benchmarks, and identical-pretraining non-looped counterparts are unavailable for the Ouro models.

Abstract

from arXiv · show

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.

1 Introduction

This paper studies whether looped language models improve compositional tool use, where agents must coordinate multiple calls and preserve intermediate structure. Across controlled evaluations, recurrent computation helps most on multi-call and dependency-aware tasks, with adaptive inference improving the compute-performance trade-off.

  • Motivation: Complex agentic tasks require composing multiple tool calls, maintaining intermediate state, and preserving dependencies across interactions.Tool use provides a controlled setting for studying how pretrained representations translate into structured actions.
  • Motivation: Looped language models repeatedly refine latent representations before generating each token, increasing test-time computation without increasing parameter count.Their benefits for agentic behavior remain underexplored despite promising reasoning-benchmark results.
  • Contributions: The study evaluates native and retrofitted looped models on API-Bank, BFCL, and NESTful using matched fine-tuning comparisons.The retrofits use shared Llama and OLMo backbones.
  • Findings: The largest benefits appear on multi-call and dependency-aware tasks, where recurrent computation helps preserve structure across multiple decisions.Increasing recurrent depth generally improves compositional tool use, while adaptive inference allocates fewer iterations when additional refinement is unnecessary.

2 Related Work

This section situates the study at the intersection of recurrent-depth architectures for latent computation and planning and composition in tool-using language models. It distinguishes latent iterative computation in looped Transformers from approaches that enhance tool use through external planning, retrieval, or execution strategies.

  • Research Scope: Related work centers on recurrent-depth architectures for latent computation and methods for planning and composition in tool-using language models.These are the two lines of work most closely related to the study.
  • Recurrent Depth and Latent Computation: Looped Transformers repeatedly apply a shared Transformer block, increasing effective model depth while decoupling test-time computation from parameter count.Earlier recurrent or parameter-sharing architectures include the Universal Transformer, Deep Equilibrium Models, and ALBERT.
  • Planning and Composition in Tool-Using Models: Tool-augmented language models invoke external functions for retrieval, computation, and software-environment interaction, with prior work combining reasoning and tool execution.Related approaches also include learning API usage from self-supervised annotations.
  • Planning and Composition in Tool-Using Models: This study examines whether additional latent iterative computation in looped Transformers benefits compositional tool calling, unlike approaches centered on external planning, retrieval, or execution strategies.API-Bank, BFCL, and NESTful evaluate capabilities from single-function invocation through parallel, sequential, and nested API compositions.

3 Background

This section introduces looped Transformers as recurrently repeated shared blocks and formalizes compositional tool use as structured prediction over tool calls and dependencies. It also describes adaptive computation and tool-call execution with observations incorporated into later steps.

  • Compositional Tool Use Formalism: Compositional tool use is modeled as structured prediction over available tools, selected functions, instantiated arguments, and tool-call dependencies.Each tool has a function name, natural-language description, and argument schema; the model predicts pθ(c_k | x) for structured calls c_k = (f_k, a_k).
  • Looped Transformers: Looped Transformers repeatedly apply a shared Transformer block across recurrent iterations, refining latent representations while increasing inference-time computation without increasing parameter count.The shared block updates the hidden state at each iteration, and a shared output head produces predictions after every iteration.
  • Looped Transformers: Adaptive computation lets looped Transformers dynamically select an exit iteration, allowing easier predictions to terminate after fewer recurrent iterations.Exit selection can use a learned halting policy or post-hoc criteria.
  • Compositional Tool Use Formalism: Executing a structured tool call returns an observation that may be incorporated into subsequent model steps.This provides the intermediate state needed to coordinate dependent tool interactions.

4 Experimental Setup

The experiments compare looped and non-looped models under matched supervised fine-tuning, using benchmarks that span isolated, compositional, and hierarchical tool use. They also test fixed-depth and adaptive recurrent inference to measure the effects of additional computation during tool use.

  • Models and comparisons: Controlled comparisons fine-tune looped and non-looped models with the same dataset and optimization settings, alongside stronger public instruction-tuned reference checkpoints.The looped models include Ouro-1.4B and Ouro-2.6B; standard Transformer baselines come from the Qwen3 and Llama families at similar parameter scales.
  • Supervised fine-tuning: All controlled models are supervised fine-tuned on Hermes function calling data formatted with ChatML and the Hermes JSON tool-calling protocol.Training uses a maximum sequence length of 4,096 tokens, a 90/10 train-validation split, two epochs, AdamW, learning rate 2 × 10−5, cosine decay, 3% warmup, and gradient accumulation of 2.
  • Evaluation benchmarks: BFCL v3, NESTful, and API-Bank measure complementary aspects of tool use, including isolated invocation, compositional multi-tool reasoning, and hierarchical execution.BFCL v3 reports AST accuracy by task category, NESTful emphasizes dependent nested workflows and reports Win Rate plus execution scores, while API-Bank emphasizes API grounding and invocation accuracy.
  • Fixed-depth inference: Fixed-depth inference varies recurrent iterations while keeping model parameters fixed, evaluating depths 1–4 for Ouro and 1, 2, 4, and 8 for retrofitted recurrent Llama-3.2-1B and OLMo-2-1B.These experiments use the BFCL v3 evaluation split and a fixed 500-example NESTful subset sampled evenly across the benchmark’s official ordering.
  • Adaptive inference: Adaptive inference uses Ouro’s pretrained exit gate, stopping each token when cumulative exit probability exceeds threshold q and reporting performance with average selected loop depth.The evaluated thresholds are q ∈{0.1, 0.3, 0.5, 0.7, 0.8}.

5 Results

Looped language models outperform matched non-looped baselines on compositional tool-calling tasks, with smaller and model-dependent gains for isolated API invocation. Increasing recurrent depth generally improves multi-step tool use, while adaptive inference achieves a better compute–performance trade-off by allocating computation selectively.

  • Looped models improve tool use: Matched looped models outperform non-looped baselines on compositional tool-calling tasks, while gains on isolated API invocation are smaller and model-dependent.Comparisons use identical datasets, optimization schedules, and LoRA configurations across looped and non-looped models.
  • Looped models improve tool use: BFCL and NESTful show larger improvements on compositional, parallel, and hierarchical workflows than on simpler or isolated API tasks.BFCL gains are particularly apparent on Parallel and Parallel-Multiple categories, while NESTful improves on full and hierarchical evaluations.
  • Depth ablations: BFCL accuracy generally rises as recurrent depth increases, separating benefits of inference-time recurrence from training differences.The depth ablation varies inference loop iterations while keeping the model fixed.
  • Depth ablations: NESTful Win Rate increases with recurrent iterations, indicating that recurrence benefits tool interactions whose later calls depend on earlier outputs.The effect persists across Ouro models and the retrofitted Llama model when only inference depth changes.
  • Adaptive computation: Adaptive inference recovers most gains from deeper recurrence with fewer loop iterations per generated token, improving the performance–compute trade-off.Adaptive stopping can match or exceed the best fixed-depth configuration at lower average cost by allocating computation according to token difficulty.
  • Iterative refinement: Iterative refinement can correct invalid calls and dependency references, recovering a complete multi-step tool sequence by recurrent depth 3 in a representative NESTful example.At greater depth, the prediction remains unchanged after the correct sequence and output-to-input dependency are recovered.

6 Conclusion

The evaluation finds looped computation especially valuable for compositional, dependency-aware, and coordinated tool calling, with native and retrofitted looped models generally outperforming comparable non-looped baselines on structured tool-use tasks.

  • Looped computation is particularly beneficial when tool calling requires composition, dependency tracking, or coordination across multiple calls.
  • On BFCL and NESTful, native Ouro and retrofitted Llama and OLMo models generally outperform comparable non-looped baselines on structured tool-use tasks.
  • Post-hoc recurrence improves several compositional tasks, but retrofitted models remain substantially weaker than natively recurrent models.

7 Limitations · A Looped Models Architectural Details · A.1 Ouro

The study uses controlled comparisons while documenting native and retrofitted looped-model architectures. Ouro applies shared Transformer blocks recurrently, combines fixed-depth and adaptive inference, and trains its halting policy in two stages.

  • 7 Limitations: The conclusions come from a deliberately controlled setting, with matched comparison for Ouro approximated using Qwen3 and Llama under the same fine-tuning recipe.No non-looped Ouro counterpart trained under identical pretraining conditions is publicly available; retrofit experiments share backbones with non-recurrent parents.
  • A Looped Models Architectural Details: The evaluated looped models comprise native recurrent Ouro models and retrofitted recurrent models, emphasizing architectural and training differences relevant to evaluation.The architectural appendix first describes native Ouro models and then retrofitted models.
  • A.1 Ouro: Ouro repeatedly applies a shared stack of L decoder-only Transformer layers for iterative latent computation, rather than stacking independently parameterized layers.Its recurrent blocks use multi-head self-attention, RoPE, SwiGLU feed-forward networks, and sandwich RMSNorm, with up to Tmax = 4 recurrent iterations.
  • A.1 Ouro: At each recurrent iteration, Ouro predicts the next-token distribution and a conditional halting probability, inducing an exit distribution over recurrent depths.The remaining probability mass is assigned to the final recurrent iteration, and the exit distribution weights training losses and determines adaptive inference depth.
  • A.1 Ouro: Ouro training proceeds in two stages, beginning with joint optimization of the language model and halting gate.Entropy regularization acts as a KL penalty toward a uniform prior over exit depths, encouraging use of multiple recurrent iterations before halting specialization.
  • A.1 Ouro: Stage II freezes the language-model backbone and optimizes the halting gate from the marginal utility of one additional recurrent iteration.This stage improves adaptive exit-policy calibration while leaving pretrained recurrent representations unchanged.
  • A.1 Ouro: Experiments use released Ouro-1.4B and Ouro-2.6B checkpoints with either predetermined fixed-depth inference or adaptive inference through the pretrained halting gate.Fixed-depth inference executes the selected number of recurrent iterations for every token.

A.2 Retrofitted Recurrent Models

Retrofitted recurrent models convert pretrained decoder-only Transformers into looped models by inserting a shared recurrent block between non-recurrent components. They preserve pretrained behavior while using sampled training depths and fixed-depth inference without learned halting.

  • Architecture: The retrofit partitions a pretrained Transformer into a non-recurrent prelude, shared recurrent block, and non-recurrent coda.Repeated latent refinement increases inference-time computation while largely preserving pretrained parameters and capabilities.
  • Training and inference: Training samples recurrent depth independently per batch from a Poisson-lognormal distribution, rather than learning an adaptive halting policy.The depth is defined by λ ∼LogNormal(µ, σ2) and r ∼Poisson(λ), with µ and σ controlling expected recurrence depth.
  • Training and inference: KL regularization preserves the frozen pretrained model’s behavior while adapting it to recurrent computation.The model is supervised after the sampled iterations, and its language-model loss uses only the final recurrent prediction.
  • Training and inference: Released checkpoints are initialized from OLMo-2-0425-1B and Llama-3.2-1B and evaluated by varying fixed recurrent depth during generation.Because these models lack learned halting, inference executes a fixed number of recurrent iterations.

B Hermes Function-Calling Dataset

All supervised fine-tuning experiments use the Hermes Function-Calling V1 dataset, a synthetic corpus for structured function calls and JSON outputs that combines single- and multi-function conversations with structured extraction and JSON-mode tasks.

  • Dataset design: Hermes Function-Calling V1 is a synthetic instruction-following corpus designed to train language models on structured function calls and JSON outputs from natural-language requests.The dataset was introduced by Nous Research and combines single-function and multi-function tool-calling conversations with structured extraction and JSON-mode tasks.
  • Training data: All supervised fine-tuning experiments in the work use the Hermes Function-Calling V1 dataset.

C Additional Qualitative Examples

Qualitative NESTful examples show recurrent refinement correcting malformed outputs, unsupported functions, argument grounding, call ordering, and missing dependency references. These examples illustrate observable prediction changes rather than claiming representativeness of the full evaluation set.

  • Cross-example observations: Across the examples, added recurrent depth changes named functions, arguments, emitted call counts, ordering, and intermediate-output references, without establishing the full-set error distribution.The examples use fixed-depth inference on NESTful instances and report only observable differences from the gold sequence.
  • Ordering and spurious-call correction: Recurrent refinement converts malformed or semantically incorrect sequences into the gold execution trace by correcting ordering errors and unsupported tool invocations.In Figure 6, depth 1 is malformed; depth 2 reverses the gold functions, calls absent function multiply, and uses an invalid variable reference, while depths 3 and 4 match gold.
  • Argument correction: Argument correction can preserve function selection while fixing argument grounding and restoring an omitted dependent call.Figure 7 shows correct first-function selection at depth 1, but input_str is borrowed from another tool, duplicated as input_str_2, and the dependent call is omitted; depths 2–4 match gold.
  • Two incorrect attempts before recovery: Some examples show two distinct incorrect attempts before recovery, with absent functions and omitted dependent calls corrected at later depths.In Figure 8, depths 1 and 2 select functions absent from the catalogue and emit only one call; depths 3 and 4 select both gold functions and pass $var1.output_0.
  • Dependency recovery: Dependency recovery can occur without changing function selection: the first gold call remains fixed while a later depth adds the dependent call and $var1.output_0 reference.Figure 9 shows depth 1 producing no parsed call, depth 2 matching the first gold call, and depths 3 and 4 adding the dependent call.

D Tool-Calling Benchmark Examples

This section presents representative tool-calling benchmark examples and connects their task structures to the formalism Gx = (Cx, Ex). The benchmarks emphasize complementary aspects of tool use, including grounding individual calls.

  • Task Structure: Tool-use solutions are represented as Gx = (Cx, Ex), where Cx contains required function calls and Ex captures output-to-input dependencies.This formalism separates the calls required to complete a task from dependencies between their inputs and outputs.
  • Task Structure: The benchmark examples illustrate how evaluated tasks instantiate the formal tool-use structure introduced in Section 3.The section relates representative benchmark tasks to the formalism used throughout the paper.
  • Benchmark Focus: API-Bank emphasizes grounding individual function calls, complementing benchmarks that assess other aspects of tool-use structure.The passage characterizes the benchmarks as evaluating complementary aspects of tool use.

D.1 Berkeley Function Calling Leaderboard · D.2 NESTful · D.3 API-Bank

The evaluated benchmarks span independent function selection and multi-call generation in BFCL, dependency-aware API workflows in NESTful, and conversational grounding of individual API calls in API-Bank. Together, they distinguish call selection and argument generation from constructing independent call sets and binding outputs across dependent calls.

  • D.1 Berkeley Function Calling Leaderboard: BFCL evaluates non-live single-turn tool calling across Simple, Multiple, Parallel, and Parallel-Multiple categories.These categories vary in the number of candidate tools and required calls.
  • D.1 Berkeley Function Calling Leaderboard: BFCL examples have independent calls with Ex = ∅, while category complexity is determined mainly by |Tx| and |Cx|.Simple uses |Tx| = 1 and |Cx| = 1; Multiple increases candidate tools without increasing required calls, whereas Parallel and Parallel-Multiple require multiple calls.
  • D.1 Berkeley Function Calling Leaderboard: Parallel-Multiple jointly tests function selection, call-set construction, and argument assignment across different tools.It combines |Tx| > 1 with |Cx| > 1 while retaining Ex = ∅.
  • D.2 NESTful: NESTful evaluates executable API-call sequences in which one function’s output is passed as an argument to a subsequent function.Its released evaluation set contains 1861 instances from mathematical reasoning and coding domains.
  • D.2 NESTful: NESTful represents solutions as Gx = (Cx, Ex), with dependencies forming generally directed acyclic graphs rather than collections of independent calls.The model must construct calls and explicitly assign outputs, select output fields, and bind variables to later arguments.
  • D.2 NESTful: In the illustrated NESTful workflow, c1 and c2 execute independently, c3 consumes both outputs, and c4 consumes c3’s output, producing the gold answer 20.The dependency edges are (c1, c3), (c2, c3), and (c3, c4).
  • D.3 API-Bank: API-Bank evaluates conversational grounding of individual tool calls, with |Cx| = 1 and Ex = ∅ for each example.The task is to select the correct API, instantiate its arguments, integrate the returned observation, and generate the final response.
  • D.3 API-Bank: An API-Bank calculator example requires translating “(5 + 6) × 3” into Calculator(formula = ’(5+6)*3’) and producing a correctly formatted invocation.The instance tests API identification, argument representation, and invocation formatting within a conversational context.
Loading 2608.18171v1…