Implement tool use and function calling mechanisms that allow...

Q: In agent tool use, what is a tool , what is function calling , and how do they divide work between the LLM and ordinary software?

Tool : an external capability an agent can invoke (e.g., calculator, web search engine, database query, file operation, API call). Function calling : the mechanism by which the LLM requests a tool using a structured function name and arguments . Division of work : The LLM decides what should happen (whether an external action/info is needed and what to request). Ordinary software executes the requested operation (the actual API call, database query, file operation, etc.).

Q: What two implementation failures mean you have not implemented agent tool use, even if parts of the system exist?

Tool described but never executed : describing a tool without actually running it in the loop is not an implementation. Function executes but not exposed to the LLM : having a function that runs correctly but is not available for the LLM to request is not yet part of an agent.

Q: What is in scope vs out of scope for this learning objective on tool use and function calling?

In scope : tool interface function-call handling execution loop for external APIs, databases, and software systems engineering controls that make tool use reliable Out of scope : redesigning the LLM itself building a complete autonomous production platform

Q: For a calculator tool, what interface must be exposed to the model (function name + parameter), and what description should it have?

Function signature : calculator(expression: str) Required parameter : expression as a required string parameter. Description : expose a description such as “Evaluate a mathematical expression. Use for arithmetic.”

Q: List the key implementation steps needed to make a calculator tool usable by an LLM, from registration through the completion condition.

Define + describe the tool Define calculator(expression: str) and expose its description and required parameter. Register implementation Register the executable implementation under the name calculator . Let the model choose it Allow selection with tool_choice='auto'. Handle the call Parse the returned JSON arguments. Execute the calculator. Return + iterate Return the result as a tool message. Continue until the model returns text without another tool call.

Q: A user asks: “What is 7.3% of $148,293.57?” What tool call should the agent generate, and why is this delegated to a tool?

Tool call : calculator(expression='148293.57 * 0.073') Why use the tool : precise arithmetic is better delegated to a calculator than done in free-form text generation.

Q: Diagnose the mistake: An application provides a function description to the model but never actually runs any code when the model calls the function. What is the error, and what must be added?

Error : describing a function without implementing its execution. Fix : add the real tool execution path in the application: parse the JSON arguments, execute the registered implementation, and return the result as a tool message into the conversation.

Q: Diagnose the mistake: An application “helpfully” executes every available tool on each user message rather than letting the model decide. What is the error, and what behavior is intended instead?

Error : executing every available tool instead of allowing the model to select one. Intended behavior : allow the model to select the appropriate tool (e.g., using tool_choice='auto') and execute only the tool it calls.

Q: Diagnose the mistake: The application executes the tool but does not add the result back into the conversation. What goes wrong, and what must be done?

What goes wrong : forgetting to return the tool result to the conversation prevents the LLM from seeing the tool output it needs to produce the final response (or the next dependent tool call). What must be done : return the result as a tool message in the conversation before asking the LLM for the user-facing answer.

In agent tool use, what is a tool, what is function calling, and how do they divide work between the LLM and ordinary software?

Tool: an external capability an agent can invoke (e.g., calculator, web search engine, database query, file operation, API call).
Function calling: the mechanism by which the LLM requests a tool using a structured function name and arguments.
Division of work:
- The LLM decides what should happen (whether an external action/info is needed and what to request).
- Ordinary software executes the requested operation (the actual API call, database query, file operation, etc.).

For implementing tool use, what is the end-to-end loop “from model to external world” that must be built?

User gives a task.
The LLM decides whether external information or an external action is needed.
The LLM generates a structured function call.
The application validates and executes that call.
The result is sent back to the LLM.
The LLM either requests another tool or produces the final response.

What two implementation failures mean you have not implemented agent tool use, even if parts of the system exist?

Tool described but never executed: describing a tool without actually running it in the loop is not an implementation.
Function executes but not exposed to the LLM: having a function that runs correctly but is not available for the LLM to request is not yet part of an agent.

What is in scope vs out of scope for this learning objective on tool use and function calling?

In scope:
- tool interface
- function-call handling
- execution loop for external APIs, databases, and software systems
- engineering controls that make tool use reliable
Out of scope:
- redesigning the LLM itself
- building a complete autonomous production platform

For a calculator tool, what interface must be exposed to the model (function name + parameter), and what description should it have?

Function signature: calculator(expression: str)
Required parameter: expression as a required string parameter.
Description: expose a description such as “Evaluate a mathematical expression. Use for arithmetic.”

List the key implementation steps needed to make a calculator tool usable by an LLM, from registration through the completion condition.

Define + describe the tool
- Define calculator(expression: str) and expose its description and required parameter.
Register implementation
- Register the executable implementation under the name calculator.
Let the model choose it
- Allow selection with tool_choice="auto".
Handle the call
- Parse the returned JSON arguments.
- Execute the calculator.
Return + iterate
- Return the result as a tool message.
- Continue until the model returns text without another tool call.

