Heavy Agent

A task needs a lot of context to do well — detailed instructions, domain expertise, large reference material. If the orchestrator carries that weight in its own window, its context fills up and a long workflow degrades or dies. The orchestrator's window becomes the bottleneck for work it isn't even doing itself.

The move: bake the heavy context — the extensive instructions and expertise a task needs — into an agent definition, and have the orchestrator invoke it by type. Dispatching by type is cheap: the orchestrator references the agent, it doesn't load it. The heavy instructions — and whatever the agent reads or reasons through at runtime — materialize in the subagent's own window, which the orchestrator never pays for. The orchestrator dispatches and waits; the weight lives elsewhere.

The who-axis observables are the Subagent Offload's (Use when): the work is separable, and the working set dwarfs its conclusion. What types a task to this specialization rather than to the branch baseline is where the weight was put.

This is subagent offload specialized by authored weight. Plain subagent offload (e.g. Parallel Audit Investigation) offloads mostly runtime context — files swept, discarded after the answer. A heavy agent is the case where the defining weight is baked into the agent file: deep instructions, a domain rubric, a large reference. "Heavy" names the authored instruction set.

The who-axis contraindications are the Subagent Offload's (Avoid when) and they close this specialization with it; one more closes the specialization alone, and a scope boundary marks where the pattern stops rather than where it is wrong.

• The weight is runtime, not authored. Nothing is baked into a definition — the material is swept and discarded per run. The branch baseline already covers it; the Explore agent is the parent's example, not this node's case.

Heavy agent ends at the offload: it offloads required context, full stop. The orchestrator doesn't load the context, doesn't carry it at runtime, doesn't bring it into its window — it just dispatches, and the agent gets a context budget the orchestrator never had to pay. That is the whole pattern. What comes back, how it's shaped, and whether it's checked are separate concerns owned by neighbor patterns (the contract, context envelope, validated seam). Heavy agent names them as the boundary; it does not reach into them.

Isolation-as-price and the per-dispatch re-boot are the Subagent Offload's forces; both bind here unchanged, and their developed per-child form is Consequences and tradeoffs below. What authored weight adds is a pressure the branch baseline's runtime-heavy case never carries: baked-in expertise is a standing surface, not a per-run cost. The same authoring that makes an agent worth invoking by type also makes it something that has to be kept correct — and the orchestrator, which never loads the definition, never sees it age.

The weight is the total context cost to achieve the task — not just the authored instructions but the tokens burned getting to the goal (reading, exploring, intermediate reasoning). All of it is borne in the subagent's window. The authored heaviness is what makes it a heavy agent specifically; offloading the runtime cost too is inherited from subagent offload.

• The orchestrator holds a lean context. It knows the agent type and a narrow task; it does not hold the agent's instructions or working material.
• The dispatch carries everything the isolated agent will need — it can't see the orchestrator's window.
• The heavy agent loads its baked-in weight plus whatever it reads at runtime, all in its own window, and does the work.
• The return crosses back — the one cost the orchestrator can't defer. Keeping it smaller than the context it replaced is the job of the neighbor patterns, not this one.

The branch procedure holds unchanged — name the separable unit, author the function pointer, pack the dispatch by the primitive's checklist, declare what comes back (Subagent Offload, Application). Applying it as a heavy agent is one decision: the weight goes in the definition, not in the dispatch. Instructions, rubric, and reference are authored once into the agent file; the orchestrator then carries the type name and a narrow task, and every invocation materializes the weight in the subagent's window. Pin the executor slot in that same definition — expertise the definition asserts is expertise the definition should price.

• Per-dispatch fixed cost. Every dispatch spins up a fresh agent and re-pays its system prompt / boot context. There's no warm reuse across dispatches — invoke it N times and you pay that baseline N times, plus dispatch latency. Easy to forget when fanning out.
• Isolation cuts both ways (the bigger real impact). The subagent can't see the orchestrator's working context, so you must pack everything it needs into the dispatch prompt (the packing anatomy lives at ../../../../../foundations/llm-dispatch/llm-dispatch.md → Model and claims › Packing the child's world). And the orchestrator can't watch or steer the work mid-flight — it only sees the return. You trade visibility and steerability for the context relief.
• The executor slot bites hardest here. A heavy agent's definition can pin its own model and effort tier — expertise priced deliberately — while silence inherits the orchestrator's tier, price and dispositions unjudged (the slot and its default live at the primitive's dispatch anatomy).
• (Authored-heavy agents specifically:) a baked-in reference can drift out of date — the authored weight is a maintenance burden the orchestrator never sees.
• (Boundary:) the return is the one cost you can't defer; shaping and checking it is the neighbor patterns' job.

The Subagent Offload's checks (Verification), read against authored weight.

• Deterministic — the definition never entered the orchestrator. The orchestrator's transcript carries the agent's type name, the dispatch, and the return; the baked-in instructions, and everything the agent read to reach its answer, appear in the subagent's transcript alone. Invocation by type either referenced the definition or loaded it, and the transcript settles which.
• Probabilistic — packing sufficiency, and the weight's currency. The parent's residue holds: an under-packed dispatch starves an agent that cannot see the orchestrator's window. Authored weight adds one of its own — a baked reference that has drifted produces stale work, and the orchestrator, which never reads the definition, sees only the return.

• The Docs Expert — the docs expert: a large reference baked into the agent; the canonical authored-heavy case.

• Parent — Subagent offload (../subagent-offload.md): dispatch a subagent so its context is never yours. Heavy agent is the specialization where the subagent is heavy by authored design. Parallel Audit Investigation is the parent's runtime-heavy, lightly authored example.
• The later/elsewhere split and the cross-branch rhyme — mapping this node opposite Reference Data as each branch's authored-heavy case — are owned at Cost Relocation (Structure).
• Return neighbors (the boundary, not owned here): the contract / the contract keystone (../../../../../foundations/the-contract-keystone/the-contract-keystone.md) for the return contract; context envelope (../../../distillation/context-envelope.md) for distilling the return; validated seam / re-dispatch (../../../../../verification/validated-seam-redispatch.md) for checking it.
• Pairs with durable state (../../../../../persistence/durable-state.md) when handoff across dispatches must survive.

Facade and Proxy (Gang of Four): a Facade presents a simplified interface over a complex subsystem; a Proxy stands in for a resource and controls access to it. The expert/librarian distinction is that split drawn over context rather than code.