@bastani/atomic 0.9.15 → 0.9.16-alpha.1

package/dist/builtin/subagents/README.md

@@ -161,7 +161,7 @@ Workflow invocations receive a stable, non-`default` Intercom group automaticall
 
 ## Where running subagents show up
 
-Foreground runs stream progress in the conversation while they run. Parallel calls keep their grouped task shape in progress and results, and status/control actions can inspect or interrupt retained foreground children.
+Foreground runs stream progress in the conversation while they run. Parallel calls keep their grouped task shape in progress and results, and status/control actions can inspect or interrupt live foreground children.
 
 You can ask naturally:
 
@@ -193,7 +193,7 @@ Use the optional prompt shortcuts below when you want the pattern to be repeatab
 
 Packaged `worker` defaults to forked context when a launch omits `context`; every other builtin runs fresh. Pass `context: "fresh"` when you intentionally want a fresh `worker` run.
 
-Child-safety boundaries are enforced at runtime by typed admission policy. In-process child sessions load bundled extensions through normal discovery. The `subagent` tool may therefore be registered when the child's active tool selection permits it, including the default no-allowlist case; an explicit allowlist may omit it. Tool presence does not grant fanout: fanout is authorized only when the resolved builtin `tools` list includes `subagent`. Typed admission policy lets a non-fanout child use only `list`, `get`, `status`, and `doctor`; delegation, `resume`, and `interrupt` receive the fanout refusal. A management-restricted child is also refused `create`, `update`, and `delete`. The bundled `pi-subagents` skill remains parent-only and is stripped from child prompts, including fanout-authorized children. No admitted child may delegate: launches, `resume`, and `interrupt` are refused for every child regardless of its fanout authorization. Children receive boundary instructions that they are not the parent orchestrator and must complete their assigned task directly. Forked child context filtering also removes parent-only subagent artifacts (including old hidden orchestration-instruction messages, slash/status/control messages, and prior parent `subagent` tool-call/tool-result history) while preserving ordinary prose and unrelated tool calls/results.
+Child-safety boundaries are enforced at runtime by typed admission policy. In-process child sessions load bundled extensions through normal discovery. The `subagent` tool may therefore be registered when the child's active tool selection permits it, including the default no-allowlist case; an explicit allowlist may omit it. Tool presence does not grant fanout: fanout is authorized only when the resolved builtin `tools` list includes `subagent`. Typed admission policy lets a non-fanout child use only `list`, `get`, `status`, and `doctor`; delegation and `interrupt` receive the fanout refusal. A management-restricted child is also refused `create`, `update`, and `delete`. The bundled `pi-subagents` skill remains parent-only and is stripped from child prompts, including fanout-authorized children. No admitted child may delegate or control another child: launches and `interrupt` are refused for every child regardless of its fanout authorization. Children receive boundary instructions that they are not the parent orchestrator and must complete their assigned task directly. Forked child context filtering also removes parent-only subagent artifacts (including old hidden orchestration-instruction messages, slash/status/control messages, and prior parent `subagent` tool-call/tool-result history) while preserving ordinary prose and unrelated tool calls/results.
 
 ## Optional shortcuts
 
@@ -233,12 +233,15 @@ Ask codebase-analyzer to review this plan. If it sees a decision I need to make,
 
 The child can use one dedicated coordination tool:
 
-- `contact_supervisor`: the child contacts the parent/supervisor session that delegated the task. Use `reason: "need_decision"` for blocking decisions or clarification, and `reason: "progress_update"` for short non-blocking updates when a discovery changes the plan. Do not ask for clarification when the only conflict is review-only/no-edit versus progress-writing or artifact-writing instructions; no-edit wins.
+- `contact_supervisor`: the child contacts the parent/supervisor session that delegated the task. Use `reason: "need_decision"` for a blocking decision, `reason: "interview_request"` for structured questions, and `reason: "progress_update"` for a short non-blocking update when a discovery changes the plan. Do not ask for clarification when the only conflict is review-only/no-edit versus progress-writing or artifact-writing instructions; no-edit wins.
 
-Child-side routine completion handoffs are still not expected. With the intercom bridge active, parent-side Atomic sends grouped completion results through `pi-intercom`: one grouped message per foreground parent `subagent` run and one per detached child completion. Intercom-confirmed delivery returns a compact receipt with artifact/session paths; without that confirmation, the normal full output is preserved. Grouped messages include child intercom targets and full child summaries.
-When the companion is enabled and available, the bridge gives eligible children deterministic Intercom identities and coordination tools without connecting them automatically. Parent and child connections remain tool-driven: if a child may need live coordination, the parent model should invoke `intercom({ action: "status" })` before launch, and the child connects when it invokes `contact_supervisor` or `intercom`. Foreground launches and management-only actions do not force Intercom loading or broker startup.
+Child-side routine completion handoffs are still not expected. With the Intercom bridge active, a blocking decision or interview from the exact foreground child ends at the source before broker send or reply-waiter admission. The parent `subagent` call returns the verbatim question, ordered attachments with duplicates preserved, agent identity, terminal run ID, and a dynamic `[TASK_CONTEXT]` handoff. `intercom.ask` does the same only when its resolved target is the launching parent. The parent answers by launching a fresh child with a new run identity and the supervisor answer in its task.
 
