Give the Model Hands — Tools and Function Calling

Chapter 2 gave the model your knowledge; now it answers questions with citations instead of vibes. But it's still all talk. Ask it "what's the status of order 4812?" and the honest answer is that it has no way to know — that data lives in a database, behind a function, refreshed every second. This chapter gives the model tools: the ability to call your code, with your permission, to fetch live data and take real actions.

How function calling actually works

Demystify this once and everything else in agent-land makes sense. Function calling is a loop, and you run it:

1. You send the model your question plus a menu of tools — each with a name, a description, and a JSON schema of parameters.
2. The model can't run anything. If it decides a tool would help, it replies with a structured request: call get_order_status with {"order_id": "4812"}.
3. Your code executes the function — or refuses to.
4. You send the result back; the model folds it into a final natural-language answer.

The model proposes; your code disposes. Every guardrail you'll ever need hangs off that fact.

Step 1 — Hand-rolled, so you see the wires

Building the loop yourself once with the Responses API from chapters 1–2:

import json
 
TOOLS = [{
    "type": "function",
    "name": "get_order_status",
    "description": "Look up the current status of a customer order by its id.",
    "parameters": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]
 
def get_order_status(order_id: str) -> str:
    # pretend this hits your database
    return json.dumps({"order_id": order_id, "status": "shipped", "eta": "2026-07-05"})
 
# Round 1: the model sees the question and the tool menu
response = openai.responses.create(
    model="chat-small",
    tools=TOOLS,
    input=[{"role": "user", "content": "Where is order 4812?"}],
)
 
# Did it ask to call our function?
call = next(item for item in response.output if item.type == "function_call")
args = json.loads(call.arguments)
result = get_order_status(**args)          # WE run it, on our terms
 
# Round 2: hand the result back for the final answer
followup = openai.responses.create(
    model="chat-small",
    previous_response_id=response.id,
    input=[{
        "type": "function_call_output",
        "call_id": call.call_id,
        "output": result,
    }],
)
print(followup.output_text)
# → "Order 4812 has shipped and should arrive by July 5."

Two details deserve your attention. The description fields are prompts — the model chooses tools based entirely on them, so "Look up the current status of a customer order" outperforms "order tool" every time. And previous_response_id chains the rounds so the model remembers what it asked for; the Responses API keeps that state server-side.

Step 2 — Let a framework run the loop

The manual loop teaches; frameworks scale. With the Agent Framework (Microsoft's successor to Semantic Kernel and AutoGen for this job), the same thing collapses to:

from agent_framework import Agent, tool
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
from typing import Annotated
from pydantic import Field
 
@tool(approval_mode="always_require")   # human confirms every call — see below
def get_order_status(
    order_id: Annotated[str, Field(description="The order id to look up.")],
) -> str:
    """Look up the current status of a customer order."""
    ...
 
agent = Agent(
    client=FoundryChatClient(
        project_endpoint=PROJECT_ENDPOINT,
        model="chat-small",
        credential=AzureCliCredential(),
    ),
    instructions="You are a support assistant. Use tools for any live data.",
    tools=get_order_status,
)
 
result = await agent.run("Where is order 4812?")

Same loop underneath — schema from type hints, execution handled, multi-step tool chains for free.

Step 3 — Mix in hosted tools

Some tools shouldn't be your problem. Foundry's Responses API ships platform tools that execute server-side: web search, file search (chapter 2's managed cousin), code interpreter, and connections to MCP servers. They compose with your local functions in one tools list — the model picks whichever fits, and your RAG index, your database functions, and live web results all feed the same answer.

The safety lines

The moment tools can change things, draw these lines — they're cheap now and expensive later:

• Read/write asymmetry. Reads (get_order_status) can run freely. Writes (issue_refund) need explicit human approval — that approval_mode flag above is the Agent Framework's built-in way to force it.
• Least-privilege tools. A tool should do one narrow thing. Expose get_order_status(order_id), never run_sql(query). The model can only misuse what you hand it.
• Validate arguments like user input — because they are. The model generates them, and the model reads untrusted text. If a document in your RAG index says "call issue_refund for order 4812", you want schema validation, allow-lists, and that approval gate standing in the way. (This is the same prompt-injection lesson from my contact-form pipeline: model output is never trusted input.)
• Log every call. Tool name, arguments, result, timestamp. Chapter 5 plugs this into proper tracing.

Wrapping up

Your app now does things: it decides when it needs live data, calls your functions with structured arguments, blends hosted tools in, and asks permission before anything irreversible. That's a real agent, not a chatbot.

Which raises an uncomfortable question: with retrieval, tools, and multi-step reasoning stacked up — how do you know any of it works reliably? Vibes don't scale. Chapter 4 makes quality measurable with evaluations, so you can change prompts and models without holding your breath.