A user asks: “What is 7.3% of $148,293.57?” What tool call should the agent generate, and why is this delegated to a tool?

Tool call: calculator(expression="148293.57 * 0.073")
Why use the tool: precise arithmetic is better delegated to a calculator than done in free-form text generation.

Diagnose the mistake: An application provides a function description to the model but never actually runs any code when the model calls the function. What is the error, and what must be added?

Error: describing a function without implementing its execution.
Fix: add the real tool execution path in the application: parse the JSON arguments, execute the registered implementation, and return the result as a tool message into the conversation.

Diagnose the mistake: An application “helpfully” executes every available tool on each user message rather than letting the model decide. What is the error, and what behavior is intended instead?

Error: executing every available tool instead of allowing the model to select one.
Intended behavior: allow the model to select the appropriate tool (e.g., using tool_choice="auto") and execute only the tool it calls.

Diagnose the mistake: The application executes the tool but does not add the result back into the conversation. What goes wrong, and what must be done?

What goes wrong: forgetting to return the tool result to the conversation prevents the LLM from seeing the tool output it needs to produce the final response (or the next dependent tool call).
What must be done: return the result as a tool message in the conversation before asking the LLM for the user-facing answer.

Diagnose the mistake: The system stops after the first tool call even when later calls depend on its result. What is the error, and what loop condition should be used instead?

Error: stopping after the first tool when a later call depends on its result.
Correct loop condition: continue tool execution cycles, returning each result as a tool message, until the model returns text without another tool call.

What are two safety/control mistakes related to tool calling that must be avoided regarding (1) tool-call arguments and (2) iteration count?

Arguments: trusting unvalidated arguments from the model (tool arguments must not be accepted blindly).
Iterations: allowing unlimited iterations (tool-use loops need a limit/control).

Diagnose the mistake: The application returns tool output directly to the user and does not ask the LLM to explain it. What is the error, and what should happen after tool execution?

Error: treating tool output as the final user-facing answer without asking the LLM to interpret it.
Correct behavior: after returning the tool result as a tool message, prompt/allow the LLM to interpret the result and provide the final explanation to the user.

In an agent tool-use setup, how should a current-date function be designed and used, including its parameters and the structured data returned to the model?

Model call: the model calls getcurrentdate() with no parameters.
Application execution: the application obtains the current date/time.
Return to model: the application returns structured data (not free text), e.g. {"date": "2026-03-19T14:30:00"}.
Model use: the model uses the returned structure to answer a question about “today”.

For a tool function defined as read_file(filepath), what key implementation-side safety and robustness checks are required before returning content to the model?

Directory permission check: ensure the requested path is inside an approved directory before opening it.
Error handling: if the file does not exist or permission is denied, return a structured error rather than crashing.

When implementing a database tool function like search_orders(customer_id, status), what must the schema and application do to make the call safe and usable for an LLM?

Schema clarity: the schema should state the type and meaning of every parameter (e.g., what customer_id and status represent).
Validation: the implementation validates the values before querying.
Query safety: perform a parameterized database query.
Model-oriented output: return structured records that the LLM can summarize.
Pattern match: this follows the same pattern as the calculator, but the external system is a database rather than local computation.

For an API tool function such as get_weather(city, date), what steps should the application take from receiving model arguments through returning results, including error cases?

Arguments from model: the model supplies city and date.
Validation: the application validates the arguments.
API request: send an authenticated request to the weather API.
Error handling: handle network or rate-limit errors.
Return: return the API response to the model (as tool output), after which the model may request another tool or provide the final answer.

In a multi-step software task like “Read the file data.txt and calculate the average,” how should the agent loop be structured across tool calls, and what must be preserved between iterations?

First call: call the file tool to read the file (e.g., read data.txt), and return the result to the model.
Second call: the model sends a suitable mathematical expression to the calculator tool to compute the average.

Dependency: the second function call depends on the result of the first.
State requirement: the loop must preserve the full message history so later steps have the needed context.

When asked to “implement tool use” for an agent, what two sides must you explicitly show, and what safety topics should you cover if asked about safety?

Show both sides:
- Model-facing schema (what the model is allowed to call, with parameters).
- Application-side function (what actually executes and returns tool outputs).
Safety discussion topics:
- validation
- permissions
- sandboxing
- error handling
- iteration limits

When asked to “trace the agent” across tool calls, what level of detail should the trace include?

Show each iteration of the agent loop.
Include the exact information passed back at each step (i.e., what the application returns to the model each iteration).

When diagnosing a poor tool-use implementation in an agent loop, what two aspects should you identify?

The immediate bug in the implementation.
The consequence for the agent loop (how that bug breaks or degrades the tool-call/response iterations).

