Tool Calling
Schemas, structured arguments, validation, errors, retries, permissions.
The model emits a structured request to call a function; your application executes it and feeds the result back — the model never runs anything itself.
The name, description and JSON schema of a tool are the only documentation the model ever reads — write them like an API contract, not a comment.
Constrain the model to emit JSON that matches a schema, then parse it into typed objects — the right abstraction when you need data, not actions.
Model-generated arguments are untrusted input from a probabilistic source — validate types, ranges, allow-lists and paths before execution, and feed violations back as re-prompts.
Classify tool failures as retryable or not, retry with exponential backoff and jitter under a timeout, and surface the rest to the model as observations it can reason about.
In an at-least-once world, a tool with side effects must be safe to call twice with the same arguments — idempotency keys make retries and re-runs harmless.
Run independent tool calls concurrently and dependent ones in order — a dependency graph, a fan-out limit, and deterministic result ordering keep it fast and debuggable.
Give each tool the narrowest scope that does the job, separate reads from writes, act with the user's delegated authority, and gate destructive actions behind confirmation, sandboxes and audit logs.