FIELD NOTE / 2026.10.024 MIN READ / 5 SOURCES

Side Quests and Subagents: Delegation Patterns for Complex Goals

Subagents work like side quests when delegation is bounded: specialists receive a clear objective, limited tools, relevant context, and a defined return contract to the coordinating agent.

Subagents should exist to isolate a real specialty

OpenAI’s orchestration guidance recommends adding specialists when they materially improve capability isolation, policy isolation, prompt clarity, or trace legibility. [1] That is a strong filter for subagents. A side quest should not exist because multi-agent diagrams look sophisticated. It should own a bounded job such as source verification, code review, itinerary optimization, or tone editing that benefits from a different tool set or instruction contract. Otherwise the delegation layer creates more coordination cost than value.

Delegation should buy separation

A subagent earns its existence when isolating the task makes the overall system easier to reason about.

Dynamic delegation fits tasks whose subtasks emerge during work

Anthropic’s orchestrator-workers pattern is useful when the subtasks cannot be predicted in advance and must be created based on the input. [2] This makes subagents appropriate for open-ended missions such as researching a market or modifying an unfamiliar codebase. The orchestrator can spawn targeted workers after discovering what the mission requires. In a gamified interface, these become visible side quests that support the main objective without replacing it.

Multi-agent systems are compound systems with interface costs

Berkeley’s compound-AI framing reminds us that performance emerges from interactions among components, not from one model alone. [3] Subagents therefore need explicit interfaces: task schema, context packet, allowed tools, expected output, confidence signals, and error format. Passing an unstructured conversation blob to every worker is easy but can create inconsistent assumptions and unnecessary context. Delegation becomes reliable when it resembles software composition.

The contract matters more than the character name

A “Research Scout” persona is useful only if its inputs, outputs, and authority are actually bounded.

Manager and handoff patterns create different user experiences

OpenAI’s practical guide describes manager-style systems, where a central agent calls specialists, and decentralized systems, where agents hand control to one another. [4] For many motivational products, the manager pattern preserves continuity: the coach remains the coach while specialists work behind the scenes. True handoffs should be reserved for cases where a different specialist really needs to own the conversation or approval boundary.

Delegation quality should be visible in traces and evals

Agent evaluations can test whether handoffs and tool choices happened when they should. [5] Subagent systems should add criteria for duplicate work, missing context, inconsistent assumptions, synthesis quality, and unnecessary delegation. More workers can increase the chance that one produces a strong insight while also increasing coordination failures. Teams need end-to-end metrics rather than celebrating individual worker outputs.

Measure synthesis, not just specialist quality

The main task succeeds only if useful subagent work is correctly incorporated into the final result.

Context packets should be minimal but sufficient

A worker needs the objective, relevant constraints, the evidence it should use, and the format in which to return results. It does not necessarily need the entire conversation or all user memory. Narrow context reduces privacy exposure and prevents unrelated instructions from leaking between roles. It also makes the worker easier to test because its task is reproducible. The orchestrator should curate context rather than forwarding everything by default.

Side quests should have budgets and stop conditions

A subagent that keeps exploring can consume time and tokens without changing the main decision. Give each delegated task a budget, success criterion, and return deadline. Optional exploration should explain its expected value. If the worker discovers a new branch, it can propose another quest rather than recursively spawning unlimited agents. This protects both operational cost and user attention.

Parallelism needs a ceiling

The ability to delegate widely is not a reason to turn every uncertainty into another agent.

The orchestrator must preserve the user’s original goal

Subagents optimize local objectives, so the coordinator must check their outputs against the global mission and user constraints. A worker may find the cheapest option when the user prioritizes privacy, or the fastest route when accessibility matters more. Synthesis is therefore a value-preservation step, not just text assembly. The best multi-agent experience feels coherent because specialists expand capability while one clear layer remains accountable for the user’s actual goal.

Subagents also need a clear rule for what they are allowed to remember after their side quest ends. A temporary worker may need sensitive documents or private preferences to complete one bounded task, but that does not imply those details should enter global memory or be exposed to other workers. The orchestrator should control both context distribution and retention. This is especially important when gamified systems use named specialist characters, because a friendly persona can make information sharing feel more casual than the underlying data flow really is. The safest default is task-local context with explicit promotion of only the facts or artifacts the main mission truly needs.

A useful delegation record should also capture provenance: which worker produced each claim or artifact, which evidence it used, and whether the coordinator modified the result during synthesis. This makes later correction much easier because the system can revisit the responsible branch instead of reopening the entire mission. Provenance also helps users understand why two specialists disagreed and gives evaluators a clean way to identify whether failure originated in delegation, worker execution, or final synthesis.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.