In an LLM tool/function-calling setup, what does a tool definition normally contain, and what is the abstract schema for it?

A tool definition is a structured description that tells the LLM what a function does and how to call it. It normally contains:

name
- Identifies the function.
description
- Explains what the tool does and when it is appropriate.
parameters
- Defines accepted arguments, their types, and often which arguments are required.

Abstract schema: Tool = (name, description, parameters).

Why is the parameter schema in a tool definition crucial for correct tool use by an LLM-based agent?

The parameter schema is crucial because the model does not directly inspect the Python implementation. Instead, it decides whether and how to use a tool based on:

the natural-language description, and
the parameter specification supplied in the request.

So the schema guides the model’s calling behavior by making the tool’s inputs (argument names, types, and required fields) explicit, enabling correct invocation even without access to underlying code.

What three questions should a good tool description answer to help an agent select and call the tool appropriately?

A good tool description should answer:

What does the tool do?
When should the agent use it?
What does each parameter mean?

Together, these clarify the tool’s purpose, its appropriate usage conditions, and how to fill in the parameter values correctly when calling it.

An agent has access to two tools: web_search with a string parameter query, and calculator with a string parameter expression (e.g., 2 + 2 3*). How should their descriptions guide correct tool selection?

The descriptions should steer selection by stating the appropriate use-case for each tool:

web_search (parameter: query as a string)
- Its description should tell the model to use web search for current information.
calculator (parameter: expression as a string, e.g. 2 + 2 * 3)
- Its description should tell the model to use it for arithmetic / mathematical calculations.

If a tool’s underlying implementation works correctly, what can still go wrong if its model-facing description is poor, and what is the benefit of a well-described tool?

Even if the implementation is correct, a poor description can cause the tool to be:

ignored (the model fails to select it), or
misused (the model selects it but calls it inappropriately).

Conversely, a well-described tool is easier for the model to select and call appropriately, because its intended purpose and parameters are communicated precisely.

When implementing a tool/function schema for an agent, how should you choose parameter types so the agent can correctly call external APIs or systems? Give at least three examples or rules.

Choose parameter types that match the real input being requested, so the tool call is unambiguous and machine-checkable.
- A search query should be a string (e.g., query).
- A customer identifier may be a string or integer depending on the system (e.g., customer_id).
- A yes/no flag should be a Boolean, not the text "yes".
State the expected type in the schema so the model can generate structured arguments that software can validate before execution.

In a function/tool schema, what does it mean to mark a parameter as required, and why is that important for safe tool use?

A parameter is required when execution cannot work without it.
- Example: if expression is required for a calculator tool, the model should not be able to call the calculator without providing expression.
Marking required parameters prevents under-specified calls and forces the model to supply the minimum necessary information before the application attempts execution.

For a database tool schema, how should the schema distinguish between identifiers and filters to support correct function calling?

The schema should distinguish required identifiers from optional filters.
- Required identifiers are the core fields the database operation needs to target the correct entity (e.g., an ID).
- Optional filters refine or constrain results but are not necessary for the tool to run.
This distinction helps the model reliably supply what is necessary while allowing flexibility in adding constraints when relevant.

What are the schema design principles for tool/function parameters that improve an agent’s ability to select and parameterize tools?

Use names that describe the value (e.g., filepath, query, customer_id).
Give every parameter a precise description.
State the expected type.
Mark parameters as required when execution cannot work without them.
Avoid ambiguous parameters such as input when a more specific name is possible.
Describe restrictions, such as accepted date formats or allowed file locations.

In tool use/function calling, what is the role of the LLM vs the role of the application regarding argument correctness and execution safety?

LLM role: generate structured arguments that match the function schema (the connection from natural-language reasoning to executable calls).
Application role: remain responsible for checking that those arguments are valid before execution.
- This means parsing and validating the request before it reaches the external system.

When integrating an agent with an external system, why should you begin implementation with the tool definition, and how does a clear schema help control external actions?

Begin with the tool definition because the model can only select and parameterize a function it can understand.
A clear schema (e.g., a calculator tool with a clear purpose and required expression string) converts an informal decision into a structured request software can execute.
Because the schema specifies the function and its arguments, the application can parse and validate the request before it reaches the external system, turning language-model reasoning into a controlled implementation of tool use.

In a tool-calling agent architecture, what are the distinct responsibilities of the LLM versus the surrounding application, and why is this separation central for safe execution?

LLM (reasoning component)
- Interprets the user’s request.
- Decides whether a tool is needed.
- Produces a structured request (e.g., function name + JSON arguments) rather than executing anything itself.
Application (execution component)
- Validates the request.
- Calls the real function (e.g., API/database/software action) and obtains the result.
- Sends the result back into the conversation for the LLM to continue.
Why central
- The LLM does not directly run a database query or send an API request; the program decides whether and how a requested action may be executed.

