Foundation · 7 of 9
Delegation and reusable skills
Breaking work into pieces is easy. Defining what a child receives, may do, and must return is the real harness contract.
§1
Three devices solve different problems
A plan externalizes intended steps and progress. It may be model-authored, user-authored, or mechanically tracked. A plan does not execute itself and does not necessarily create another model context.
A skill packages repeatable procedure, examples, scripts, or reference material. Loading a skill changes the instructions or resources available to a run. It need not create another agent.
A subagent is a separately scheduled child run. The parent delegates a bounded task; the harness chooses the child’s initial context, model, tools, authority, lifetime, and result path.
These terms name harness conventions, not universal LLM capabilities. Their exact semantics vary by implementation, so a comparison must inspect context inheritance, tool access, authority, and return limits rather than relying on the label. Interpretation
§2
The six-part delegation contract
| Dimension | Choice | Tradeoff | Question to record |
|---|---|---|---|
| Initial context | Fresh, selected, summarized, or forked parent state. | More inheritance preserves continuity but consumes budget and may carry irrelevant assumptions. | Exactly which messages, files, summaries, and instructions crossed? |
| Task prompt | Explicit objective, output contract, boundaries, and evidence requirements. | A vague child prompt makes reconciliation expensive and failure ambiguous. | What observable result counts as done? |
| Tools | Read-only subset, specialized tools, or broader parent capabilities. | Least capability reduces risk; missing capability can block useful work. | Which names are visible and which implementations are callable? |
| Authority | Inherited, reduced, separately approved, or none for side effects. | Child execution must not silently expand the user’s delegation. | Which policy and sandbox govern the child? |
| Result channel | Short answer, structured success or failure report, artifacts, event stream, or shared state. | Large raw returns can consume the parent’s context; summaries can omit decisive evidence. | What returns on success, failure, timeout, or cancellation, and what remains behind a reference? |
| Lifecycle | Join, stream, cancel, retry, time out, or continue independently. | Concurrency adds stale assumptions and conflicting effects. | Who owns cancellation and conflict resolution? |
§3
Fresh context and forked context are different bets
A fresh child starts from an explicit task package. It avoids much of the parent’s conversational debris and makes the delegation boundary auditable. The parent must supply every important constraint and pointer, or the child will rediscover context and may choose a different interpretation.
A forked child begins from some parent context or state snapshot. It can continue with shared vocabulary and recent evidence, but it also inherits token cost, outdated hypotheses, untrusted material, and assumptions that were never meant to become child instructions. “Fork” must be defined: messages, durable session, cache, workspace, credentials, and approvals are separate inheritance questions.
Fresh versus forked describes how the child process begins; selected versus broad describes what the parent puts into it. A practical middle is therefore a fresh child with a selected package: an explicit task, relevant files or artifact references, governing instructions, a result schema, and no unrelated transcript. That selection is itself context management.
§4
The parent remains responsible for reconciliation
Delegation can reduce context pressure by moving exploration into another window, but the parent still needs enough evidence to use the result. A child’s “looks good” is not a substitute for the relevant file, test result, or cited source. Return contracts should preserve conclusions, evidence, uncertainties, changed artifacts, and unresolved risks.
When children work concurrently, their initial views can become stale. Two agents may edit the same file, assume different dependency versions, or make individually reasonable changes that conflict. The harness can reduce collisions through read-only tasks, disjoint working sets, isolated worktrees, ownership records, and an explicit merge/review stage.
Result caps should be intentional. A short result protects the parent’s context but may hide the trail. A useful pattern is a concise inline report plus durable artifacts or source locations the parent can inspect on demand.
§5
Apply the fresh-process test
For work that outlives one context or process, ask whether a fresh runner can recover without trusting one lossy summary. Durable state should let it establish the governing objective, the current state of work, the evidence behind that state, and the next authorized action. Interpretation
01 · Objective
What counts as done?
Preserve the user goal, acceptance criteria, constraints, and the version of the plan or specification that governs the work.
02 · Progress
What changed and why?
Record completed increments, open work, decisions, failures, and any clean checkpoint from which work can safely continue.
03 · Evidence
Where is the exact trail?
Keep tests, diffs, artifacts, source locations, logs, receipts, and unresolved uncertainty inspectable rather than flattened into confidence.
04 · Next action
What may happen next?
Name the next bounded step, current authority, workspace ownership, stop condition, and any approval or coordination still required.
A transcript, a model-visible working set, and project memory are different artifacts. The transcript records interaction. The working set is what the next inference can see. Project memory preserves durable decisions, evidence, and recovery state. A progress note can point into all three, but it should not quietly become all three.
§6
Delegate bounded uncertainty
Good child tasks have a clear object and independent evidence: map a subsystem, reproduce one failure, inspect a set of sources, or review a defined diff. Poor child tasks require constant shared judgment, mutate overlapping state, or hide a key product decision behind “figure it out.”
Skills are preferable when the work is a repeatable procedure in the same context. A plan is preferable when the main need is ordering and progress visibility. A subagent is valuable when a separate context, specialized toolset, or independent line of inquiry saves enough work to justify coordination cost.