Q: Kelly Sub-Agent Spawn Protocol — What's Enforced vs What's Assumed?

Short answer: Kelly's sub-agent spawning is documented as a command (subagents spawn) with RALPH failure handling, but critical operational behaviors — timeout enforcement, parent-death cleanup, context handoff completeness, result durability — are assumed rather than enforced. SuperAda's lobster-pipelines (typed JSON envelope + resumable approval gates) are a directly relevant alternative that addresses these exact gaps.

Context

Kelly's multi-agent architecture (kelly-handbook-ch7-multi-agent) uses the subagents tool to spawn independent worker agents. The Router (main agent) spawns labeled sub-agents with task descriptions and an output directory; sub-agents run independently and report back when complete. This is the core execution primitive of the factory.

The RALPH protocol (ralph-protocol) handles sub-agent failures (retry once, escalate on second failure). But RALPH covers failure after spawn — it doesn't cover the operational lifecycle questions that affect reliability at scale.

What the KB Has on Spawn Behavior

From kelly-handbook-ch7-multi-agent and kelly-factory-overview:

The Spawn Primitive

  • subagents spawn creates a labeled sub-agent with task description and output directory
  • Sub-agents work in parallel — three simultaneous research agents = 5x speedup vs sequential
  • Sub-agents are ephemeral — run to completion and die
  • Parent (Router) maintains context via sessions_yield

RALPH Protocol

  • Any sub-agent failure → retry once
  • Same failure twice → escalate immediately
  • Three failures → mandatory escalation with structured diagnostic
  • Unrecoverable → immediate escalation with operator decision requested

Quality Gate Before Marking Complete

Minimal gate before marking task complete: output file exists, file is non-empty, content addresses original request.

What's NOT Documented

The gap is everything RALPH doesn't cover:

What's Missing

1. Sub-Agent Timeout Enforcement

Kelly's spawn has no documented maximum runtime. What happens if a sub-agent doesn't complete?
- Is there a timeout after which the Router kills and re-assigns?
- Does the heartbeat mechanism detect stuck sub-agents, or only the main agent's heartbeat?
- The kelly-factory-overview mentions heartbeat as agent liveness detection, but doesn't specify whether sub-agents are included in this check

Kelly vs Gas Town gap analysis rated GUPP's explicit hook enforcement (timeout-based) as a medium-high adoption priority — suggesting the current Kelly model lacks hard timeout enforcement.

2. Parent-Death Behavior

What happens to spawned sub-agents when the parent (Router) session dies?
- Does the sub-agent continue running to completion independently?
- Does it receive a termination signal?
- Does its output get lost if no one is listening?

Kelly's sessions_yield model (parent yields while sub-agent executes, parent resumes when complete) implies the parent stays alive and listening. But if the parent process itself dies (gateway restart, crash), what happens to orphaned sub-agents?

SuperAda's lobster-pipelines address this with typed JSON envelopes — result persistence is explicit, not a side effect of parent being alive.

3. Context-Complete Handoff Standard

SuperAda v3's Rule 1: delegation must be context-complete — the assignee must have everything needed to act without follow-up questions. Kelly's spawn pattern includes a task description and output directory, but:
- What's the minimum context a sub-agent must receive before being considered properly spawned?
- If a sub-agent asks clarifying questions — is that a spawn quality failure (should have refused the task) or normal behavior?
- Is there a documented template for what a spawn instruction must contain?

4. Result Durability

Sub-agents write results to files in their output directory. But:
- Is the result file written atomically, or can a partially-written file be read if the sub-agent dies mid-write?
- Is there a "result ready" signal the parent waits for, or does the parent just poll for file existence?
- The minimal quality gate (file exists + non-empty + addresses request) is post-hoc — what ensures the file is actually complete when read?

SuperAda's lobster-pipelines use a typed envelope with explicit status: done fields — result readiness is structural, not inferred from file presence.

5. Sub-Agent vs sessions_yield vs Cron Separation

kelly-factory-overview states the principle: tasks that need reasoning belong in agent sessions; tasks that don't belong in cron/scheduled automation. But:
- When does a task go from "sub-agent with sessions_yield" to "cron job"?
- Are spawned sub-agents subject to the same reasoning/automation separation?
- If a sub-agent spawns a grandchild sub-agent, who monitors it — the parent, the Router, or no one?

6. Grandchild Sub-Agent Visibility

Kelly's documented pattern is Router → lead agent → sub-agent. What if a lead agent (research-lead) spawns its own sub-agents (grandchildren of Router)?
- Does the Router have visibility into grandchild state?
- Can the Router kill a grandchild sub-agent, or only the parent lead agent?
- Does RALPH apply to grandchildren, or only first-level sub-agents?

7. Spawn vs sessions_yield Tradeoffs

Both sessions_yield (parent yields control to delegate) and subagents spawn (spawn independent worker) are available. The KB documents them as distinct tools but doesn't specify when to use which:
- When is yield appropriate vs spawn?
- Does sessions_yield block the parent for the full duration, and is that acceptable for long-running tasks?
- If both could handle a task, which is preferred and why?

Proposed Research Path

  1. Check the Kelly handbook for spawn lifecycle details — kelly-handbook-ch7-multi-agent.md may have spawn timeout or cleanup behavior not yet extracted
  2. Check the operator's actual AGENTS.md — actual spawn behavior, timeout settings, or cleanup rules may be documented there
  3. Review SuperAda's lobster-pipelines — the typed JSON envelope pattern is a direct solution to result durability and resumable handoff gaps
  4. Cross-reference GUPP autonomous continuation — q-gupp-vs-kelly-autonomous-continuation notes Kelly should add explicit timeout enforcement as a lightweight GUPP approximation