-For foreground runs, Intercom uses a targeted probe/reservation before delivery: only the exact live child can claim its message. Atomic then commits detach for that child and waits for its acknowledgement before placing claimed asks, sends, decisions, interviews, and progress updates in the parent's model-visible steering queue, so cancellation between phases cannot surface an orphaned request. Blocking calls remain alive for an exact threaded reply and then resume; fire-and-forget calls create no waiter. The retained child later replaces its detached status and artifacts with the real result. Cancellation/replacement invalidates stale handshakes, duplicate delivery cannot recommit, and unmatched messages retain queued-until-idle behavior.
+For parallel runs, the claim interrupts every active sibling and prevents queued work from starting or requesting authorization. The sibling set, sessions, and worktrees are not retained for continuation. Any follow-up starts fresh SINGLE or PARALLEL children explicitly. `intercom.send`, progress updates, and asks to siblings or other peers retain the exact-child probe/commit detach and ordinary Intercom delivery paths.
+
+With the Intercom bridge active, the parent may load and connect its Intercom runtime before initial child execution to issue the exact child's broker capability. The child connection remains tool-driven. A claimed `contact_supervisor` decision or interview still yields before child send or reply-waiter admission; `intercom.ask` connects the child to resolve both targets.
+
+Parent-side Atomic still sends grouped completion results through Intercom: one grouped message per foreground parent `subagent` run and one per detached child completion. Intercom-confirmed delivery returns a compact receipt with artifact/session paths; without that confirmation, the normal full output is preserved. Grouped messages include child Intercom targets and full child summaries.
 
 If a child appears stalled, needs-attention notices can show up in the parent session with useful next actions, such as checking `subagent({ action: "status" })`, interrupting the run, or nudging the child.
 
@@ -537,6 +540,16 @@ These are the parameters the LLM passes when it calls the `subagent` tool. Most
 ], worktree: true }
 ```
 
+### Sibling execution calls
+
+If one assistant response emits several sibling execution-mode `subagent` calls, Atomic collects the synchronous burst before any child starts and runs it through one indexed parallel set. Each original tool call receives only its own children in source order, and its live result, progress, control, and artifact updates are projected to that same route without sibling data. The TUI redraws the shared run as one aggregate parallel widget rather than retaining one widget per original call. A solitary call keeps its original mode, sequential awaited calls stay independent, and management actions bypass collection. A call that arrives after a child has started still gets the existing in-progress rejection. Prefer one explicit `{ tasks: [...] }` call when you intend parallel work; burst collection handles model-emitted sibling calls.
+
+In a collected burst, a call's top-level `agent` task comes first, followed by its `tasks` array. Duplicates and array order are preserved, and `count` expands in place. The task cap applies after all calls are flattened and counts are expanded, with the same hard maximum of 50. Each call-level `cwd` selects that call's agent-discovery scope and child base directory. A task-level `cwd` stays relative to that base and affects child execution, not agent discovery. This per-origin rule applies only to collected sibling calls; an ordinary explicit `{ tasks: [...] }` call keeps one discovery scope from its top-level `cwd`. Per-call and per-task `group` values also remain attached to their children, and a task-level group wins.
+
+For a collected `worktree: true` burst, every call-level `cwd` must resolve to the same path. That common path becomes the shared worktree root; differing origins reject the burst before launch, and any task-level `cwd` must still resolve to that root. Each projected caller result keeps shared worktree diff text and terminal control guidance while its child results and standard child-output sections remain route-local.
+
+One parallel run also needs one value for each run-wide option. Sibling calls must agree on `concurrency`, `worktree`, `context`, `share`, `control`, `sessionDir`, `maxOutput`, `artifacts`, `includeProgress`, and `agentScope`. If any value differs, Atomic rejects the full burst before launch and names the field instead of mixing settings.
+
 ### Management actions
 
 Agent definitions are not loaded into context by default. Management actions let the LLM discover, inspect, create, update, and delete agents at runtime.
@@ -580,7 +593,7 @@ Agent definitions are not loaded into context by default. Management actions let
 |-------|------|---------|-------------|
 | `agent` | string | - | Agent name for single mode, or target for management actions. |
 | `task` | string | - | Task string for single mode. |
-| `action` | string | - | `list`, `get`, `create`, `update`, `delete`, `status`, `interrupt`, `resume`, or `doctor`. |
+| `action` | string | - | `list`, `get`, `create`, `update`, `delete`, `status`, `interrupt`, or `doctor`. |
 | `config` | object/string | - | Agent config for create/update. |
 | `output` | `string \| false` | agent default | Override single-agent output file. |
 | `outputMode` | `"inline" \| "file-only"` | `inline` | Return saved output inline or as a concise saved-file reference. `file-only` requires an `output` path. |
@@ -611,12 +624,10 @@ Status and control actions:
 subagent({ action: "status" })
 subagent({ action: "status", id: "<run-id>" })
 subagent({ action: "interrupt", id: "<run-id>" })
-subagent({ action: "resume", id: "<run-id>", message: "follow-up question" })
-subagent({ action: "resume", id: "<run-id>", index: 1, message: "follow-up for child 2" })
 subagent({ action: "doctor" })
 ```
 
