Runtime tools are tool definitions passed inline with a dispatch API request, without saving them to the platform first. They support the same execution types as saved tools.
Runtime tools support four types:
Call any HTTP API. Configure the URL, method, headers, and body with {{parameter}} template variables.
Execute sandboxed JavaScript, TypeScript, or Python code.
Execute another saved Runtype Flow as a tool.
Spawn a focused child agent with its own context window and a restricted tool subset. The child runs in isolation — it cannot see the parent’s conversation — and only its final result returns to the parent. This keeps the parent’s context clean for a narrow sub-task that may take several tool calls.
Subagents come in three forms:
agentId. The saved agent is org-scoped and ownership-checked.agent field, with no saved agent. Set exactly one of agentId or agent.allowedTools is required and is intersected with the parent’s available tools, so the child can never use a tool the parent itself lacks (no privilege escalation). Use wildcards like mcp:* or builtin:*, or an empty array [] for a model-only child.
spawn_subagent)Instead of pre-defining a child, you can let an agent spin off focused subagents on its own. Add a subagentConfig to the agent’s tools configuration and Runtype adds a built-in spawn_subagent tool that the model can call, choosing the task, the tools to grant, and an optional system prompt at runtime.
The model grants only tools from toolPool, and that pool is itself a subset of the parent’s resolved tools — the same no-escalation rule applies. By default subagents cannot spawn their own subagents.
Include runtime tools in the tools.runtimeTools array on a prompt step:
Runtime tools can be combined with saved tools and built-in tools in the same step:
Runtime tools can reference credentials passed in the secrets field of the dispatch request. Secrets are never logged or returned in responses.
Reference them in tool configs with {{secrets.key_name}}.