Skip to content

Subagent

pawaca edited this page Aug 30, 2026 · 1 revision

Subagent

Not implemented. Edge has session fork but not agent delegation.

Upstream reference: Subagent

What Upstream Provides

SubagentRuntime (ctx.subagents) enables agents to delegate work to child agents. It supports two delegation patterns:

  • One-shot runs — a parent spawns a child that executes once and returns structured output. Provider-based: multiple backends (spawn, fork, ACP) coexist.
  • Continuable children — persistent child sessions with FIFO inbox, cold recovery, and lifecycle management. The parent can follow up, interrupt, or receive reports from the child.

Key capabilities: depth-limited delegation, tool filtering per child, per-child persona, structured output schema, tree-scoped cancellation, and three-tier child enumeration (live → cache → persistence).

Current Edge State

Not Implemented SubagentRuntime is not installed. The apiproxy returns stubs:

  • subagents.list → empty array with parentAvailable: false
  • subagents.history, subagents.prompt, subagents.interruptunsupported

What Edge does have

Edge has session fork (forkSession()) which creates a child session from a parent's event prefix. This preserves parentSession lineage and copies the model selection, cwd, and balanced turn history. However, session fork is conversation branching — the child runs independently with no delegation contract, no structured output, no parent notification, and no lifecycle coordination.

Cloudflare Enablers

Approach How Plan Complexity
DO-internal subagent Multiple Agent instances in one cordis Context. The existing AgentRegistry already supports multiple agents. Install SubagentRuntime with an in-process fork provider. Free Medium — need to verify inject requirements and concurrent turn management within a single DO
DO-to-DO delegation Parent DO spawns a child session in the same or a new DO via internal fetch(). Child runs its own agent loop. Results communicated via session events or KV. Free High — need cross-DO coordination protocol, no shared cordis Context
Container-isolated subagent Child agent runs in a Cloudflare Container with full Linux capabilities. Parent DO coordinates via Container API. Paid (Enterprise/beta) Very high — different runtime, needs custom provider

The most viable path is DO-internal subagent: the upstream SubagentRuntime is a cordis plugin with an in-process fork provider. If its inject dependencies are satisfiable, it could be installed directly — Edge's AgentRegistry already manages multiple agent instances, and the existing session fork infrastructure (forkSession()) provides the seed event mechanism.

Architecture Summary

Component Status Edge Code
SubagentRuntime Missing Not installed
Session fork Reuse forkSession() — conversation branching only
Subagent apiproxy Stub Returns empty/unsupported
Client subagent UI Reuse Included in 33-plugin bundle but no server provider

TODO

Evaluate DO-internal SubagentRuntime installation. Check SubagentRuntime's inject requirements. The in-process fork provider may need ctx.subprocess or ctx.jobs — if so, a minimal stub or Edge-owned fork-only provider could satisfy the contract. The key question is whether one-shot delegation can work within a single DO's execution time limits (30s free, 30min paid).

Evaluate relationship with Background Jobs. Continuable subagents depend on ctx.jobs for lifecycle management. If Background Jobs (#95) is implemented first, continuable subagent support may follow naturally.

English

中文

Clone this wiki locally