-`resume` sends the follow-up directly when a child is still reachable. After completion or eviction, it cold-reloads the same canonical child identity from the stored session file. Remembered foreground single or parallel runs can be revived by passing `index` to choose the child; no new OS process is created.
+Completed, interrupted, and parent-question children are terminal for continuation. A prior run ID cannot revive a child or parallel sibling set. Start a fresh subagent call with an explicit context handoff for follow-up work.
 
 ## Worktree isolation
 
@@ -640,7 +651,7 @@ Requirements:
 - the main repository's Husky or populated `.git/hooks` directory is shared through `core.hooksPath`
 - gitignored files matched by `.worktreeinclude` are copied into the worktree
 
-After a worktree parallel step completes, per-agent diff stats are appended to the output and full patch files are written to artifacts. Cleanup forcibly removes each worktree, waits briefly for Git's lock release, and deletes its `worktree-*` branch; the same cleanup runs after post-creation setup failures.
+After a worktree parallel step reaches any terminal result, per-agent diff stats are appended to the output and full patch files are written to artifacts. A parent-directed ask terminally ends the active set, captures its staged and unstaged changes in the same handoff result, and then cleans up every worktree and `worktree-*` branch after a brief Git lock-release wait. The same cleanup runs after post-creation setup failures.
 
 ## Configuration
 
@@ -772,7 +783,7 @@ This is disabled by default. Session data may contain source code, paths, enviro
 
 ## Delegation boundary
 
-Delegation is exactly one level deep, and nothing configures it. A top-level session — main chat or a workflow stage — may call `subagent`. A session that was itself admitted as a subagent child may not: every launch, `resume`, and `interrupt` it attempts is refused with guidance to complete its assigned task directly. The observing actions `list`, `get`, `status`, and `doctor` stay available to a child.
+Delegation is exactly one level deep, and nothing configures it. A top-level session — main chat or a workflow stage — may call `subagent`. A session that was itself admitted as a subagent child may not: every launch and `interrupt` it attempts is refused with guidance to complete its assigned task directly. The observing actions `list`, `get`, `status`, and `doctor` stay available to a child.
 
 There is no configuration option, agent frontmatter field, or tool parameter for the delegation level. The rule is enforced twice: the subagent executor refuses a child before any run starts, and the Rust `SubagentControl` admission door refuses a child deeper than the single permitted level. Admitted depth is typed admission state and is not inherited through an environment variable.
 

package/dist/builtin/subagents/agents/worker.md

@@ -20,9 +20,9 @@ Treat an approved handoff or execution plan as the contract. Inspect inherited c
 
 ## Decision and escalation contract
 
-Do not silently make a new product, architecture, or scope decision. When implementation reveals an unapproved decision required to continue safely, pause and use the live coordination route supplied at runtime. Use `contact_supervisor` with `reason: "need_decision"` and stay alive for the reply. Use `reason: "progress_update"` only for a concise, non-blocking update when helpful or explicitly requested. Fall back to `intercom` only when `contact_supervisor` is unavailable.
+Do not silently make a new product, architecture, or scope decision. When implementation reveals an unapproved decision required to continue safely, use the live coordination route supplied at runtime. Use `contact_supervisor` with `reason: "need_decision"`; a claimed request ends this child and gives the supervisor a fresh-subagent handoff, so do not wait for a reply in this run. Use `reason: "progress_update"` only for a concise, non-blocking update when helpful or explicitly requested. Fall back to `intercom` only when `contact_supervisor` is unavailable.
 
-Do not end with a question requiring the supervisor to choose before work can continue. Do not send routine completion handoffs; return the normal task result when coordination is unnecessary. If you sent a blocked or progress update through `contact_supervisor`, keep it short and still provide the full structured result.
+Do not end with a question requiring the supervisor to choose before work can continue. Do not send routine completion handoffs; return the normal task result when coordination is unnecessary. If you sent a progress update through `contact_supervisor`, keep it short and still provide the full structured result.
 
 ## Work and validation
 

