quiz · 4 min

Tool Use Check

Which four parts make up the tool contract described in 'What Is a Tool?'
Name, prompt, cache, and logModel, runtime, registry, and fallbackName, description, typed arguments, and deterministic implementationSchema, parser, executor, and monitor
What prevents the model from executing arbitrary code in a tool-using agent?
The model selects a name from a registry you control; your runtime maps that name to a registered function and calls itThe model is sandboxed inside the tool schema so it cannot reach outside the schema boundaryThe loop rejects any tool call whose name contains special charactersArgument validation blocks all code the model attempts to run directly
In the tool-using loop from 'A Tool-Using Loop', what happens after the runtime executes a tool?
The loop halts and returns the tool result to the caller immediatelyThe loop discards the result and calls the policy again with the original promptThe loop logs the result and waits for the next user messageThe tool result becomes the next observation and is fed back to the policy
According to 'Tool Errors & Retries', how should a tool failure be treated in the agent loop?
It should raise an unhandled exception so the caller can decide how to respondIt is a structured observation returned to the policy, which can then retry or degrade gracefullyIt should be silently swallowed so the loop continues without interruptionIt terminates the loop and returns an empty result to the caller
Why does the retry policy require an attempt budget rather than retrying until success?
Retrying more than once makes the agent non-deterministic and unusableAn attempt budget is optional; the model stops retrying once it finds the right argumentsA bounded attempt budget prevents runaway cost when a tool is broken or a resource does not existThe budget limits the number of distinct tools the agent may call in a single run