Set The Loop, Not The Script

Give an AI two tools and ten steps, and it can plan, search, and calculate on its own — deciding which tool to call next based on what the last one returned. Give it messy context, and it chokes on it. The mechanism behind multi-step tool use is a loop, not a hand-written decision tree, and knowing how that loop actually works changes both how you build agents and how you keep them fast.

The problem with hand-coded branches

The instinct when wiring up tool use is to write the control flow yourself: call tool A, check the result, if condition X call tool B, else call tool C, and so on. This works for a fixed, known sequence of steps. It falls apart the moment the right next action depends on what a previous tool call actually returned — which is most interesting agent behavior. You end up hand-coding an ever-growing tree of if branches trying to anticipate every path, and it's still brittle against the one case you didn't anticipate.

The loop, mechanically

The actual mechanism most agent frameworks implement is simpler than the branch-tree approach, and more general: after the model generates a tool call, your code executes that tool and sends the result back to the model as part of the conversation. The model then generates again — with the tool result now in context — and either produces another tool call or plain text. This repeats until the model stops calling tools, or a maximum step count is reached, whichever comes first.

step = 0
while step < MAX_STEPS:
    response = model.generate(messages)
    if response.is_plain_text:
        return response.text          # model is done
    tool_result = run_tool(response.tool_call)
    messages.append(tool_result)      # feed it back
    step += 1
# hit MAX_STEPS — stop and handle gracefully

Nothing in this loop is task-specific. The model decides, at each turn, whether it has enough information to answer or needs another tool call — and which tool to call next. Your code's job is just to execute whatever tool the model asked for and hand the result back. A single implementation of this loop supports arbitrarily different tasks because the branching logic lives in the model's reasoning, not in your code.

Why the step cap matters

Without a maximum step count, a model that gets stuck in an unproductive pattern — repeatedly calling the same tool, or chasing a dead end — will keep going, burning tokens and latency with no guarantee of ever stopping cleanly. The step cap is a hard backstop: if the model hasn't converged on an answer within N tool calls, the loop exits and your code decides what to do. This isn't a performance optimization — it's the difference between a bounded system and one with no upper limit on cost or time.

A reasonable step cap depends on the task. A single-lookup agent might cap at 3-5 steps; a research agent chaining multiple searches and syntheses might need 15-20. Start conservative and raise the cap only when you see legitimate multi-step tasks getting cut off.

The other half: trim what you feed back

The loop's correctness depends on what goes into that tool-result message. A tool call that scrapes a full web page and feeds the entire raw HTML back to the model burns a large chunk of context on formatting noise, ads, and navigation markup the model doesn't need — and dilutes the signal it needs to decide its next step. Filtering the tool result down to what's actually relevant before returning it measurably improves how effectively the model uses that context — it's not just a token-cost optimization, it changes whether the next generation is accurate.

Concretely: extract the relevant text before returning it, summarize a long result instead of pasting it whole, and drop fields the model has no use for. Treat "what does the model need to see" as a design decision at every tool boundary, not an afterthought.

Where this pattern applies

• Multi-step research — search, read, refine the query, search again, synthesize.
• Debugging — inspect a stack trace, look up the failing function, check recent changes, propose a fix.
• Planning tasks — check constraints, query options, compare, narrow down, present a plan.

Each of these has a variable number of steps depending on the input — exactly the case where a hand-coded branch tree breaks down and a step-capped loop holds up.

Power tricks

• A missing step cap is a production incident waiting to happen. Always set one, even generously, before shipping any agent loop.
• Don't feed back everything "just in case." A trimmed, relevant tool result outperforms a complete but noisy one — bigger isn't safer here, it's usually worse.
• The step cap is a backstop, not a UX plan. Decide up front what your app does when the cap is hit — silently truncating an unfinished multi-step task is usually worse than surfacing that it didn't finish.

Resources

• The generate-execute-feed-back-repeat loop with a step limit is a standard pattern documented across modern agent/tool-calling frameworks — look for your SDK's "multi-step," "agent loop," or "max steps" documentation.