LLM Agents and Tool Use

A language model asked "what's the current price of AAPL and what would 200 shares cost including a $4.95 commission" has no live market data and, worse, may confidently hallucinate a plausible-looking price rather than admit it doesn't know. An LLM agent fixes this not by making the model smarter at arithmetic or market data, but by giving it the ability to call an actual price-lookup tool and an actual calculator, and reason about when each one is needed.

The analogy: a research assistant with a phone and a calculator, not just a memory

A research assistant who only has their memory to rely on will occasionally misremember a fact or a number. Give that same assistant a phone to call the data desk and a calculator on their belt, and the quality of their answers changes completely — not because they got smarter, but because they now reach for a verified source or a precise tool instead of relying on memory whenever the task calls for it. An LLM agent is a language model given exactly that kind of belt of tools, plus the judgment (learned through prompting or fine-tuning) about when to reach for which one.

The loop, piece by piece

An agent typically runs a repeating cycle, often called ReAct (reason plus act):

1. Reason. The model is prompted to think about what the current sub-goal requires — "I need the current stock price before I can compute the total cost."
2. Act. The model outputs a structured call to one of a fixed set of available tools — e.g., get_price(ticker="AAPL") — rather than generating free text.
3. Observe. The actual tool executes outside the model (a real API call, a real database query) and returns a real result, which is inserted back into the model's context.
4. Repeat or answer. The model reasons over the new information, decides whether another tool call is needed, and eventually produces a final answer grounded in the tool outputs it collected.

In plain English: the model's job shrinks from "know everything and compute everything internally" to "correctly decide which real tool to call, in what order, and correctly combine their real outputs" — a much narrower and more verifiable responsibility.

Worked example: a two-step tool-use trace

Question: "What would 200 shares of AAPL cost right now, including a $4.95 commission?" Step 1 (reason): the model determines it needs the current price. Step 2 (act): it calls get_price(ticker="AAPL"). Step 3 (observe): the tool returns $227.50. Step 4 (reason): the model determines it now needs to compute $200 \times 227.50 + 4.95$. Step 5 (act): it calls calculator(expression="200*227.50+4.95"). Step 6 (observe): the tool returns 45,504.95. Step 7 (final answer): "200 shares at $227.50 would cost $45,504.95 including the $4.95 commission." Every number in the final answer traces to a real tool call, not the model's internal guess.

Worked example: catching a tool-use failure

Suppose the price tool is temporarily unavailable and returns an error instead of a price. A well-built agent is prompted to check the tool's response for an error before proceeding, and to report "I couldn't retrieve a current price for AAPL" rather than silently substituting a remembered or guessed number and presenting it as live data — the difference between an agent that fails visibly and one that fails silently and confidently.

What this means in practice

Tool use is what makes LLMs practically usable for tasks requiring current, precise, or verifiable data — pricing, calculations, database lookups — rather than confined to tasks where a fluent, roughly-right answer from memory is acceptable. The new risk it introduces is that a poorly constrained agent might call a tool with the wrong arguments, misinterpret a tool's output, or call a tool with real-world side effects (like placing an order) based on a reasoning error — so production agent systems need explicit guardrails on which tools can be called, with what permissions, and under what human review, not just a bigger toolbox.