LLM Dispatch

LLM dispatch is the creation of one LLM execution by another. The caller is the parent and the created execution is the child for that one edge. A child may itself create a child, so parent, worker, and orchestrator are relative positions in an execution tree rather than fixed component types.

The foundation defines one parent-child edge. Repeating the relationship creates depth; the node makes no claim about how many levels a runtime supports.

A single LLM window forces exploration, specialization, and integration through one context and one trajectory. Parent-child dispatch lets a workflow open a new reasoning surface without first resolving that thread in the current window. The child can load different context, run concurrently, or become the root of a smaller execution tree.

This is more foundational than delegation as an authority model. A parent may delegate bounded work, ask for an independent opinion, launch background work, or create a component in a composition. Those are motives. The reusable capability is that another LLM execution exists and may recursively do the same.

One edge, three scheduling modes

Every dispatch creates a distinct execution. The parent may then:

• wait immediately — a serial edge;
• continue useful work and join later — a parallel edge;
• never join — a fire-and-forget edge.

Scheduling is orthogonal to the primitive. A serial call still crosses a real context boundary; a parallel call additionally buys overlap. A return is common but not constitutive.

Context is distinct, not necessarily empty

The child normally offers a fresh canvas: its own window and trajectory. Freshness is a powerful default, not an invariant. A runtime may initialize the child from an inherited snapshot, ambient instructions, registered tools, or other standing context.

Anything in the child's initial window is dispatch input even when the runtime supplies it automatically. Worked in the shape every dispatch hits: the author writes a two-line request, and the child boots with the harness system prompt, project instruction files, registered tool schemas — and an executor it never chose (the anatomy's one slot that cannot go empty; below). Each inherited item is a live dependency: drift in any of them changes the child's behavior with no edit to the request that supposedly defines the dispatch. Accounting only for the manually authored request understates both cost and dependency — and the executor is the limiting case, because its inherited value never appears in the window at all.

Separation is symmetric while the child runs. The child cannot see the parent's window — the dispatch and the declared channels are its only aperture — and the parent cannot watch the child's trajectory: a join sees the return, not the reasoning. Each dispatch also admits the child's standing definition afresh; no warm window carries over from a previous child. What that opacity and re-boot cost in practice is the wielding patterns' subject, not this node's — Subagent Offload prices both for the context motive.

The execution context is separate even when actors share a filesystem or other external state. Every workspace location one execution writes and another reads is an additional contract seam, not shared conversational memory.

What may cross an edge

One thing always crosses: the dispatch that causes the child to exist and gives it an objective. Two other channels are conditional:

• a return may carry a result, status, artifact pointer, or declared failure back to the parent;
• a shared-world handoff may make work visible through a filesystem, queue, service, or effect surface.

A fire-and-forget edge may have neither a return nor a join. Removing the return does not create ownerless work: the parent remains responsible for the child's authorized effects and lifecycle unless the dispatch explicitly transfers that responsibility to another controller.

Anatomy of a dispatch

The dispatch seam has the contract's two tiers. The child's standing definition supplies reusable capability, tool, and input expectations. The per-edge request supplies only what this child execution needs:

The slots are an anatomy, not a demand for formality. “Investigate this and tell me what you find” may be an adequate prose contract for cheap, inspectable work. Rigor rises with ambiguity, downstream consequence, and the cost of asking again.

One slot escapes that informality clause. The executor cannot go unresolved: some model at some effort tier runs the child, and what the author can omit is only the decision. Left unstated, the runtime resolves the slot, and the standing resolution is inheritance — the child runs on the parent's model and effort. That default is a real cost and behavior dependency, not a neutral omission: the parent's tier was chosen for the parent's task, and the child inherits its price and its dispositions with no one having judged the fit. The packing checklist below already carries the test — omission is valid only when the default is correct, not probable — and the executor is that rule's sharpest instance, because the inherited value leaves no trace in the child's window: the one dispatch input that cannot be audited by reading the context it shaped.

Packing the child's world

For each candidate input, ask: who decides whether this enters the child's window—the author now, the child at runtime, or the harness?