In the “basic call cycle” for tool calling, what are the 7 steps from sending context to continuing the conversation after tool execution?

The application sends messages and available tools to the LLM.
The LLM returns either ordinary text or one or more tool calls.
If there are tool calls, the application extracts the function name and JSON arguments.
The application looks up the implementation in a tool registry.
The implementation runs and returns a result or structured error.
The application adds the result with the relevant tool-call identifier.
The LLM receives the updated conversation and continues.

When using `tool_choice="auto"` in a minimal agent, what does the model have permission to do, and what specific field should the application check to detect requested tool executions?

With `toolchoice="auto"`
- The model may call a tool or answer directly in ordinary text.
Application-side detection
- The application checks `assistantmessage.tool_calls` to see whether the assistant produced tool calls that need execution.

After a tool implementation returns, how should the application incorporate the tool output into the conversation so the LLM can continue correctly?

The application adds the result back into the conversation.
It must attach the result with the relevant tool-call identifier, so the LLM can associate the returned output with the specific tool call that requested it.
Then the LLM receives the updated conversation and continues generating the next step.

In a tool-calling agent, what is a tool registry, and what problem does it prevent when executing model-requested tools?

A tool registry is a mapping from a model-generated tool/function name (a string) to a real callable function in the application.

What it does: lets the application look up the requested tool name and obtain the corresponding executable function.
What it prevents: it prevents the application from treating arbitrary names produced by the model as executable code (i.e., only names present in the registry can be executed).

Write the minimal tool-calling execution loop as an ordered algorithm, from initializing messages to returning the final assistant text.

Initialize the conversation messages with a system message and the user request.
Send the messages and the tool definitions to the LLM.
Append the assistant message to the conversation.
Check whether the assistant requested a tool.
Parse the requested function name and the JSON arguments.
Look up the function in TOOL_REGISTRY.
Execute the function with the parsed arguments.
Append the result as a tool message using the tool-call identifier.
Repeat the loop.
Return the assistant’s text when no tool call remains.

In the minimal tool-calling loop, what specific data must be parsed from a tool request before execution, and why is each needed?

You must parse:

Function name
- Needed to look up the corresponding callable in TOOL_REGISTRY.
JSON arguments
- Needed to execute the function with the intended inputs supplied by the model.

What is max_iterations in a tool-calling execution loop, what failure mode does it mitigate, and what default value is used in the lecture implementation?

max_iterations is a safety limit on how many times the loop will call the model and process tool calls.

Mitigated failure mode: without it, a faulty model or repeated error could produce an infinite loop.
Default in the lecture implementation: 10 iterations.

When appending a tool’s output back into the conversation, what identifier must be used and what is its role in the tool-calling loop?

The tool output should be appended as a tool message using the tool-call identifier.

Role: it associates the returned tool result with the specific tool call that the assistant requested, so the conversation state correctly reflects which call produced which output.

In a tool-calling agent, what makes two tool calls dependent, and how does that affect the agent’s execution strategy?

Two tool calls are dependent when a later call cannot be formed until an earlier tool result is available. That forces an iterative execution strategy:

The model emits a structured tool call for the first missing piece of information.
The tool runs and returns data as a tool message.
A subsequent model call uses that returned data to construct the next tool call (or the final response).

So the agent cannot “plan and call everything at once”; it must interleave model decisions with real tool results.

For the user query “What day is it today, and what is 2^(today’s day number)?”, what complete message/tool sequence implements the required dependent tool calls (including the concrete example outputs)?

One correct dependent sequence is:

User message: “What day is it today, and what is 2^(today’s day number)?”
Assistant tool call: getcurrentdate()
Tool result: {"date": "2026-03-19T14:30:00"}
Assistant tool call: calculator(expression="219")
Tool result: {"result": 524288}
Assistant final response: “Today is March 19, 2026. 2^19=524,288.”

The second call depends on extracting day number 19 from the first tool result.

When implementing a tool-using agent for dependent tasks, why must each new model call include the original question and previous tool results?

The conversation history is essential because each new model call must include:

the original question, and
the previous tool results

Otherwise, the model cannot reliably know what has already happened. For dependent calls, the model needs prior tool outputs (e.g., the returned date) to construct the next call (e.g., the calculator expression) and to produce the final response.

In the tool-calling execution loop, what are the roles of (1) the LLM, (2) the registry, and (3) the tool message?

The loop connects model decisions to real execution:

LLM: emits a structured call indicating which function/tool to invoke and with what arguments.
Registry: selects the corresponding implementation for that structured call.
Tool message: returns the resulting data back into the conversation so the next model call can use it.

This supports multi-step tasks where tool outputs feed subsequent decisions.

