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.
Alex: Welcome to another episode of ResearchPod.
Sam: So what are we looking at today?
Alex: A paper from the University of Cambridge asking a deceptively simple question: can we make AI smarter at complex, multi-step tasks without just making it bigger?
Sam: And why is that a tension worth exploring?
Alex: Most AI language models today work in what you might call a single-pass way. You give them a question, and they generate an answer in one go — like writing an essay without ever pausing to re-read what you've written or correct a mistake. That works fine for simple questions. But when a task has multiple steps — say, booking a flight, then checking hotel availability, then confirming a calendar — a single-pass model can fail early and have no way to recover. It just keeps going, even if it's already gone wrong.
Sam: So the researchers want to give the model a chance to think things through more carefully before committing to an answer.
Alex: Exactly. And their solution is what they call a looped language model. Instead of passing information through the model's layers just once, they run the same block of layers multiple times — like reading a problem, putting it down, picking it back up, and re-reading it with fresh eyes. Each pass refines the model's internal understanding before it produces any output.
Sam: And this doesn't mean building a bigger model. You're using the same computational machinery — just running it more than once.
Alex: Right. The internal settings that define how the model behaves stay fixed. What changes is how much time the model spends thinking before it speaks. More loops means more computation, but not a more complex structure.
Sam: So how do the researchers test whether this actually helps?
Alex: They use three benchmarks designed to test tool use — things like booking APIs or search functions. One tests whether the model can call a single tool correctly. Another tests whether it can chain multiple tool calls together in the right order. The third checks whether the model can handle situations where one tool's output feeds directly into the next tool's input — tasks where getting step two right depends entirely on getting step one right.
Sam: And what do they find?
Alex: The looped approach shows consistent benefits on those more complex, chained tasks. On simpler, isolated tool calls, the gains are smaller — which makes intuitive sense. If a task doesn't require deep reasoning, extra loops don't add much.
Sam: But here's a practical problem. If the model runs eight loops for every single word it generates, that's a lot of wasted computation on easy tasks.
Alex: That's exactly what the second part of the paper addresses. The researchers introduce what they call adaptive inference. Rather than always running a fixed number of loops, the model learns to estimate — at each loop — whether another pass is still worth doing. Think of it like a student checking their work. After the first check, you might catch a big mistake. After the fifth check, you're probably not finding anything new. At some point, it's more efficient to just hand in the paper.
Sam: So the model is essentially asking itself, "Have I thought about this enough?"
Alex: That's a good way to put it. At each loop, the model calculates a probability of stopping. If it's confident, it exits early. If there's still meaningful uncertainty, it keeps going. And this decision happens separately for each word — or piece of a word — the model is generating.
Sam: So a simple word like "the" might only need one loop, while a complex parameter being passed to an API might need six or seven.
Alex: Precisely. And the paper shows that this adaptive approach matches or slightly exceeds the performance of always running the maximum number of loops — while using significantly fewer total computations on average. You get most of the benefit at a fraction of the cost.
Sam: How do you actually train a model to do this? Teaching it to loop and then decide when to stop sounds genuinely complicated.
Alex: The researchers take a careful approach. They start with a model that already knows a lot about language, and they freeze its core settings — those don't change. Then they add small adaptation layers that teach the model how to loop effectively. During training, the number of loops used for each example is chosen randomly, which prevents the model from learning to rely on any specific depth. And the model is only evaluated on its final output — not on what it produced partway through.
Sam: So it learns to produce good final answers across a range of loop counts, rather than being trained to always use the maximum.
Alex: Which is what makes the adaptive halting work cleanly in practice. The model has already learned to be useful at different depths.
Sam: What are the limitations? Where does this fall short?
Alex: The paper is candid about this. The benchmarks are static and single-turn — the model answers once, and that's it. Real-world workflows are messier. An API might return an unexpected error. A tool might go offline. A conversation might span many turns. How well the looped architecture handles that kind of live, dynamic feedback is still an open question.
Sam: So we know it reasons better in controlled conditions. Whether it recovers gracefully when things go wrong in the real world — that's the next thing to test.
Alex: That's the honest summary. The paper makes a clear case that thinking in loops rather than a single pass improves structured reasoning without requiring a larger model. The adaptive halting mechanism makes that practical by avoiding unnecessary computation. But the multi-turn, error-recovery challenge remains largely unaddressed, and that's where future work will need to go.
Sam: A meaningful step toward AI systems that can handle complex tasks more reliably — without simply scaling up.
Alex: Thanks for listening to ResearchPod.