Design preview · Sample content — not a released episode or final script.
Systems & tools
A tool call is an interface, not a superpower
Tools connect generated decisions to concrete operations. The interface determines what can happen and how a result gets checked.
Video embed placeholder — no video attached
A text model can explain how to look something up. A tool-enabled system can request a lookup and use its result. The difference is an interface between language and software. That interface should make the operation explicit enough to validate before anything happens.
From words to structured arguments
A tool definition tells the model which operation is available and what inputs it accepts. Instead of writing a vague instruction, the model can produce a structured request with named arguments. A document lookup might require an identifier and a query. A calculator might require an expression. The surrounding software checks whether the request matches the expected format and whether the operation is permitted. Well-formed arguments are necessary, but they do not guarantee that the proposed action is appropriate.
Execution produces an observation
Once an operation runs, it returns data or an error. That result becomes new evidence for the model's next response. The system should distinguish what the tool actually returned from what the model inferred. A successful lookup can establish that a document was found; it does not establish that every claim in the document is true. This distinction is especially useful when tools read material written by other people.
A simplified mechanism
- Proposed call
- Validate schema
- Check permission
- Execute
- Return observation
If validation or permission fails: reject or ask for clarification
Failures are part of the contract
Tools can time out, receive invalid inputs or return incomplete results. A system needs a policy for those cases: retry when appropriate, revise the request or explain the limitation. Repeating the same failed action without new evidence can waste time and obscure the underlying problem. The useful response depends on whether the failure is temporary, whether the requested operation is supported and whether another permitted path exists.
Design the boundary deliberately
Useful tools expose clear operations with narrow inputs and understandable outputs. Permission checks, audit records and human approval can sit outside the model. Those boundaries make it easier to see what happened and to control consequential actions. This sample focuses on a general interface pattern. Before evaluating a particular assistant, inspect which tools it has, what those tools can change and how their results are verified.
Design preview
Related sample articles
How an AI agent turns a goal into a loop
A useful way to understand an agent is to follow the cycle between a model, its tools and the software that keeps track of progress.
Context and memory solve different problems
What a model can see during a response is different from what a system stores and retrieves between responses.