package/dist/builtin/subagents/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/subagents",
-  "version": "0.9.15",
+  "version": "0.9.16-alpha.1",
   "private": true,
   "description": "Atomic extension for delegating tasks to subagents with parallel execution. Fork of: https://github.com/nicobailon/pi-subagents",
   "contributors": [

package/dist/builtin/subagents/skills/subagent/SKILL.md

@@ -251,24 +251,17 @@ Avoid duplicate output paths in parallel tasks. Concurrent children should not w
 Concurrent writers conflict. `code-simplifier` and `debugger` change files. Do not run two writers in parallel against the same worktree unless you isolate them with `worktree: true`.
 
 
-### Foreground execution and resume
+### Foreground execution and fresh follow-ups
 
 All subagent execution runs in the foreground and returns its result to the parent call. Parallel tasks may still run concurrently within one foreground invocation, and forked context still creates branched child sessions.
 
-Use `resume` for a follow-up on a retained child:
+Completed, interrupted, and parent-question children are terminal for continuation. Do not address a prior child or sibling set by run ID. Start follow-up work with the normal launch form and an explicit handoff:
 
 ```typescript
-subagent({ action: "resume", id: "run-id", message: "Follow up on this point." })
-subagent({ action: "resume", id: "run-id", index: 1, message: "Continue reviewer 2." })
+subagent({ agent: "worker", task: "[TASK_CONTEXT] Continue with this supervisor answer: ..." })
 ```
 
-Resume behavior:
-
-- If a child is still running and reachable, `resume` sends the follow-up through its intercom route when available.
-- Completed foreground single and parallel runs can be revived by `index` while their run metadata remains in extension state.
-- A revived child starts a new in-process attempt from its persisted session file.
-- Multi-child runs require `index` unless only one child is selectable.
-- If the chosen child has no persisted `.jsonl` session file, resume fails and reports that directly.
+A parent-ask handoff supplies the original question, ordered attachments, previous agent identity, and dynamic task context. The fresh launch receives a new run identity.
 
 Use diagnostics when setup or child startup looks wrong:
 
@@ -280,7 +273,7 @@ Humans can use `/subagents-doctor` for the same read-only report. It checks runt
 
 ### Subagent control
 
-Subagent control is the runtime visibility and intervention layer for delegated runs. It is separate from lifecycle status. Lifecycle status says whether a child is `queued`, `running`, `paused`, `complete`, or `failed`. Activity reporting is factual: it tracks the last observed activity time and the current tool when known. It does not pretend to know that a child is truly stuck.
+Subagent control is the runtime visibility and intervention layer for delegated runs. Lifecycle status distinguishes queued and running children from terminal completed, failed, or interrupted results. Activity reporting is factual: it tracks the last observed activity time and the current tool when known. It does not pretend to know that a child is truly stuck.
 
 Default behavior is intentionally conservative. When no activity has been observed past the configured threshold, the run emits a `needs_attention` control event. Foreground runs push this as a `subagent:control-event` event, and notification-worthy control events are inserted into the visible transcript so both the user and the parent agent can see them, with a proactive hint plus concrete `nudge`, `status`, and `interrupt` options. Visible notifications fire once per child run and attention state.
 
@@ -296,7 +289,7 @@ Pass `id` when targeting a specific controllable run:
 subagent({ action: "interrupt", id: "abc123" })
 ```
 
-A soft interrupt cancels the current child turn and leaves the run paused. It does not mean the delegated task succeeded or failed. After an interrupt, decide the next explicit action: resume with clearer instructions, replace the task, ask the user, or stop the workflow.
+A soft interrupt cancels the current child turn and terminally records the child as interrupted. It does not mean the delegated task succeeded. Decide the next explicit action: launch a fresh child with the relevant task context, replace the task, ask the user, or stop the workflow.
 
 Per-run control thresholds can be overridden when a task legitimately runs without observable output for longer than usual:
 
@@ -339,7 +332,7 @@ subagent({
 
 Atomic subagents work without intercom. When Atomic's bundled intercom companion or upstream `pi-intercom` is installed and enabled, the bridge can give eligible child agents a private coordination tool back to the parent session without connecting either session automatically. If a child may need live coordination, invoke `intercom({ action: "status" })` in the parent before launching it; the child connects when it first invokes `contact_supervisor` or `intercom`.
 
-The builtin `debugger` and `worker` agents declare `intercom` and `contact_supervisor`. With an active bridge route, they can send progress or pause to ask the parent for a decision. Other builtin specialists finish their pass and return without live coordination; use a custom agent with bridge tools when another role needs that ability.
+The builtin `debugger` and `worker` agents declare `intercom` and `contact_supervisor`. With an active bridge route, they can send progress or terminally hand a parent-directed question back to the supervisor. Other builtin specialists finish their pass and return without live coordination; use a custom agent with bridge tools when another role needs that ability.
 
 Custom agents that do have the bridge tool can ask the parent for a decision:
 
@@ -461,8 +454,8 @@ If a prompt-template extension is installed, additional user prompt templates ca
 
 - **Forking requires a persisted parent session.** If the current session does not have a persisted session file, forked runs fail.
 - **Forked runs inherit parent history.** They are branched threads, not fresh filtered contexts. Use fresh context for adversarial review unless the user explicitly asks for forked context.
-- **Delegation is one level deep and not configurable.** A subagent cannot call `subagent`: every launch, `resume`, and `interrupt` from inside a child is refused. Only `list`, `get`, `status`, and `doctor` stay available to a child.
-- **Attention signals are not lifecycle state.** `needs_attention` means no activity has been observed past the configured threshold. `paused` means the child turn was intentionally interrupted or is awaiting direction; it is not the same as `failed`.
+- **Delegation is one level deep and not configurable.** A subagent cannot call `subagent`: every launch and `interrupt` from inside a child is refused. Only `list`, `get`, `status`, and `doctor` stay available to a child.
+- **Attention signals are not lifecycle state.** `needs_attention` means no activity has been observed past the configured threshold. `interrupted` means the child turn ended before completion; it is terminal for continuation and is not the same as `failed`.
 - **Builtin coordination varies by agent.** `debugger` and `worker` declare `intercom` and `contact_supervisor`; the other builtin specialists do not. For agents without bridge tools, decide the task up front or use a custom agent when mid-run coordination is required.
 - **Intercom asks are blocking.** A session can only maintain one pending outbound ask wait state at a time.
 - **Keep conversational authority clear.** Advisory specialists should not silently become second decision-makers.
@@ -550,7 +543,7 @@ For complex or risky changes, increase review and validation fanout when user in
 
 For very large work, split into serial milestones instead of launching a swarm of writers. Each milestone gets one writer, a validation contract, fresh-context review, a fix pass, and parent approval before the next milestone starts. Use parallel subagents inside a milestone for read-only context, research, and review only.
 
-Keep orchestration authority in the parent session. Child subagents cannot launch more subagents or run their own orchestration loops: delegation is one level deep and nothing configures it. This skill is parent-only and is stripped from every child prompt. A child may still have the `subagent` extension tool registered, because bundled extensions load through normal discovery; registration is not authority. Typed admission policy lets a child use only `list`, `get`, `status`, and `doctor`, and refuses delegation, `resume`, and `interrupt`. Spawned children also do not receive parent-only status/control/slash messages or prior parent `subagent` tool-call/tool-result artifacts, and child context filtering strips old hidden orchestration-instruction messages when they appear in inherited history. Every child also receives a boundary instruction that says the parent owns orchestration, that the `subagent` tool refuses every launch, `resume`, and `interrupt` from inside a subagent, and that writer children must call real edit/write tools instead of printing pseudo tool calls. Pass children concrete role-specific work instead.
+Keep orchestration authority in the parent session. Child subagents cannot launch more subagents or run their own orchestration loops: delegation is one level deep and nothing configures it. This skill is parent-only and is stripped from every child prompt. A child may still have the `subagent` extension tool registered, because bundled extensions load through normal discovery; registration is not authority. Typed admission policy lets a child use only `list`, `get`, `status`, and `doctor`, and refuses delegation and `interrupt`. Spawned children also do not receive parent-only status/control/slash messages or prior parent `subagent` tool-call/tool-result artifacts, and child context filtering strips old hidden orchestration-instruction messages when they appear in inherited history. Every child also receives a boundary instruction that says the parent owns orchestration, that the `subagent` tool refuses every launch and `interrupt` from inside a subagent, and that writer children must call real edit/write tools instead of printing pseudo tool calls. Pass children concrete role-specific work instead.
 
 1. Clarify only when needed. Use existing context first; gather missing code or research context selectively, then ask only unresolved questions that materially affect scope, completion criteria, constraints, or non-goals.
 2. Define the validation contract. State completion expectations before implementation: expected behavior, checks to run, user flows to exercise, and evidence required in the writer handoff. For UI, CLI, integration, or workflow changes, include at least one validator angle that uses the product the way a user would rather than only reading code.

package/dist/builtin/subagents/src/extension/index.ts

@@ -38,7 +38,6 @@ import {
 } from "../slash/slash-live-state.js";
 import {
 	advanceResultPulseFrame,
-	renderLiveSubagentResult,
 	renderSubagentResult,
 	type SubagentResultRenderState,
 	stopResultAnimations,
@@ -48,6 +47,7 @@ import { parseSubagentNotifyContent } from "./notification-content.js";
 import { DEFAULT_PROMPT_GUIDANCE } from "./prompt-guidance.js";
 import { SubagentParams } from "./schemas.js";
 import { SUBAGENT_TOOL_DESCRIPTION } from "./tool-description.js";
+import { renderSubagentToolCall, renderSubagentToolResult } from "./tool-rendering.js";
 
 export {
 	PROMPT_TEMPLATE_SUBAGENT_CANCEL_EVENT,
@@ -157,7 +157,7 @@ export function renderSubagentNotification(
 	const icon =
 		details.status === "completed"
 			? theme.fg("success", "✓")
-			: details.status === "paused"
+			: details.status === "interrupted"
 				? theme.fg("warning", "■")
 				: theme.fg("error", "✗");
 	const parts: string[] = [];
@@ -218,7 +218,6 @@ export default function registerSubagentExtension(pi: ExtensionAPI): void {
 			baseCwd: "",
 			currentSessionId: null,
 			subagentInProgress: false,
-			foregroundRuns: new Map(),
 			foregroundControls: new Map(),
 			lastForegroundControlId: null,
 			pendingForegroundControlNotices: new Map(),
@@ -326,14 +325,6 @@ export default function registerSubagentExtension(pi: ExtensionAPI): void {
 			promptTemplateBridge.cancelAll();
 			promptTemplateBridge.dispose();
 		});
-		function effectiveParallelTaskCount(tasks: Array<{ count?: unknown }> | undefined): number {
-			if (!tasks || tasks.length === 0) return 0;
-			return tasks.reduce((total, task) => {
-				const count =
-					typeof task.count === "number" && Number.isInteger(task.count) && task.count >= 1 ? task.count : 1;
-				return total + count;
-			}, 0);
-		}
 		const tool: ToolDefinition<typeof SubagentParams, Details, SubagentToolRenderState> = {
 			name: "subagent",
 			label: "Subagent",
@@ -344,27 +335,11 @@ export default function registerSubagentExtension(pi: ExtensionAPI): void {
 				const executionSignal = signal ?? ctx.signal ?? new AbortController().signal;
 				return executeSubagentCollapsed(id, params as SubagentParamsLike, executionSignal, onUpdate, ctx);
 			},
-			renderCall(args, theme) {
-				if (args.action) {
-					const target = args.agent || "";
-					return new Text(
-						`${theme.fg("toolTitle", theme.bold("subagent "))}${args.action}${target ? ` ${theme.fg("accent", target)}` : ""}`,
-						0,
-						0,
-					);
-				}
-				const isParallel = (args.tasks?.length ?? 0) > 0;
-				const parallelCount = effectiveParallelTaskCount(args.tasks as Array<{ count?: unknown }> | undefined);
-				return new Text(
-					isParallel
-						? `${theme.fg("toolTitle", theme.bold("subagent "))}parallel (${parallelCount})`
-						: `${theme.fg("toolTitle", theme.bold("subagent "))}${theme.fg("accent", args.agent || "?")}`,
-					0,
-					0,
-				);
+			renderCall(args, theme, context) {
+				return renderSubagentToolCall(args as SubagentParamsLike, theme, context);
 			},
 			renderResult(result, options, theme, context) {
-				return renderLiveSubagentResult(result, options, theme, context);
+				return renderSubagentToolResult(result, options, theme, context);
 			},
 		};
 		pi.registerTool(tool);

package/dist/builtin/subagents/src/extension/notification-content.ts

@@ -1,6 +1,6 @@
 import type { SubagentNotifyDetails } from "../runs/foreground/notify.js";
 
-const HEADER_STATUSES = ["completed", "failed", "paused"] as const;
+const HEADER_STATUSES = ["completed", "failed", "interrupted"] as const;
 
 function isHeaderLineTerminator(character: string): boolean {
 	return character === "\r" || character === "\u2028" || character === "\u2029";

package/dist/builtin/subagents/src/extension/schemas.ts

@@ -124,23 +124,11 @@ export const SubagentParams = Type.Object(
 				description: "Management/control action. Omit for execution mode.",
 			}),
 		),
-		id: Type.Optional(
-			Type.String({
-				description: "Run id or prefix for action='status', action='interrupt', or action='resume'.",
-			}),
-		),
+		id: Type.Optional(Type.String({ description: "Run id or prefix for action='status' or action='interrupt'." })),
 		runId: Type.Optional(
 			Type.String({
 				description:
-					"Target run ID for action='interrupt' or action='resume'. Defaults to the most recently active controllable run for interrupt. Prefer id for new calls.",
-			}),
-		),
-		index: Type.Optional(
-			Type.Integer({ minimum: 0, description: "Zero-based child index for actions that target a specific child." }),
-		),
-		message: Type.Optional(
-			Type.String({
-				description: "Follow-up message for action='resume'. Use index to choose a child from multi-child runs.",
+					"Target run ID for action='interrupt'. Defaults to the most recently active controllable run. Prefer id for new calls.",
 			}),
 		),
 		config: Type.Optional(

package/dist/builtin/subagents/src/extension/tool-description.ts

@@ -14,7 +14,6 @@ MANAGEMENT (use action field, omit agent/task/tasks):
 • { action: "delete", agent: "code-analysis.custom-agent" }
 CONTROL:
 • { action: "status", id: "..." } - inspect an in-process run by id or prefix
-• { action: "interrupt", id?: "..." } - soft-interrupt the current child turn and leave the run paused
-• { action: "resume", id: "...", message: "...", index?: 0 } - follow up with a live child or revive a retained foreground child
+• { action: "interrupt", id?: "..." } - soft-interrupt the current child turn; the child is terminal for continuation, so follow-up work starts a fresh launch
 DIAGNOSTICS:
 • { action: "doctor" } - read-only report for runtime paths, discovery, sessions, and intercom`;

package/dist/builtin/subagents/src/extension/tool-rendering.ts

@@ -0,0 +1,53 @@
+import type { AgentToolResult } from "@earendil-works/pi-agent-core";
+import { type Component, Container, Text } from "@earendil-works/pi-tui";
+import { getBurstDisplay } from "../runs/foreground/subagent-executor-burst-display.js";
+import type { SubagentParamsLike } from "../runs/foreground/subagent-executor-types.js";
+import type { Details } from "../shared/types.js";
+import { renderLiveSubagentResult } from "../tui/render.js";
+
+type Theme = Parameters<typeof renderLiveSubagentResult>[2];
+type RenderContext = Parameters<typeof renderLiveSubagentResult>[3] & { toolCallId: string };
+
+function effectiveParallelTaskCount(tasks: Array<{ count?: unknown }> | undefined): number {
+	if (!tasks || tasks.length === 0) return 0;
+	return tasks.reduce((total, task) => {
+		const count = typeof task.count === "number" && Number.isInteger(task.count) && task.count >= 1 ? task.count : 1;
+		return total + count;
+	}, 0);
+}
+
+export function renderSubagentToolCall(args: SubagentParamsLike, theme: Theme, context: RenderContext): Component {
+	const burst = getBurstDisplay(context.toolCallId);
+	if (burst && !burst.owner) return new Container();
+	if (args.action) {
+		const target = args.agent || "";
+		return new Text(
+			`${theme.fg("toolTitle", theme.bold("subagent "))}${args.action}${target ? ` ${theme.fg("accent", target)}` : ""}`,
+			0,
+			0,
+		);
+	}
+	if (burst) {
+		return new Text(`${theme.fg("toolTitle", theme.bold("subagent "))}parallel (${burst.taskCount})`, 0, 0);
+	}
+	const isParallel = (args.tasks?.length ?? 0) > 0;
+	const parallelCount = effectiveParallelTaskCount(args.tasks as Array<{ count?: unknown }> | undefined);
+	return new Text(
+		isParallel
+			? `${theme.fg("toolTitle", theme.bold("subagent "))}parallel (${parallelCount})`
+			: `${theme.fg("toolTitle", theme.bold("subagent "))}${theme.fg("accent", args.agent || "?")}`,
+		0,
+		0,
+	);
+}
+
+export function renderSubagentToolResult(
+	result: AgentToolResult<Details>,
+	options: { expanded: boolean; isPartial: boolean },
+	theme: Theme,
+	context: RenderContext,
+): Component {
+	const burst = getBurstDisplay(context.toolCallId);
+	if (burst && !burst.owner) return new Container();
+	return renderLiveSubagentResult(burst?.result ?? result, options, theme, context);
+}

package/dist/builtin/subagents/src/intercom/intercom-bridge.ts

@@ -37,7 +37,7 @@ const DEFAULT_INTERCOM_BRIDGE_TEMPLATE = `The inherited thread is reference-only
 
 Use contact_supervisor first. It resolves the supervisor session "{orchestratorTarget}" and run metadata automatically.
 - Need a decision, blocked, approval, or product/API/scope ambiguity: contact_supervisor({ reason: "need_decision", message: "<question>" })
-- After contact_supervisor with reason "need_decision", stay alive and continue only after the reply arrives. Do not finish your final response with a choose-one question.
+- A claimed decision or interview ends this child. Do not wait for or expect a reply in this run; the supervisor receives a dynamic [TASK_CONTEXT] handoff and may launch a fresh subagent with a new run identity and the answer.
 - Do not ask for clarification when the only conflict is review-only/no-edit versus progress-writing or artifact-writing instructions. Review-only/no-edit wins; leave files unchanged and mention the conflict in your final result only if it matters.
 - Meaningful progress or unexpected discoveries that change the plan: contact_supervisor({ reason: "progress_update", message: "UPDATE: <summary>" })
 - Generic intercom is lower-level plumbing/fallback only: intercom({ action: "ask", to: "{orchestratorTarget}", message: "<question>" })

package/dist/builtin/subagents/src/intercom/result-intercom.ts

@@ -21,7 +21,7 @@ export function resolveSubagentResultStatus(input: {
 	detached?: boolean;
 }): SubagentResultStatus {
 	if (input.detached || input.status === "continued") return "detached";
-	if (input.interrupted || input.status === "interrupted" || input.state === "paused") return "paused";
+	if (input.interrupted || input.status === "interrupted" || input.state === "interrupted") return "interrupted";
 	if (input.status === "ok" || input.success === true || input.state === "complete") return "completed";
 	if (input.status === "error" || input.status === "skipped" || input.success === false || input.state === "failed")
 		return "failed";
@@ -32,7 +32,7 @@ function countStatuses(children: SubagentResultIntercomChild[]): Record<Subagent
 	const counts: Record<SubagentResultStatus, number> = {
 		completed: 0,
 		failed: 0,
-		paused: 0,
+		interrupted: 0,
 		detached: 0,
 	};
 	for (const child of children) {
@@ -45,7 +45,7 @@ function formatStatusCounts(counts: Record<SubagentResultStatus, number>): strin
 	const parts = [
 		counts.completed ? `${counts.completed} completed` : undefined,
 		counts.failed ? `${counts.failed} failed` : undefined,
-		counts.paused ? `${counts.paused} paused` : undefined,
+		counts.interrupted ? `${counts.interrupted} interrupted` : undefined,
 		counts.detached ? `${counts.detached} detached` : undefined,
 	].filter((part): part is string => Boolean(part));
 	return parts.length ? parts.join(", ") : "0 results";
@@ -54,7 +54,7 @@ function formatStatusCounts(counts: Record<SubagentResultStatus, number>): strin
 function resolveGroupedStatus(children: SubagentResultIntercomChild[]): SubagentResultStatus {
 	const counts = countStatuses(children);
 	if (counts.failed > 0) return "failed";
-	if (counts.paused > 0) return "paused";
+	if (counts.interrupted > 0) return "interrupted";
 	if (counts.completed > 0) return "completed";
 	if (counts.detached > 0) return "detached";
 	return "failed";

package/dist/builtin/subagents/src/runs/foreground/execution-parent-ask-handoff.ts

@@ -0,0 +1,78 @@
+import {
+	PARENT_ASK_HANDOFF_REQUEST_EVENT,
+	type ParentAskHandoffRequest,
+	type RunSyncOptions,
+} from "../../shared/types.js";
+
+interface ExecutionParentAskState {
+	readonly agent: string;
+	readonly isUnavailable: () => boolean;
+}
+
+const PROCESS_PARENT_ASK_CLAIMS = Symbol.for("atomic/subagents/parent-ask-claims@1");
+
+type ProcessParentAskClaimHandler = (payload: unknown) => void;
+
+interface ProcessParentAskClaimRegistry {
+	handlers: Set<ProcessParentAskClaimHandler>;
+}
+
+function processClaimSlots(): typeof globalThis & Record<symbol, ProcessParentAskClaimRegistry | undefined> {
+	return globalThis as typeof globalThis & Record<symbol, ProcessParentAskClaimRegistry | undefined>;
+}
+
+function registerProcessClaimHandler(handler: ProcessParentAskClaimHandler): () => void {
+	const slots = processClaimSlots();
+	const registry = slots[PROCESS_PARENT_ASK_CLAIMS] ?? { handlers: new Set<ProcessParentAskClaimHandler>() };
+	slots[PROCESS_PARENT_ASK_CLAIMS] = registry;
+	registry.handlers.add(handler);
+	return () => {
+		registry.handlers.delete(handler);
+		if (registry.handlers.size === 0 && slots[PROCESS_PARENT_ASK_CLAIMS] === registry) {
+			delete slots[PROCESS_PARENT_ASK_CLAIMS];
+		}
+	};
+}
+
+function isParentAskHandoffRequest(payload: unknown): payload is ParentAskHandoffRequest {
+	if (!payload || typeof payload !== "object" || Array.isArray(payload)) return false;
+	const request = payload as Partial<ParentAskHandoffRequest>;
+	return (
+		typeof request.runId === "string" &&
+		typeof request.index === "number" &&
+		typeof request.agent === "string" &&
+		typeof request.childIntercomTarget === "string" &&
+		typeof request.orchestratorTarget === "string" &&
+		(request.kind === "decision" || request.kind === "interview" || request.kind === "intercom") &&
+		typeof request.question === "string" &&
+		typeof request.claimed === "boolean"
+	);
+}
+
+/** Claim a blocking ask only for the exact live child attempt that issued it. */
+export function registerExecutionParentAskHandoff(options: RunSyncOptions, state: ExecutionParentAskState): () => void {
+	if (!options.onParentAskHandoff) return () => {};
+	const handleRequest = (payload: unknown): void => {
+		if (state.isUnavailable() || !isParentAskHandoffRequest(payload)) return;
+		if (
+			payload.claimed ||
+			payload.runId !== options.runId ||
+			payload.index !== (options.index ?? 0) ||
+			payload.agent !== state.agent ||
+			payload.childIntercomTarget !== options.intercomSessionName ||
+			payload.orchestratorTarget !== options.orchestratorIntercomTarget
+		)
+			return;
+		payload.claimed = true;
+		options.onParentAskHandoff?.(payload);
+	};
+	const eventCleanup = options.intercomEvents?.on(PARENT_ASK_HANDOFF_REQUEST_EVENT, handleRequest) ?? (() => {});
+	const processCleanup = registerProcessClaimHandler(handleRequest);
+	let cleaned = false;
+	return () => {
+		if (cleaned) return;
+		cleaned = true;
+		eventCleanup();
+		processCleanup();
+	};
+}

package/dist/builtin/subagents/src/runs/foreground/inprocess-run-sync.ts

@@ -23,6 +23,7 @@ import type { AttemptOutcome, ChildSpec, ParentContext } from "../inprocess/runn
 import { filterSpawnableModelCandidates } from "../shared/model-candidate-filter.js";
 import { buildModelCandidates } from "../shared/model-fallback.js";
 import { registerExecutionIntercomDetach } from "./execution-intercom-detach.js";
+import { registerExecutionParentAskHandoff } from "./execution-parent-ask-handoff.js";
 
 function emptyUsage(): Usage {
 	return {
@@ -349,11 +350,6 @@ export async function runSingleInProcess(
 			lastActivityAt: Date.now(),
 		});
 	}
-	control.registerAttempt(options.runId, running, {
-		model: resolvedCandidate?.model,
-		modelId: candidate,
-		thinkingLevel: spec.thinkingLevel,
-	});
 	let detached = false;
 	let resolveContinuation!: () => void;
 	const continuation = new Promise<void>((resolve) => {
@@ -369,10 +365,15 @@ export async function runSingleInProcess(
 			resolveContinuation();
 		},
 	});
+	const parentAskCleanup = registerExecutionParentAskHandoff(options, {
+		agent: agent.name,
+		isUnavailable: () => running.status !== "running" || detached,
+	});
 	const terminal = running.promise.then((value) => ({ kind: "terminal" as const, value }));
 	const winner = await Promise.race([terminal, continuation.then(() => ({ kind: "continued" as const }))]);
 	if (winner.kind === "continued") {
 		detachCleanup();
+		parentAskCleanup();
 		void running.promise.then(async (continuedOutcome) => {
 			const recovered = resultFromOutcome(agent, task, continuedOutcome, startedAt, artifactPaths, {
 				cwd,
@@ -441,6 +442,7 @@ export async function runSingleInProcess(
 		return continuedResult;
 	}
 	detachCleanup();
+	parentAskCleanup();
 	const outcome = winner.value;
 	const result = resultFromOutcome(agent, task, outcome, startedAt, artifactPaths, {
 		cwd,

package/dist/builtin/subagents/src/runs/foreground/notify.ts

@@ -21,7 +21,7 @@ interface SubagentStepResult {
 
 export interface SubagentNotifyDetails {
 	agent: string;
-	status: "completed" | "failed" | "paused";
+	status: "completed" | "failed" | "interrupted";
 	taskInfo?: string;
 	resultPreview: string;
 	durationMs?: number;
@@ -211,14 +211,13 @@ export default function registerSubagentNotify(pi: ExtensionAPI): () => void {
 		inFlight.set(key, ownership.promise);
 		const agent = result.agent ?? "unknown";
 		const summary = typeof result.summary === "string" ? result.summary : "";
-		const paused =
-			result.status === "interrupted" || result.state === "paused" || summary.startsWith("Paused after interrupt.");
-		const status = paused
-			? "paused"
+		const interrupted = result.status === "interrupted" || result.state === "interrupted";
+		const status = interrupted
+			? "interrupted"
 			: result.status === "ok"
 				? "completed"
 				: result.status === "continued"
-					? "paused"
+					? "interrupted"
 					: "failed";
 
 		const taskInfo =