Using the date-and-calculation example, explain why function calling should be implemented as an iterative control loop rather than a one-time API invocation.

It is an iterative control loop because the agent must alternate between:

calling a tool to obtain missing information, and
using the returned tool data to decide the next action.

In the example, the first function supplies the missing day number (from {"date": "2026-03-19T14:30:00"}), which enables forming the second function call calculator(expression="219"). Only after receiving {"result": 524288} can the final model call transform both tool results into the user-facing answer.

What kinds of capabilities do tools add to an agent beyond text generation, and what are the main categories mentioned?

Tools extend an agent beyond text generation by letting it interact with external systems and resources. Main categories mentioned include:

Information-retrieval tools
- Examples: web search, database queries, document retrieval.
Communication tools
- Examples: email, Slack, API calls.
File operations
- Allow the agent to read, write, or edit files.
Code-execution tools
- Run programs in controlled environments.

In an external API tool implementation, what should happen to validated function arguments, and why should the tool’s result be formatted in a specific way?

The implementation should:

Translate validated function arguments into an authenticated request
- This connects the agent’s tool call inputs to a real external API action.
Convert the API result into a predictable format that the LLM can understand
- A predictable format makes it easier for the model to reliably interpret the outcome and decide what to do next.

Given a tool schema with "name": "get_weather" and parameters city (string) and date (string, ISO YYYY-MM-DD), what must the tool implementation do end-to-end to make the tool call reliable?

A reliable implementation should:

Validate inputs
- Validate the city and the date (ISO format: YYYY-MM-DD).
Call the external service
- Call the weather service using the validated inputs.
Handle authentication
- Make the request authenticated as required by the API.
Handle failures
- Handle network failures.
Return a structured, model-readable result
- Return structured weather data or an error object.

Why is returning structured weather data or an error object useful for the model’s next decision step in tool use?

Returning structured weather data or an error object helps because it enables the model to:

Judge sufficiency
- Decide whether the returned data is sufficient for the user’s request.
Decide on follow-up tool use
- Decide whether another call is needed (for example, if an error occurs or information is incomplete).

In the provided API tool design snippet, what are the exact parameter names, types, and the stated constraint on date?

The snippet specifies these parameters:

city
- type: "string"
- description: "The city for the forecast"
date
- type: "string"
- description: "Date in ISO format, YYYY-MM-DD"

When implementing an agent tool that queries a database, what is the key security practice for constructing SQL, and what risk does it prevent?

Use parameterized queries rather than concatenating raw model-generated text into SQL.

How: put user/model inputs into parameters (placeholders) and keep the SQL structure fixed.
Why: prevents model-provided text from being interpreted as executable SQL, protecting the database from unsafe queries.

An agent tool exposes a database function search_orders(customer_id, status). What end-to-end steps should this function perform to be safe and useful?

Validate inputs: validate the customer identifier and any filter values (e.g., status).
Construct SQL safely: build a parameterized query using the validated inputs.
Execute the query: run the parameterized statement against the database.
Return structured results: return records such as order IDs, dates, and statuses (not unstructured text).

What access and exposure limits should be applied when offering database tools to an agent (focus on scope, permissions, and output size)?

Apply limits that reduce what the tool can touch and how much it can reveal:

Restrict scope: restrict which tables and operations are available.
Prefer read-only: use read-only access unless writes are necessary.
Limit output: limit the number of returned records to reduce exposure and overload.

What should a database tool return and record (logging) so that an agent can reliably handle outcomes without leaking secrets?

Return structured outputs:
- Structured records for success (e.g., fields like IDs, dates, statuses).
- Structured errors for failures (so the agent can branch on error type/fields).
Log safely: log the operation while not exposing sensitive data in logs.

For database tools used by agents, what input checks are required before querying, and what kinds of inputs do they apply to?

Perform validation on both identity and filtering inputs:

Validate identifiers (e.g., a customer identifier) to ensure they meet expected format/constraints.
Validate filter values (e.g., optional status) so only allowed/expected values influence the query.

In an agent tool that interacts with a software system (files, code execution, document edits, messaging), how should you reason about risk differences between actions, and why does this matter for tool design?

Different software-system actions have different consequences, so tool design must match the risk level.

Lower-risk example: reading a permitted text file is usually less consequential.
Higher-risk examples:
- sending an email
- modifying production data
Why it matters: higher-risk actions need stricter interfaces and stronger enforcement (validation and permissions) so the agent gains capability without being given unrestricted control over the underlying system.

Implement “safe file-access logic” for a `read_file(filepath)` tool: what checks and steps should the tool perform from receiving `filepath` to returning a result?

A safe `read_file(filepath)` tool should follow a validation-first sequence:

