Function Calling
Advanced 13 min read Function Calling

Multi-Call Loops

Chaining actions until done

Real work needs sequences of tool calls: look up, decide, write, verify. Multi-call loops chain results through turns with caps, budgets and explicit stop conditions so autonomy stays bounded.

multi-callloopcapbudgetstop conditionagent loop
Prerequisites: Tool Dispatch
Before we start

What you will learn

  • Model multi-turn tool loop logic
  • Enforce call caps and token budgets
  • Define explicit success/stop conditions
Introduction

What is this?

A multi-call loop runs repeated rounds of model→tool→model until explicit success or a stop condition. The loop must carry accumulated context, enforce hard caps (max calls, budget), detect stalling (repeated same call), and decide done-vs-failed honestly.

Motivation

Why do you need it?

  • Single calls rarely answer compound tasks.
  • Caps and budgets convert open-ended autonomy into a bounded project.
  • Loop telemetry (calls, and outcomes) is the input to evals and alerts.
  • Explicit stop conditions prevent infinite regress and hidden drift.
Think about it

Mental model

Imagine

A project manager's task board

Think of

Multi-call loop

The PM plans (model), delegates each task (tool call), reviews results (tool messages) and re-plans — but the day has a budget and a deadline. If a task spins or repeats, the PM calls it and moves on. The loop is that bounded day, on repeat.

Mechanics

How it works

  • Start turn with the task + tool list.
  • If model emits tool_calls, execute them (via dispatch).
  • Append results, ask model to continue or conclude.
  • Track caps (max calls, token/time budget) at each iteration.
  • Stop on: explicit completion text, cap, stall, or error trigger.

Bounded loop.

Start
Model
Execute
Check
Conclude
Abort
Real world

In production

  • Research tasks chain search tools into synthesized answers.
  • Troubleshooting flows run diagnostics then apply fixes with confirmation.
  • Automation 'one button, many steps' products run loops with admin sliders.
Guidelines

Best practices

  • Always cap loops (calls AND tokens).
  • Detect stalls: same tool+args n times → change strategy or stop.
  • Return partial state + reasons on abort.
  • Log every turn — the loop is a state machine, transient.
Watch out

Common mistakes

  • No cap — cost and latency balloon.
  • Ignoring repeated identical calls (spinning).
  • Discarding intermediate results the final answer needs.
Root cause analysis

Common issues

Error
Loop exceeds budget
Root cause

Cap set too high/absent

Fix

Lower max calls; enforce token budget per turn.

Error
Spins on same tool
Root cause

Result unused or tool underpowered

Fix

Feed errors into next call; escalate or stop after N repeats.

When things break

Debugging tips

  • Long loops → put caps early; guide model to fewer calls.
  • Repeated call = confused → tighten descriptions or split tools.
  • Wrong final answer despite good calls → check whether last turn included all results.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

The minimum guarantees a loop needs:

2

Repeated identical tool calls mean healthy progress.

Go deeper

Official documentation

Multi-step tool use (Anthropic)
docs