Skip to main content
Programmatic subagents let an agent dispatch subagents from interpreter code. Instead of asking the model to choose one subagent call at a time, the agent can use JavaScript loops, branches, and parallel batches to route work across configured subagents and synthesize the results. Use this pattern when work spans many independent units, needs multiple perspectives, or benefits from recursive analysis. For general interpreter setup, see Interpreters.
Programmatic subagents use the interpreter runtime, which is in beta. APIs and lifecycle behavior may change between releases.

How it works

When an agent has subagents and interpreter middleware, the interpreter exposes a built-in task() global that dispatches subagents from code. A task spanning many independent units (reviewing every file in a directory, triaging a batch of tickets) becomes a loop that fans the work out, so it runs deterministically instead of one model-chosen tool call at a time. Subagent orchestration also supports recursive language model (RLM) workflows, the approach described in the Recursive Language Models paper: keep the working set in interpreter variables, select slices, call subagents with task(), and synthesize the results. task() takes the following inputs:
  • description: The prompt for the subagent
  • subagentType: Which configured subagent to run
  • responseSchema (optional): Structured output
A task() runs a full agentic loop and resolves to the subagent’s result:
When you pass responseSchema, the resolved value is already a typed JavaScript object; only call JSON.parse if a subagent intentionally returned a JSON string.

Guide orchestration

The interpreter middleware ships orchestration guidance in the system prompt, so the agent already knows how to fan out in bounded batches, filter between passes, and synthesize results. You do not hand-write that logic or prompt for it turn by turn. To shape what the agent orchestrates, work through the inputs it already responds to:
  • The subagents you configure. Their name and description define the roles available. A reviewer paired with a verifier invites a two-pass check; a single analyzer invites a straight fan-out.
  • The task message. Phrasing like “I only want confirmed issues, not maybes” or “be exhaustive” nudges the agent toward verification or an open-ended sweep.
  • The system prompt. Use systemPrompt (or the agent’s instructions) to add standing guidance when you want a consistent strategy across runs.

Patterns

The agent picks a strategy from the shape of the task; these emerge from how it writes interpreter code, not from configuration, and the subagents you make available determine what it can do. Every pattern shares one model: hold work in JS variables, dispatch subagents with task(), and combine results in code. The diagrams below show the common shapes, each with a runnable example.

Classify and act

Items are classified first, then each item is handled by a specialized subagent based on its classification. This lets you process mixed inputs where different items need different expertise. Use cases: Triaging support tickets, error logs, user feedback, or any batch of items that need different handling depending on their type.
What you configure
What the agent writes

Fan-out and synthesize

The agent dispatches the same kind of work across many items in parallel, then combines the results. Use cases: Code review across a directory, analyzing a batch of documents, processing log files, running the same check across many services.
What you configure
What the agent writes

Adversarial verification

A two-pass pattern. The first pass produces findings. The second pass sends each finding to independent verifiers, and only findings that survive agreement are kept. This reduces false positives when confidence matters more than speed. Use cases: Security audits where false positives are costly, compliance checks, any review where you need high confidence in findings.
What you configure
What the agent writes

Generate and filter

Multiple subagents generate independent solutions to the same problem. The agent compares, scores, and filters the results in code, keeping only the best. Use cases: Architecture proposals, refactoring strategies, content variations, any task where exploring multiple options before committing produces a better outcome.
What you configure
What the agent writes

Tournament

Variations are compared head-to-head by a judge subagent, with winners advancing through elimination rounds. Use cases: Optimization under subjective criteria, style selection, choosing between competing implementations.
What you configure
What the agent writes

Loop until done

The agent runs a discovery loop, deduplicating against what it has already found, until no new results appear. Useful when the scope of the work is not known upfront. Use cases: Exhaustive search, dead code detection, dependency audits, any sweep where you want completeness rather than a fixed number of results.
What you configure
What the agent writes
task() dispatches from inside an already-running eval call. It does not go through the normal tool calling path, so interruptOn approval workflows on the parent agent are not enforced per dispatch. Gate the eval tool itself if you need approval before subagent orchestration runs.

Disable programmatic subagents

Subagent dispatch is on by default whenever the agent has subagents. Disable it if you want subagents to be available only through the normal task tool path.