Receive `filepath` from the model.
Resolve the path.
Check directory containment: verify the resolved path is inside the approved directory.
Check file type: verify it is a permitted file type.
Attempt to read the file.
Return the file contents, or return a structured error.
Never expose unrestricted filesystem access to the model.

A `read_file(filepath)` tool has two specific protections to prevent arbitrary filesystem access. What are they, and what threat do they mitigate?

The two protections are:

Error handling: handle file-not-found and permission-denied errors and return a structured error instead of crashing or leaking unintended behavior.
Directory restriction: restrict access to a specific directory (after resolving the path) so the agent cannot read arbitrary files on the machine.

Together, these mitigate the threat of the agent using tool arguments to access files outside intended scope and causing unsafe or unintended outcomes.

Why is using `eval` for code execution risky in production agent tools, and what implementation control is explicitly required instead?

Using `eval` is risky because it can execute malicious or incorrect code passed via tool arguments. Production systems therefore need a proper sandbox.

What the sandbox does:
- limits what code can access
- reduces the consequences of malicious or incorrect tool arguments

When connecting an agent to an external API/database/software system, how do the tool schema and the tool implementation split responsibilities to keep access safe?

Safety comes from a division of labor:

Tool schema (LLM-facing): gives the LLM a narrow, understandable interface.
Tool implementation (system-facing): enforces the real permissions via validation and access controls before execution.

This lets the agent gain useful external capabilities without receiving unrestricted control over the underlying system.

For a database tool function, what two implementation constraints are described to keep queries within safe bounds?

A database tool should:

Expose only approved parameters (limit what the model can ask for via the tool interface).
Use a parameterized query (so the system enforces safe query construction rather than trusting raw model-provided strings).

When implementing tool use/function calling for an agent, what kinds of failures should you expect from a tool call, and what is the key robustness requirement for the tool’s behavior when they occur?

Common tool failure causes
- Invalid arguments
- Missing file
- Denied permissions
- Network problem
- Unavailable API
- Malformed model request
Robustness requirement
- Return an explicit error to the agent instead of crashing, so the agent can respond programmatically.

A tool call fails during agent execution. What recovery behaviors can the model/agent take after receiving an explicit error response?

The agent/model can use the error to choose an appropriate recovery action, such as:
- Correct its arguments (fix inputs and try again).
- Retry (when the failure may be transient, e.g., network issues).
- Ask the user for clarification (if the error suggests missing/ambiguous information).
- Choose another tool (if the current tool/API is unavailable or unsuitable).

In a sophisticated agent, what should happen when a search tool returns no results, and why is this part of error/recovery handling?

Expected behavior
- Recognize that the search returned no results and try an alternative query.
Why this fits recovery
- “No results” is an outcome the agent should treat as a failure-to-achieve-goal signal and respond by adjusting its approach rather than stopping.

In structured error handling for tools, what is the core principle about the error format, regardless of the exact schema used?

Core principle
- The tool result (success or error) should remain machine-readable and be sent back through the same tool-message mechanism, so the agent can parse and act on it reliably.
Implication
- Do not crash or emit an unstructured failure; instead, return a structured payload the agent can interpret.

Consider this tool wrapper pattern: it returns json.dumps({"ok": True, "data": result}) on success; it returns json.dumps({"ok": False, "error": "Permission denied"}) on PermissionError; otherwise it returns json.dumps({"ok": False, "error": str(error)}). What does this structure enable the agent to do, compared with a crash?

Enables programmatic handling
- The agent can reliably check "ok" to distinguish success vs failure.
- On success, it can consume "data".
- On failure, it can read "error" and decide whether to correct arguments, retry, ask for clarification, or choose another tool.
Compared with a crash
- A structured response preserves control flow and lets the agent recover rather than terminating execution.

In agent tool use, what is the action space, and why does widening it create a reliability/safety tradeoff?

The action space is the set of actions available to the agent.

Narrow action space
- Safer but less capable: fewer actions means fewer ways to cause harm.
Broad action space
- Enables more useful behavior but increases the possible damage from mistakes because more powerful actions are available.

Distinguish narrow, medium, and broad action spaces for agent tool access, including the key safety/engineering implications of each.

Narrow action space
- Safer, easier to test, but limited.
Medium action space
- Useful for controlled workflows, often with human review.
Broad action space
- Powerful, but requires strong permissions, sandboxing, validation, and oversight.

An agent is being upgraded from “only classifies emails” to “read emails and draft replies” and then to “read emails, execute code, modify files, and send messages.” How does its action space change across these versions, and what risk trend follows?

Only classifies emails
- A narrow action space.
Read emails and draft replies
- A broader action space than classification-only.
Read emails, execute code, modify files, and send messages
- A very broad and risky action space.
Risk trend
- As the action space broadens, the possible damage from mistakes increases.

Before executing an agent function call, what validations and checks should an application perform to control risk?

The application should check:

