Stage 04 of 11 · Tool-Using Agents · 3 min · Reviewed Aug 2026
Tool-Using Agents: Calling, Design, Memory, Middleware
Function-calling APIs are one implementation. The educational point is the observation: the model emits a structured call, software runs, a result returns. Memory is how the next turn knows what happened. Middleware is where you put permissions, retries, and logs. Fluent text is not a tool result.
- Tool calling
- Tool design
- Memory
- Middleware
What you learn
How agents interact with the real world through tools, memory, and a permissioned runtime.
The contract is the schema
Tools declare names, descriptions, and JSON-schema arguments. The model fills the arguments. Your runtime validates, executes, and returns an observation. Unexpected payloads are errors, not prose to smooth over.
Write descriptions for the model, not for marketing. Say when not to call the tool. Enums beat free-text. Required fields beat “optional unless you need it.”
{
"name": "get_order",
"description": "Fetch one order by id. Do not use for refunds.",
"parameters": {
"type": "object",
"required": ["id"],
"additionalProperties": false,
"properties": {
"id": { "type": "string" }
}
}
}Visual
Tool Call Lifecycle
The model emits a structured tool call. The runtime validates arguments against the schema, executes the function, and returns an observation. Invalid arguments are rejected as errors, not smoothed over.
Tool design: small, idempotent, boring
One tool, one job. get_order(id) and refund_order(id, reason) beat do_commerce(action, payload). Idempotency keys belong on anything that spends money or sends email. Timeouts belong on anything that talks to a network.
Return compact, typed observations. Do not dump HTML. Do not return stack traces to the model unless you intend it to debug. Do not let a tool return 40k tokens of logs into the context.
{
"ok": true,
"id": "ord_19",
"status": "paid",
"total_cents": 4200
}