How the executor tree grows
Public Preview

Understand nested executors and deadlines

One SDK submission divides work across an executor tree and returns one terminal outcome within a single task deadline.

One SDK submission divides work across a root and child executor tree, returning one terminal outcome with bounded nesting and absolute delegated deadlines.

  • Each child executor returns its outcome to the caller as a tool result.
  • The harness gives each child an absolute deadline within its caller's remaining time.
  • A task stop applies to all work delegated under that task.
  • The Dashboard executor tree shows stable identifiers, ancestry, and observed activity times.
  • A bounded final-writing phase can finish after the task deadline using work captured before it.

Summaries were generated by AI. Generative AI is experimental.

One SDK submission can divide work across an executor tree and still return one terminal outcome. Each executor is one bounded unit of agent work. The root handles the submitted task; child executors handle delegated work and can delegate smaller parts again.

How the executor tree grows

The root creates a child executor when part of the task needs a separate focus. The child receives its own instruction and working context.

Several children can work on separate parts. A child can also delegate further work. Each delegated child returns an outcome to the executor that called it. The parent receives that outcome as a tool result and continues its own work.

Nested executor work inside one taskOne task starts a root executor. The root delegates two focused pieces of work. One child delegates a smaller piece again. Each child result returns to its caller, and the root produces the terminal task outcome.

Each child executor uses the tool set defined by its handoff. Depending on the work, that set can include built-in tools or functions your process registered with @tool.

The platform sets fixed bounds for nesting and the number of delegated executors. A task stop also applies to work delegated under that task. Scope and limits defines stop behavior.

How task and child deadlines relate

All delegated work stays within the task deadline your application sets.

The harness gives each child executor an absolute deadline within its caller’s remaining time. A child can use less time, but it cannot extend the task deadline. Further delegation follows the same rule.

A short, bounded final-writing phase can finish after the task deadline by using work captured before it. Scope and limits defines this phase. Routing contract and limits defines the end-to-end boundary.

Set one deadline for the full task. The harness derives child deadlines within it.

Read the Dashboard as an observed trace

Use the Dashboard executor tree to see how the task divided work. Each trace has a stable executor identifier, records ancestry from the root, and shows the earliest and latest activity observed for that executor.

Executor names and tree shapes can differ across runs. Use identifiers and ancestry to correlate activity, and use the terminal task outcome to confirm completion.

Context continuity explains how each delegated branch keeps a separate working context and returns its result without merging full transcripts.