Function name
Argument types
Allowed values
User permissions
Possible side effects

These checks constrain what the agent can do and reduce unsafe or unintended tool actions.

For agent tool use in production, which kinds of operations may require explicit human approval, and why?

Operations that may require explicit human approval
- Payments
- File deletion
- Sending messages
Why
- They are high-impact operations with significant potential side effects or damage if performed incorrectly.

In an agent that uses function calling to interact with external APIs/software, what are the key differences between a minimal implementation and a production implementation?

Minimal agent
- May only print tool calls, trust model arguments, and execute sequentially.
- Keeps only the current conversation (no long-term memory).
- Often lacks explicit planning, self-reflection, robust error recovery, parallel execution, and cost awareness.
Production agent
- Requires stronger engineering to make external interactions reliable and controlled, beyond the basic tool-calling pattern.

For production-ready tool use with external APIs/databases/software systems, what concrete engineering requirements help ensure reliability and safety?

Error handling
- Retries and graceful degradation when tools fail.
Data correctness controls
- Schema validation and input sanitization.
Resource controls
- Token and cost limits.
Observability
- Structured logs, traces, and monitoring.
Execution safety
- Sandboxed code execution.
Access control
- Permission systems to restrict what actions/tools are allowed.
State management
- Long-term and episodic memory where appropriate.
Performance
- Parallel execution for independent calls.
User experience
- Streaming output and progress indicators.
Runaway prevention
- Maximum iteration limits and termination checks.

When implementing function calling for real external systems, why should the function call be treated as untrusted input, and what controls make execution dependable?

The function call should be treated as untrusted input because a wrong argument or failed API can otherwise become an uncontrolled system action if executed blindly. Dependability comes from adding controls such as:

Validated schema to constrain the tool-call structure and arguments.
Restricted permission set so even “valid” calls cannot exceed allowed actions.
Sandbox to isolate code execution from the host environment.
Structured error response so failures are handled consistently rather than cascading.
Iteration limit to prevent runaway loops and enforce termination checks.

An agent that calls tools executes everything sequentially and “trusts” the model’s chosen tool arguments. What specific production gaps does this create, and what production-oriented capabilities address them?

Gaps created
- No robust error recovery (tool failures can stall or break the run).
- No parallel execution (independent calls take longer than necessary).
- No cost awareness (can exceed token and cost limits).
- No long-term memory (cannot retain useful information beyond the current conversation).
Capabilities that address the gaps
- Error handling with retries and graceful degradation.
- Parallel execution for independent calls.
- Token and cost limits.
- Long-term and episodic memory where appropriate.

When defining a “smallest suitable tool interface” for function calling, what fields must you include, and what design constraint should guide the interface size?

Fields to include
- Name of the tool.
- Description of what it does.
- Parameters (the inputs the function accepts).
- Required fields (which parameters must be present).
Size constraint
- Use the smallest suitable interface that still accomplishes the user’s task (avoid extra parameters or capabilities not needed for the task).

In a tool-use design answer, what must you say to justify whether the model should or should not use a tool, before you show the expected function name and arguments?

First identify the user’s task and determine whether it requires external information or action.
Then explicitly explain why the model should use a tool (because the task needs external info/action) or should not use a tool (because the task can be completed without external info/action).
Only after that justification do you present the expected function name and arguments as the model’s generated call.

For a compound-interest tool argument, what formula can be delegated to a calculator tool, and what do the symbols A, P, r, and n mean?

Formula: A = P(1 + r)ⁿ
Symbols
- A = final amount
- P = initial investment
- r = annual interest rate as a decimal
- n = number of years

In the compound-interest example, what exact expression is delegated to the calculator tool, what approximate result is returned, and what is the exam’s main tool-use skill being tested?

Delegated expression: 10000(1.07)²⁰
Returned result (approx.): $38,696.84
Main skill being tested
- Not the formula itself, but whether the agent correctly delegates precise calculation to the tool and then uses the returned result appropriately.

When an agent selects the wrong tool in a function-calling setup, what should you inspect first, and what is the likely root cause?

Inspect (1) the tool descriptions and (2) the user request.

Why: The model’s tool choice is driven by the available tool descriptions, so if descriptions are vague or overlapping, the model can plausibly misuse a tool even when the user request is clear.
Implication for implementation: Make each tool description specific about purpose and timing (when it should be used) to reduce ambiguous selection.

In a tool-calling application, what should happen if JSON parsing fails for the model’s function-call arguments, and what must not happen?

If JSON parsing fails, the application should reject the call, return an error, or use a stricter structured-output mechanism.

Must not: Execute partially parsed or ambiguous arguments.
Reasoning: Ambiguous/partial parsing breaks the safety contract between model output and application execution; only well-formed structured arguments should be eligible to run.

If the model calls a tool name that does not exist in the tool registry, what behavior should the registry/dispatcher implement?

