What is tool use (function calling) in LLMs, and how does it enable agents?

In this question, we will learn what tool use or function calling means for LLMs and why it matters for building agents that perform tasks. We will keep the focus practical, with one concrete example so you can explain it in an interview.

We will cover the following:

• The direct answer
• The intuition
• How it actually works with a worked example
• Design patterns for agents and tools
• Tradeoffs and failure modes

Direct answer: Tool use is the pattern where an LLM is prompted with function schemas and emits structured function calls that a runtime executes, enabling agents to access external capabilities like search, computation, and actions. This lets models delegate precise, auditable work to tools and then reason about the returned observations. The model still guides behavior, but the heavy lifting is done by reliable services mapped via clear schemas.

The intuition (an analogy that makes it click)

Think of the LLM as a well spoken assistant who knows what you want but cannot fetch a live price or run a calculator. Function calling gives the assistant a phonebook of services and the exact form of the phone number to dial. The assistant writes a structured request, the runtime dials the number, and then reads back the answer. You keep the human level planning and the tools do the concrete facts and side effects.

How it actually works (the real mechanics, with one concrete worked example)

At runtime you provide the model with a prompt and a list of function signatures or JSON schemas. The model returns either plain text or a structure like { "name": "get_stock_price", "arguments": {"symbol": "TSLA"} }. The system matches by name, calls the corresponding function, and appends the result to the model context so it can continue reasoning.

Worked example: build a small agent that answers "What is TSLA latest price and the 10 day moving average?"

1. Register two functions: get_stock_price(symbol) and get_historical_prices(symbol, days).
2. Prompt the model with behavior and the two schemas.
3. Model returns a call to get_historical_prices for 10 days. System executes and returns prices $p_1 \dots p_{10}$.
4. Model computes the moving average and returns a final message.

The moving average formula you can show is the display math:

$MA_{10} = \frac{1}{10} \sum_{i=1}^{10} p_i$

A simple data table of returned prices might look like this:

The model receives that array and applies the formula $MA_{10}$ to compute the number and then formats a user-facing answer. The schema ensures the runtime knows how to parse arguments and map the call to the correct function.

Design patterns for agents and tools

• Planner and executor: split the agent into a planning model that decides which tool to call and an executor that performs the call and returns observations. This separation keeps prompts smaller and responsibilities clear.

• Structured schema design: make function signatures narrow and explicit. For example, prefer parameters like "symbol" and "days" over a single free text blob. Narrow schemas reduce parsing errors and improve safety.

• Observe and replan loop: after a tool returns, feed the result into the model so it can revise its plan. This loop forms the core agent cycle: plan, call, observe, act.

Comparison of output types

Safety, validation, and robustness

Always validate tool inputs and outputs outside the model. Treat model outputs as instructions that need sanitizing. For example, if the model suggests calling a destructive API like delete_user, require an authorization step and strict schema checks. Use retries and timeouts for network tools and handle malformed or missing fields gracefully.

Tradeoffs and failure modes

Tool use raises new tradeoffs: you get stronger correctness for actions but you must manage schema design, error handling, and increased system complexity. Latency also grows because each function call may add round trips.

Questions the interviewer might ask

Some follow-up questions you might get:

How do you prevent a model from calling harmful APIs? Design the runtime to whitelist functions per session and to validate arguments. Also separate high risk functions behind additional human or authorization checks.

What happens when the model returns malformed JSON or wrong argument types? Your runtime should detect parsing errors and return a structured error object to the model so it can retry or choose a different plan. Do not execute anything that fails schema validation.

When should you prefer a single monolithic tool versus many small tools? Many small tools are easier to secure and test. Monolithic tools can reduce round trips but increase blast radius. Prefer small focused APIs when safety and auditability matter.

How do you keep the agent from overusing tools and incurring cost? Add budget constraints in the planner prompt and track call counts. Implement caching and require the model to check cache first for repeated queries.

Can you compose tools, for example chain search then database update? Yes. The agent can call tool A, observe the result, then call tool B using data from A. Keep each step explicit in the context so the model can reason about preconditions and effects.

Some things to note:

• Instrument everything: logs are essential for debugging and safety.
• Keep schemas narrow and versioned so you can evolve tools without breaking agents.

What the interviewer is really testing

They want to know you understand the separation between language reasoning and external execution, and that you can design a reliable, auditable integration. They also want to hear about practical safety checks, schema design, and failure handling rather than a purely conceptual description.