Tool Use in Agentic Systems

When people first evaluate an AI agent, they often read its answer and ask whether it sounds good. An agent's plan can be detailed, confident, and well organized, and still fail the person who asked for it. Evaluating planning ability means checking three things: whether the plan actually accomplishes the task, whether it respects the limits the task sets, and whether it uses its tools correctly. This article builds that checklist one piece at a time, and it follows a plan through the agent's run to show where each kind of failure can enter.

A simplified way to picture an agent's run is as a sequence of stages. The agent starts with a task and a tool inventory, which is the set of tools it is allowed to use for that task. It then generates a plan. The plan leads to tool calls, each tool call returns an output, and the agent eventually reflects on whether the work is complete. Each stage can go wrong, and the failures do not all look alike. The diagram below marks where each failure type enters the run. Follow the arrows and notice that the failures branch off at different points and have different consequences for what happens next.

Read the diagram as a map of entry points. A constraint violation enters at the plan itself, because the plan can be sound in its destination and still break a budget or a deadline. A missing tool enters at the tool call stage, because the agent has no tool to call for a step the task requires. A wrong tool output enters after a tool runs, when the tool returns an incorrect result. A reflection error enters at the end, when the agent wrongly concludes that it has succeeded. Goal failure appears when the outcome misses the goal, and it can be discovered only by checking the final result against what was asked.

The counting example shows why the diagram ends with a reflection step. The agent's claim of success is itself an output, and it can be wrong. The count of 12 for a list of 10 is a checkable fact, so a checker can catch it. Because the error sits in the agent's self-assessment, the rest of the run has already been treated as finished. Any downstream steps that rely on the false claim will carry the error forward.

The source groups planning failures into three modes. Planning failures can occur because of goal failure or because of a constraint violation, and a third mode, which is easy to miss, comes from errors in the agent's reflection on its own work. The comparison below summarizes what each mode breaks. The distinctions matter because each mode is checked in a different way, and a single pass or fail label would hide which one happened.

Each mode is easy to confuse with the others if you only look at the final text. The subsections below explain each one with a concrete case.

A tool failure happens when the agent picks the correct tool but the tool's output is wrong. The source gives two examples. An image captioner may return a wrong description, or an SQL query generator may return an incorrect query. A second source of trouble appears when the agent produces only high-level plans and a separate translation module converts each planned action into executable commands. In that setup, the translation step can introduce errors even when the plan itself is sound.

A missing tool failure is the second route to trouble. The source gives a clear case: a task that requires retrieving current stock prices from the internet fails if the agent has no internet access. Missing tool failures are harder to notice than wrong outputs, because nothing is returned at all. Detecting them requires knowing which tools a task should use.

When a tool call returns an error, the diagnostic question is whether the fault lies in the tool execution or in the plan that chose the tool. The source's advice is to test each tool on its own, so that a bad result can be traced. Testing a tool only inside the full agent run makes it hard to tell whether a bad result came from the tool or from the planning. If the pipeline includes a translator, build benchmarks that evaluate the translator separately.

Spotting failures by reading a handful of outputs is unreliable. A more systematic method is to build a planning dataset in which each example is a tuple made of a task and a tool inventory. For each task, you ask the agent to generate K plans, and then you compute measurements across all of those plans and tool calls. The diagram shows how the pieces relate, and where the failure labels attach.

The structure separates problems that a single pass or fail label would blur together. An invalid tool, a valid tool with bad parameters, and a valid tool with wrong parameter values are three different failures, and each points to a different fix. Because each plan is a separate sample, the dataset also shows how often the same task fails across different attempts, which a single run cannot reveal. The source lists the measurements this makes possible: plan validity, tool-call validity, and parameter errors.

An agent's plan may be valid and use the right tools, yet still be wasteful. Efficiency is a separate question from correctness. The source suggests tracking three quantities: the average number of steps the agent needs to complete a task, the average cost of completing a task, and the time each action takes. Looking at the time per action helps reveal whether a few particular actions dominate the total.

Raw numbers only mean something against a baseline. The baseline might be another agent or a human operator. A human and an AI work in very different ways, so a result that looks inefficient for a person can be sensible for a machine, and the reverse can also be true. Visiting 100 web pages would be a heavy burden for a human who can open only one page at a time, yet it is trivial for an AI agent that can process many pages at once. Compare like with like, and judge efficiency by what each kind of worker can actually do.

Many of the failures above depend on what the agent is able to keep track of while it works. The source ties this to memory, which it defines as mechanisms that allow a model to retain and utilize information. An agentic system needs memory to store many kinds of material. The source links this to evaluation: because agents keep plans, tool inventories, and tool outputs in memory, a failure in one of those stored items can carry forward into later steps. A wrong tool output that is stored and reused can therefore affect several later decisions, not only the one step where it appeared.