Architecture pattern
Harness composition and subagent delegation
A harness can increasingly delegate work to isolated child agents, other harness processes, or protocol-mediated children. That internal topology is separate from UHP's external client-to-harness execution contract.
Short answer
Section titled “Short answer”Subagent delegation is the runtime pattern in which a parent agent or harness hands a bounded task to one or more child agents with their own context and execution state. Harness composition is the broader descriptive term used by this guide when those children may be separate processes, separately configured agent runtimes, or even different harness products.
Neither term is a UHP protocol primitive. UHP 2026-08-11 standardizes the external contract between a client/product and a server that runs a selected harness. What that harness does internally — including spawning children or invoking another harness — remains implementation behavior.
Product / client │ │ UHP ▼UHP server │ ▼Selected harness (parent) ├── isolated child of the same harness ├── out-of-process child ├── ACP-mediated child └── another harness product (for example Codex or Claude Code)The lower branches are examples of internal composition, not additional UHP hops.
Why this now deserves its own layer
Section titled “Why this now deserves its own layer”Recent upstream harness implementations make the topology explicit enough that “the harness” can no longer always be treated as one monolithic agent loop.
DeepSeek Harness: explicit multi-provider child architecture
Section titled “DeepSeek Harness: explicit multi-provider child architecture”DeepSeek Harness (dsh) provides the clearest current example. Release v0.1.0-rc.8 on 19 August 2026 made Claude Code and Codex subagents installable on demand as Profile Bundles, with non-interactive permission modes and multiple named instances. The current upstream subagent family is broader still:
| DeepSeek Harness child path | What it does |
|---|---|
| In-process spawn | Starts a fresh child inside the dsh runtime |
| In-process fork | Starts a child from the parent’s completed history |
| ACP provider | Starts an out-of-process child over Agent Client Protocol (ACP) |
| Codex provider | Starts a real Codex app-server child |
| Claude Code provider | Starts a real Claude Code child through the official Claude Agent SDK |
| dsh SDK provider | Starts an out-of-process DeepSeek Harness child through its TypeScript SDK |
Multiple named providers can coexist in one context. Codex and Claude Code remain optional bundles rather than dependencies in the default dsh production closure.
This is cross-harness composition in concrete upstream code: one harness can delegate to children implemented through different runtime/provider boundaries.
Hermes: isolated delegation and nested orchestration
Section titled “Hermes: isolated delegation and nested orchestration”Hermes exposes delegate_task, which spawns child agent instances with isolated conversation context, inherited allowed tool access and separate terminal sessions. Parallel batches are supported, and nested delegation is opt-in through an orchestrator role and configurable spawn depth.
Hermes therefore demonstrates another composition style: a parent harness remains the orchestrator while children operate in fresh contexts and return summarized results. The current documentation also distinguishes process-local delegated execution from durable scheduled/background work, so delegation should not be confused with a persistent distributed job system.
Pi: extension-level subprocess delegation
Section titled “Pi: extension-level subprocess delegation”Pi ships a documented Subagent Example extension at v0.84.3. Each child runs as a separate pi process with an isolated context window. The example supports single-agent execution, parallel batches and sequential chains, with usage accounting and abort propagation.
The maturity boundary matters: this is a shipped example extension demonstrating the pattern, not evidence that UHP, ACP or another interoperability protocol is required by Pi’s core runtime.
Composition dimensions
Section titled “Composition dimensions”The implementations above show that “subagent” is not one transport or one protocol. Useful dimensions include:
| Dimension | Common choices |
|---|---|
| Process topology | Same process, child process, remote process/service |
| Runtime identity | Same harness family, differently configured instance, different harness product |
| Context model | Fresh context, forked history, explicitly passed task/context |
| Delegation transport | Internal API, SDK/process bridge, ACP or another protocol |
| Scheduling | Single child, parallel fan-out, sequential chain, nested orchestration |
| Capability boundary | Inherited tools, restricted child tools, provider-specific permissions |
| Result model | Final summary, structured result, streamed progress, persisted child session |
A system can combine several choices. “Multi-agent” alone therefore says little about interoperability unless the child boundary and lifecycle are identified.
Where UHP stops
Section titled “Where UHP stops”UHP’s role remains outside this internal topology. A UHP client selects a configured harness and receives a standard task/session/file/event lifecycle from the UHP server. The current specification does not define:
- how many child agents a harness may spawn;
- whether children share or fork context;
- which child protocol or SDK is used;
- how nested-agent budgets or concurrency trees are represented;
- whether a child is another instance of the same harness or a different product;
- how internal child sessions map to the externally visible UHP session.
That separation is useful. A server can preserve one stable UHP contract even as the selected harness changes its internal orchestration strategy.
ACP can be an inner boundary without becoming UHP
Section titled “ACP can be an inner boundary without becoming UHP”DeepSeek Harness provides concrete evidence that ACP can be used inside a harness composition: its subagent-acp provider starts an out-of-process child over ACP. Separately, HarnessRouter can run DeepSeek Harness as a UHP backend.
Those facts must not be collapsed into a protocol claim. A UHP request routed through HarnessRouter to dsh does not imply that ACP is part of UHP, that every dsh task uses ACP, or that HarnessRouter’s UHP implementation depends on ACP. ACP is one possible internal child boundary selected by the harness.
See UHP vs ACP for the protocol-level comparison.
Adoption and conformance boundary
Section titled “Adoption and conformance boundary”UHP conformance evaluates the server-visible UHP behavior. Internal child topology can affect whether the implementation ultimately behaves correctly, but the current 52-check suite does not standardize or certify the harness’s internal orchestration graph.
Why the pattern matters for harness engineering
Section titled “Why the pattern matters for harness engineering”Harness composition changes several practical design questions:
- Context isolation: delegated children can protect the parent context from large intermediate traces.
- Model specialization: workers can use different models or configurations from the parent planner.
- Capability control: a child can receive a narrower tool/permission surface.
- Failure semantics: child cancellation, timeout, crash and partial-result behavior need explicit handling.
- Auditability: observability must distinguish parent work from child work and preserve causal relationships.
- Interoperability boundaries: protocols such as ACP may appear inside the harness while UHP remains the external execution contract.
These concerns are implementation architecture today, not a new UHP conformance class.
Related pages
Section titled “Related pages”Read DeepSeek Harness for the concrete cross-harness implementation, Hermes and Pi for other harnesses, UHP vs ACP for the protocol boundary, UHP vs ATIF for whole-run trajectory interchange, and UHP architecture for the normative Client/Server/Harness model.