Runtime tools
Define runtime tools inline in a dispatch request instead of saving them to your account. Use them for SDK-driven workflows, temporary configurations, testing, and one-off tasks. Runtime tools support five types: external, custom, Flow, subagent, and local.
When to use runtime tools
Use runtime tools in the following cases:
- Define tools dynamically in an SDK-driven workflow.
- Test a tool configuration before you save it.
- Keep a temporary tool out of your account’s saved tool definitions.
- Define a self-referential tool that calls the Runtype API.
Tool types
Choose one of the following runtime tool types.
External
Call an HTTP API. Configure the URL, method, headers, and body in config. Use template variables such as {{city}} for tool parameters and {{secret:WEATHER_API_KEY}} for managed secrets.
The following example defines an external tool that requests weather data:
The city parameter supplies the {{city}} value. Replace WEATHER_API_KEY with the name of the managed secret that stores the API key.
Custom
Run sandboxed JavaScript, TypeScript, or Python code. Set config.code, and optionally set config.language and config.timeout.
The following example calculates a discounted price with JavaScript:
The timeout value is in milliseconds. Set language to javascript, typescript, or python; the default is javascript.
Flow
Run a saved Flow as a tool. Set config.flowId to the saved Flow ID. Use parameterMapping to map tool inputs to Flow inputs and outputMapping to extract a value from the Flow result.
The following example maps a tool input to a saved Flow:
Replace YOUR_FLOW_ID with the ID of the Flow that you want to run.
Subagent
Delegate a focused task to a child agent. The child runs in its own context window and returns only its final result to the parent. By default, the child does not receive the parent’s conversation. Set inheritMessages to true to pass the current messages to the child.
Subagent tools use exactly one of agentId or agent. Set allowedTools to limit the tools that the child can use. Runtype intersects that list with the parent’s available tools.
The following example runs a saved agent as a subagent tool:
Replace YOUR_AGENT_ID with the ID of the saved agent. To define the child inline, replace agentId with an agent object and keep only one of these fields.
The following fields configure a subagent tool:
Dynamic subagents (spawn_subagent)
Let an agent choose what to delegate at runtime by adding subagentConfig to its tools configuration. Runtype adds the built-in spawn_subagent tool. The model chooses the task, tools from toolPool, and an optional system prompt for each call.
The following tools configuration enables dynamic subagent spawning:
The toolPool must be a subset of the parent’s resolved tools. Set allowNesting to true to let a subagent spawn its own subagents.
The following fields control dynamic subagent spawning:
Local
Run a local tool in the client that drives the dispatch. When the model calls it, Runtype pauses the run and sends the tool call to that client. The client runs the handler and resumes the run with the result. A local tool does not need a config object.
Use local tools for actions that must run in the caller’s environment, such as prompting the end user or reading local state. An SDK process or CLI session can run local tools. The Runtype dashboard does not implement your local tool.
The following example defines a local tool without a config object:
Passing runtime tools in a dispatch request
Add runtime tools to the tools.runtimeTools array on a prompt step.
The following request defines one runtime external tool on the Assistant prompt step:
The {{query}} variable resolves from the tool input. The flowMode value virtual runs the inline Flow without saving it.
Combine runtime tools with saved tools and built-in tools in the same prompt step.
The following configuration combines a saved tool, a built-in tool, and a runtime tool:
Replace YOUR_TOOL_ID with the ID of the saved tool.
Secrets
Use managed secrets in hosted Flow execution. Open Settings and select Secrets to configure them. Reference a managed secret by name in supported HTTP fields.
The following example references a managed secret in an external tool header:
Replace WEATHER_API_KEY with the name of the managed secret. Use managed secret references only in external tool configuration fields.
The top-level dispatch secrets map is retired on both dispatch targets: a non-empty map is refused with 400 RUNTIME_AGENT_TRANSIENT_SECRETS_UNSUPPORTED on an agent dispatch and 400 RUNTIME_FLOW_TRANSIENT_SECRETS_UNSUPPORTED on a flow dispatch. An empty map is accepted and does nothing. Managed secret values are encrypted at rest and are not logged or returned in responses.
Limits
Runtime tools have the following limits:
- Runtime tools per request: 50 across all steps.
- Custom tool timeout: 30 seconds.
Next steps
Continue with one of the following pages:
- Creating custom tools: save sandboxed code tools
- Creating external tools: save HTTP API tools
- What are Tools?: compare tool types