AI Agents

How do you get reliable tool use across multi-step tasks?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 11 min read

How do you get reliable tool use across multi-step tasks? Measure whole-chain success over repeated runs, give the model fewer choices, return errors as data it can retry on, and fix the path in code. A model that gets each call right nine times in ten still fails about two in three ten-step chains; the first step below shows the arithmetic.

In this article

Before you start
Why interviewers ask this
Reliable tool use from first principles
The Staff-level answer
The rubric
Three variants of this question
Common mistakes
Follow-up questions
Sources

Before you start

This page belongs to the AI agents learning path. It assumes you know what a prompt is; if not, read prompt engineering first.

Why interviewers ask this

The question separates candidates who have watched an agent demo from candidates who have run one for a week. A demo succeeds once. A product has to succeed on the next hundred runs, with the order of steps changing each time.

A weak answer says "use function calling with a strict schema" and stops. A strong answer says that a schema fixes the shape of arguments but not the choice of tool or the order of steps, then names what does: fewer and clearer tools, validation, errors the model can read, and limits on the loop. A Staff-level answer starts with arithmetic. It shows why per-step accuracy is the wrong number and says how the team would measure the right one. This topic is reported in interviews at AI labs and large tech companies, and it sits next to the agentic AI interview questions.

Reliable tool use from first principles

Tool call: A tool call is a structured request, usually a tool name plus arguments in JSON, that a large language model (LLM) emits so that ordinary code runs a function and returns the result to the model as its next input.
Idempotent tool: An idempotent tool is a tool whose repeated call with the same arguments leaves the world in the same state as one call, so a retry after a failure cannot double its effect. Setting an order's status to shipped is idempotent; adding one item to an order is not.

In plain words

Picture a new assistant who follows a checklist across ten desks. At each desk they can pick the wrong form. They can fill it in wrongly. They can hit a locked drawer. So you check their work over many days. You give them few, clearly labelled forms. You tell them exactly what went wrong at a locked drawer. You print the route on paper where it never changes. The analogy breaks in one place. The assistant remembers yesterday. A model starts each run from the text in its context window.

Reliable multi-step tool use means a chain of tool calls reaches the right end state on nearly every repeated run. You get it two ways: lower each step's failure rate, and remove decisions the model should not make.

Step 1: Measure the whole chain over repeated runs

Reliability is a property of the whole task, measured over many runs. If each step succeeds with probability p and the steps are independent, a chain of n steps succeeds with probability p to the power n. With p of 0.95 (illustrative), a ten-step chain succeeds 0.5987 of the time, and with p of 0.99 it succeeds 0.9044 of the time; at 0.9 per step it succeeds only 0.3487 of the time.¹ A model that is right nine times in ten per step therefore fails about 0.6513 of ten-step tasks.¹ The formula ignores two real effects: recovery mid-chain and correlated failures. Chains can do better when errors are caught and retried, and worse when failures cluster.

Reliability falls with chain length at every per-step rate, so the per-step rate must be much higher than the whole-task target.
Per-step success (illustrative)	5 steps	10 steps	20 steps
0.90	0.5905	0.3487	0.1216
0.95	0.7738	0.5987	0.3585
0.99	0.951	0.9044	0.8179

At 0.95 per step, ten steps succeed 0.5987 of the time and twenty steps succeed 0.3585 of the time; at 0.99 per step they succeed 0.9044 and 0.8179 of the time.¹

Whole-task success falls fast as the chain grows, even when each step looks reliable.CC BY 4.0 — source: How do you get reliable tool use across multi-step tasks?

Text description of the diagram

At 0.95 per step, ten steps succeed 0.5987 of the time and twenty steps succeed 0.3585 of the time.
At 0.99 per step they succeed 0.9044 and 0.8179 of the time.

The same logic applies to repeated runs. The pass^k idea from τ-bench is a success rate counted only when all k repeated trials of the same task succeed. If a task succeeds 0.8 of the time in one trial (illustrative), it succeeds in all four trials 0.4096 of the time and in all eight trials 0.1678 of the time, assuming independent trials.¹ One lucky demo hides that gap. You now know what to measure; the next steps lower the per-step failure rate.

Step 2: Narrow the choices the model must make

Each tool call asks the model to pick a tool and fill in arguments. Fewer, clearer choices mean fewer wrong picks. Give each tool a distinct name and a description that says when to use it and when not to, and merge tools that always run together into one. The Anthropic guide to writing tools for agents covers naming, descriptions and returning useful context, and the prompting guidance applies to tool descriptions as it does to instructions.

Constrain the arguments too. As of October 2026, the function calling guide describes schema definitions and a strict mode that holds arguments to the declared JSON schema. That removes malformed arguments. It does not make the choice of tool, or the order of tools, correct. Where a step must use one tool, the tool-choice setting of the vendor application programming interfaces (APIs) can force or limit the choice. Input: the task and the tool list. Output: one well-formed call. A shared protocol such as the Model Context Protocol standardises how tools are described, not whether the model picks the right one.

Step 3: Validate results and return errors as data

After a call, the code checks the result before the model sees it: does the response match the expected shape, is a required field empty, did the tool time out. A failure is returned to the model as a tool result marked as an error, with a plain message saying what failed and what to try. As of October 2026, the tool use documentation describes passing tool results, including errors, back into the conversation, which lets the model correct a bad argument instead of repeating it.

Retries need limits. If a step fails with probability 0.1 and a failure is detected reliably, two retries lift the step to 0.999, and ten such steps then succeed 0.9900 of the time (illustrative; real failures are not fully independent).¹ Retries are safe only for an idempotent tool, or one that carries an idempotency key. For a call that changes the world, such as sending a payment, check state before retrying. You now have a self-correcting step; the last step controls the route.

Step 4: Control the path and limit the loop

Where the order of steps is known, put it in code. A workflow with model calls at fixed points has fewer model decisions than an open loop, and each removed decision removes one chance to fail. The Anthropic essay Building effective agents separates workflows from agents and advises choosing the simplest design that works. Leave the loop open only for the part where the path depends on what the tools return, as in the reasoning-and-acting loop of Yao et al..

Then bound the loop: a maximum number of steps, a budget, checkpoints after each completed step so a failed run resumes instead of restarting, and a human confirmation before an irreversible action, as in human-in-the-loop agents. Long chains also fill the context window, which degrades behaviour; see context rot.

Reliability is built in four layers, from measuring the chain to controlling the path.CC BY 4.0 — source: How do you get reliable tool use across multi-step tasks?

Step-by-step description

Measure the whole chain over repeated runs.
Give the model fewer, clearer choices.
Check results and return errors for retry.
Fix the path in code and bound the loop.

Reliability is measured over the whole chain and repeated runs.
A schema fixes argument shape but not tool choice or order.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.