Tool execution loop
When an agent defines tools, the runtime runs an iterative loop: send schemas to the provider, accept tool calls or final text, validate inputs, execute tools, feed results back, repeat until completion or max_iterations. Default mode is llm_select; legacy legacy_eager exists for compatibility.
Agent setup: Defining agents. Execution context: Execution model.
ToolExecutionConfig
| Mode | Behavior |
|---|---|
llm_select | Model chooses whether to call tools each turn (default) |
legacy_eager | Older eager execution path; prefer llm_select for new workflows |
Default max iterations is enforced by the engine. When exceeded, the step fails with an appropriate error code (often StepExecutionFailed).
Loop sequence (LlmSelect)
Tool definition and validation
Invalid call example the runtime rejects:
Trace:
Example trace for successful tool call
trace data policy: traces record schema hashes and byte sizes, not tool arguments or results. See Trace data policy.
Python tool registration
Examples use @tool decorator patterns:
Multi-tool turns
The model may request multiple tools in one provider response. The runtime executes each validated call before the next provider round. Order is deterministic within the engine implementation; do not rely on cross-tool side effects for correctness.
Provider errors during tool loop
| Event | Meaning |
|---|---|
ProviderRateLimited | Backoff or retry per Retry and backoff |
ProviderError | Terminal if not recovered |
ToolCallFailed | Handler threw or returned error |
Rate limits may include retry_after_seconds in trace metadata.
Testing tool loops
Use stub provider and test mode to avoid live API:
For integration tests with real tool validation, use minimal schemas and stub handlers in SDK examples under examples/.
Related pages
- Defining agents
- Provider configuration
- Validation and testing
- Vector RAG pipeline (retrieval as memory, not custom tools)