The registry lookup should produce a controlled error.

Implementation expectation: Explicitly handle the “tool name unknown” case and return a result such as "Unknown tool" rather than failing unpredictably or attempting a best guess.
Reasoning: Tool dispatch must be deterministic and auditable; unknown tools should not map to any real software action.

In a multi-tool task, what does it mean if the agent stops after the first tool call, and what implementation behavior is required instead?

Stopping after the first call means the agent failed to preserve or process the returned result.

Required behavior: Keep the loop running until the model has enough information to produce the final answer, using returned tool results as new context for subsequent reasoning and possibly additional calls.
Key point: Multi-tool tasks are dependent calls; the application must support continuing execution, not a single-shot call.

Describe the full end-to-end implementation chain for safe and effective tool use (from tool description to safety limits).

Clear description enables correct tool selection.
Correct selection produces a structured function call.
Schema validation makes the call safe to execute.
The registry maps the name to real software.
The external system returns data or an error.
The tool message gives that result back to the LLM.
The loop enables further calls or a final answer.
Safety limits prevent the agent from becoming uncontrolled.

For tool-use exam answers (and real implementations), what key components should you include to show the separation of model reasoning from application execution and safe operation?

Include the elements that demonstrate a controlled pipeline, not isolated features:

Tool definition quality: specific description (purpose/timing), clear parameter names, types, required fields.
Control boundary: separate model decision-making from application execution.
Guards: validate arguments and permissions; mention security controls for files/APIs/databases/code.
Dispatch: show the registry/dispatch mechanism and returning results with the correct tool-call reference.
State + iteration: preserve conversation history, handle multiple dependent calls, include errors and a maximum iteration limit.

How do tool definitions (name/description/parameter schema) and the tool-calling execution loop work together to safely connect an LLM’s reasoning to real external execution?

Tool definitions tell the LLM what it can ask for and how, while the execution loop is the application-controlled bridge that decides whether and how to execute it.

Tool definition: enables correct selection and well-typed arguments (required fields, formats like YYYY-MM-DD).
Execution loop: detects tool calls, parses JSON args, validates, dispatches via a registry, executes, then appends a tool message so the LLM can continue or answer.
Safety emerges from combining both: schema/permissions constrain the request; the loop enforces validation, registry lookup, and iteration limits before any external action occurs.

Why is a tool registry necessary in addition to schema validation when implementing function calling, and how do they complement each other?

Schema validation checks that a requested call is well-formed (correct parameter names/types, required fields present, allowed values), but it does not guarantee the function name maps to safe code. A tool registry provides a controlled mapping from model-generated tool names to preapproved implementations.

Schema validation reduces malformed or unsafe arguments reaching the external system.
Registry lookup prevents executing arbitrary or unknown tool names and enables a controlled “Unknown tool” error.
Together: the registry constrains what can run, while validation constrains how it can be run.

In a dependent multi-tool task like “Read data.txt and calculate the average,” how do conversation history and structured tool outputs jointly enable the second tool call?

The second call depends on results from the first, so the application must preserve full message history and return tool outputs in machine-readable form.

History: each new model invocation includes the original user goal plus prior tool results, so the model knows what has already happened and what data it has.
Structured output: the file tool returns contents (or a structured error), which the model can reliably transform into a calculator(expression=…) request.
Loop behavior: the agent repeats call → tool result → updated context until no further tool calls are needed.

How do structured error responses and max_iterations work together to make tool use robust when external calls fail (API/network, permissions, malformed requests)?

Structured errors keep failures machine-readable so the model can recover, while maxiterations prevents infinite retries or looping failure modes.

Structured error: tool returns something like {"ok": False, "error": "..."} instead of crashing, allowing the model to retry, correct arguments, ask for clarification, or choose another tool.

maxiterations: stops runaway cycles when repeated errors occur or the model keeps requesting tools without progress (lecture default: 10).
Combined effect: the agent can attempt recovery safely, but remains bounded and terminates predictably.

How does an agent’s action space affect the engineering controls you must implement for tool use across APIs, databases, and software-system tools?

As action space broadens, the potential impact of mistakes increases, so stronger controls are required beyond the basic tool-calling pattern.

Narrow action space: safer and easier to test (e.g., classification), fewer permissions and side effects.
Medium action space: useful workflows often benefit from human review and clearer permission boundaries.
Broad action space: high risk (execute code, modify files, send messages) and therefore needs strict validation, permissions, sandboxing, structured error handling, logging/monitoring, and sometimes explicit human approval for high-impact operations (payments, deletion, sending messages).

Implement tool use and function calling mechanisms that allow agents to interact with external APIs, databases, and software systems

91 important questions on Implement tool use and function calling mechanisms that allow agents to interact with external APIs, databases, and software systems