A paper posted to arXiv on 20 August by University of Cambridge researchers finds that looped language models (models that recycle their own computation layers before answering) improve at multi-step tool calling, where one API request depends on the result of another S¹. The gains grow with recurrent depth, but only for tasks that chain tools together; isolated single calls barely benefit. If agents that think longer also plan better, it changes how we should build them. If they just burn compute, it doesn't.

My read: This is the first study I've seen that systematically tests whether recurrent computation helps with agentic tool use rather than just reasoning puzzles. I don't buy the clean narrative yet, because the abstract hedges every claim ("generally benefits," "generally increases," "suggest") and the authors are evaluating their own proposed architecture. But the direction is plausible: compositional tool calling is a planning problem, and planning is where extra compute should help most.

Why looping helps where single-pass models stall

A standard language model runs its neural layers once and produces output. A looped model reuses the same layers multiple times, what researchers call recurrent depth, refining its internal state before it answers S¹. Think of it as a model that can re-read its own draft before committing.

For simple tasks, one pass is enough. The problem is compositional tool calling: an agent that needs to call an API, read the result, decide what to call next, and repeat. Each step depends on the last. Language models already struggle with nested rules and compositional reasoning, they overgeneralise and break when tasks stack. Tool calling multiplies that problem, because a wrong step early in the chain poisons everything downstream.

The Cambridge team, Andrei Cristian Popescu, Haitz Sáez de Ocáriz Borde, and Pietro Liò, evaluated both native looped models and retrofitted ones (standard models adapted to loop) on three benchmarks: API-Bank, a tool-augmented LLM benchmark from EMNLP 2023 P⁴; BFCL; and NESTful S¹. They compared looped and non-looped models trained under matched supervised fine-tuning recipes, then varied recurrent depth at inference time S¹.

Where the gains are, and where they aren't

The findings split along a clear line. Recurrent computation generally benefits compositional and dependency-aware tool use, the multi-step chains where planning matters S¹. Accuracy on multi-step tool use generally increases with recurrent depth S¹.

But isolated API invocation, calling a single tool with no dependencies, shows smaller and more model-dependent gains S¹. This makes sense: if there is nothing to plan, extra thinking cycles have less to work with.

The most practical finding concerns adaptive inference. Instead of running a fixed number of loops for every request, the model allocates extra computation only when it needs it, for complex chains, not simple calls. The authors report this achieves a more favorable compute-performance trade-off S¹. In a field where inference cost, the cost of actually running the model, is the dominant expense for agent deployments, spending compute only where it matters is the difference between a system that scales and one that drains your budget.

What to do about it

Consider a freight-forwarding company building an AI agent to handle shipment bookings. The agent needs to check a vessel schedule API, calculate customs duties based on the destination country, verify the result against a compliance database, then book a slot. Each step feeds the next. A single-pass model might nail the first call but garble the chain by step three. A looped model that runs more cycles on the complex booking workflow, and fewer on the simple schedule check, could handle both without overspending on the easy parts.

For teams building agent systems today, the practical signal is this: if your agents struggle with multi-step tool chains rather than single API calls, recurrent computation is a direction worth tracking. The paper is not a product release or a model you can download. It is a preprint finding that the architecture itself changes the equation for compositional tool use, without requiring more parameters or better training data.

One thing to check this week: pull your agent's failure logs and sort by number of tool calls in the workflow. If errors cluster in the longer chains, you are looking at the exact problem this paper addresses.

What we don't know yet

The paper discloses no exact accuracy figures or percentage gains in its abstract S¹. Every claim is hedged. The study has not been peer-reviewed; it is a single-source arXiv preprint, and all findings are the authors' own claims S¹. The authors are evaluating their own proposed architecture, which means performance results should be treated as preliminary until independently replicated.

The study does not directly compare looped models against commercial systems such as GPT-4 or Claude. It does not claim looped models beat non-looped models on every task; the gains on isolated API calls were smaller and inconsistent across models S¹.

A GitHub repository, DeepExperience/LoopTool, exists with 69 stars and was created in November 2025, but its relationship to this specific paper is unclear P³.

The next signal: whether the authors post a revised version with actual accuracy numbers, or whether an independent team reproduces the results on the same benchmarks. We'll check the claims against either when it appears. If you want us to catch it first, subscribe and we'll have it in your inbox the day it lands.

Sources: S1 — Looped Language Models Improve Compositional Tool Calling · P2 — Looped Language Models Improve Compositional Tool Calling · P3 — DeepExperience/LoopTool · P4 — API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs | OpenRevi · P5 — liminghao1630/API-Bank · Datasets at Hugging Face

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.