• Verbatim — guaranteed admission; use for load-bearing material the child cannot safely recover or infer.
• By reference — delegated admission; the child decides whether to follow a resolvable pointer at runtime.
• Inherited or ambient — runtime admission; count it, name the dependency, and account for drift even though the request did not carry the bytes.
• Omitted as derivable — no delivery; valid only when the child's default assumption will be correct, not merely probable.

Under-packing encourages confident guessing. Over-packing recreates in the child the context pressure the new execution could have relieved. Lazy packing is appropriate only when a check or cheap follow-up can expose starvation.

Parallel fan-out

Fan-out is the parallel edge taken N times from one parent, not a new kind of edge. Per edge, nothing changes: each of the N dispatches carries the full anatomy — its own goal, its own packed world, its own executor resolution — so the contract multiplies with the edge count. What can be authored once and delivered N times is the payload, never the edge.

What N adds beyond N copies is one point of convergence: when the edges join, their returns meet at a single seam in the parent. That seam is where fan-out's design weight sits, and it is owned elsewhere — shaping the one-to-many payload is the the travelling declared-shape contract specialization's broadcast leg (where the build-once economics live), merging many returns into one is its aggregation leg, and when the children are verifiers whose verdicts must combine, N verifiers when a clause won't mechanize — answer voting vs. judge panels; bounded by error correlation owns the vote and its correlated-error bound. This node contributes the topology: N edges out, one seam back.

The trade is stated descriptively: aggregate tokens rise with N while wall-clock falls from the sum of the children toward the slowest of them, and exploration widens at the price of N standing-definition boots. Whether a given N clears the trade is the The Context Economy's arithmetic and the wielding pattern's call.

• A deterministic tool call is not LLM dispatch: a tool receives an operation and arguments but does not create another LLM execution.
• A human gate is a contracted control-flow seam, not a child LLM edge.
• An in-context submodule may help decompose instructions without creating a distinct execution; it belongs to workflow decomposition, not this primitive.
• The primitive does not require a return, a cold start, parallel execution, or a particular native recursion depth.
• Recursive capability does not grant unlimited authority. Token, time, concurrency, and effect budgets remain workflow concerns.

• Context offload can route a working set through a child's window.
• Workflow decomposition can realize one bounded component as a child.
• A fresh child resets context momentum; this is useful for recovery and independent trials, but it also discards useful resident state unless the dispatch reconstructs it.
• Fire-and-forget designs need lifecycle and effect ownership even though they need no return contract.

This is a structural model rather than an empirical claim. It succeeds if serial calls, parallel fan-out, recursive workers, inherited-context runtimes, and fire-and-forget tasks can all be described as variations of one edge without inventing contradictory dispatch anatomies.

One clause is empirical rather than structural: the executor slot's standing default (unstated → inherited from the parent). Its grounding is the 2026-07-16 exemplar-repo intake, where the inheritance trap — an omitted tier silently inheriting the expensive parent — was documented as deployed practice, not hypothesized; the clause stays runtime-anonymous by ruling (2026-08-03, live grilling): the anatomy names the slot, never a vendor. A mainstream runtime that resolves an unstated executor another way — a fixed cheap tier, a mandatory declaration — would demote "standing default" to "one common resolution" without touching the anatomy.

• Sibling primitive: The Contract, which governs expectations at this and other seams. Historical rationale: ADR 0008.
• Wielded for context by Subagent Offload.
• Wielded for complexity by partition a workflow into bounded responsibilities; realization may be code, tools, in-context modules, or child LLM executions.
• Fresh executions support isolated child executions for TDD and controlled comparison and tactical validate at the return seam; re-dispatch over repair; bounded autonomy — the contract keystone, applied.
• Context and return costs are priced by The Context Economy.

Command (Gang of Four) and Scatter-Gather (Hohpe & Woolf, Enterprise Integration Patterns): a request reified as an object that can be issued, queued, and routed, and a fan-out whose replies rejoin at a single seam.

• Lifecycle vocabulary: background work shared by fire-and-forget dispatch and external queues lacks a common name and boundary.
• Contract relationship: the exact foundation-level relationship between the contract and recursive dispatch remains unsettled; neither currently subsumes the other.