@zachwill/pi-orchestrate 0.16.0 → 0.17.0

package/README.md

@@ -1,18 +1,26 @@
 # Pi Orchestrate
 
-[`@zachwill/pi-orchestrate`](https://www.npmjs.com/package/@zachwill/pi-orchestrate) lets a Pi session delegate work to direct child sessions. It requires Pi 0.85.0 or newer.
+[`@zachwill/pi-orchestrate`](https://www.npmjs.com/package/@zachwill/pi-orchestrate) lets a Pi session delegate work to direct child sessions.
 
 - Each worker gets a focused brief and a separate conversation.
 - Workers run independently and return their results to the parent.
 - Only the parent can delegate; workers cannot create more workers.
 
+Requires Pi 0.85.0 or newer.
+
+```bash
+pi install npm:@zachwill/pi-orchestrate
+```
+
 ## The model
 
 Each `orchestrate` dispatch creates a fresh worker session with its own transcript. The worker receives a complete brief from the parent but not the parent's conversation.
 
-A worker definition is reusable configuration: it selects the worker's prompt, tools, lifecycle, and optional model settings. It is not a running or retained session.
+A worker definition is reusable configuration for the worker's prompt, tools, lifecycle, and optional model settings. The parent remains responsible for the user's complete requested outcome across its own and worker work.
 
-Independent workers dispatched together run concurrently. Their results return only to the parent session that started them, and the parent synthesizes the group after every worker finishes. A rejected or failed worker does not cancel its peers. Orchestration dispatched alongside unrelated tool calls runs inline instead of in the background.
+Workers run in the background. `orchestrate` and `interactive_send` return acceptance so the parent can continue useful independent work, including tool calls dispatched alongside the workers. Worker dispatches in the same response form one result group; dispatches in later responses form separate groups.
+
+Results return only to the parent session that started the workers. Results that settle while the parent is busy are queued. After the parent run ends normally, individual results can enter its context as they arrive; a dispatch group resumes the parent after every admitted member settles. The parent can do useful independent work before ending its run, or end promptly when progress needs worker evidence. A rejected, failed, or aborted worker does not cancel its peers; stopping other active workers requires an explicit `worker_abort` request.
 
 Workers have one of two lifecycles:
 
@@ -23,13 +31,7 @@ A **worker ID** identifies a worker session. A **run ID** identifies one generat
 
 Interactive workers remain available across session switches and extension reloads within the same Pi process. Closing one releases its retained session; process shutdown releases any that remain.
 
-## Compaction
-
-Parent compaction does not stop workers. Results that settle during compaction remain queued for the owning session and resume automatic delivery when that session becomes idle, including after failed or cancelled compaction. Grouped work still triggers synthesis only after the group settles.
-
-Before each parent model request, the extension adds a fresh, owner-scoped snapshot of active workers and ready interactive sessions. This transient context survives compaction by being rebuilt from live state; it is not appended to the transcript. The snapshot is capped at 12 KiB and reports omitted workers or truncated assignments, with `worker_status` available for recovery rather than polling.
-
-This state belongs to the running Pi process. Compaction does not require restarting workers, and persisted transcripts do not restore running workers after a process restart.
+Workers keep running when the parent conversation is compacted, and their results return automatically. Restarting Pi does not restore running workers.
 
 ## Agent interface
 
@@ -43,11 +45,11 @@ Pi Orchestrate gives the parent five model-facing tools:
 | `worker_abort` | Stop active workers owned by the parent |
 | `worker_status` | Inspect the trusted catalog and diagnose the parent's worker state |
 
-The extension supplies the parent with the exact dispatch and lifecycle rules for these tools. The README describes their behavior rather than duplicating those model instructions.
+The extension supplies the parent with instructions for using these tools.
 
 ## Worker definitions
 
-The package includes four fallback definitions in [`examples/workers/`](examples/workers/): `scout` for small factual probes, `investigator` for read-only cross-file research, `worker` for bounded implementation, and `web` for public web research. The first three inherit the parent's active model. The `web` worker uses the model declared in its definition and requires an installed, authenticated Codex CLI.
+The package includes four fallback definitions in [`examples/workers/`](examples/workers/): `scout` for small factual probes, `investigator` for read-only cross-file research, `worker` for bounded implementation, and `web` for public web research. The fallbacks use `openai-codex/gpt-6-sol`, except `scout`, which uses `openai-codex/gpt-6-luna`. The `web` worker also requires an installed, authenticated Codex CLI.
 
 Definitions are loaded by name in this precedence order:
 
@@ -85,8 +87,6 @@ The frontmatter is strict:
 
 The Markdown body is the worker's nonempty system prompt. `tools` and `skills` accept either YAML arrays or comma-separated strings. Supported Pi tools are `read`, `bash`, `edit`, `write`, `grep`, `find`, and `ls`. Unknown fields and malformed definitions are rejected and appear in catalog diagnostics.
 
-Each `orchestrate` call starts a new worker session from the selected definition. Only `interactive_send` continues an existing session.
-
 ## Trust boundary
 
 Workers run in the parent process and are not security sandboxes. They share its filesystem and environment permissions.
@@ -95,6 +95,4 @@ Workers can use global Pi settings, authentication, packages, extensions, skills
 
 A definition's `tools` field controls Pi's tool allowlist, not operating-system authority. A worker with `bash` can start external processes, including other agent CLIs. A read-only prompt also does not prevent writes when the worker has a write-capable tool.
 
-Concurrent workers share the same working tree, so overlapping write scopes can collide. The parent owns the outcome, works directly, and delegates independent parts when doing so improves speed or quality. The parent integrates worker results and checks the evidence behind consequential claims or changes, adding independent review when a specific risk warrants it.
-
-Pi Orchestrate excludes itself from child sessions and keeps workers as direct Pi children.
+Concurrent workers share the same working tree, so overlapping write scopes can collide.

package/examples/workers/investigator.md

@@ -1,7 +1,8 @@
 ---
 name: investigator
 description: Investigates cross-file questions through read-only inspection and evidence-based synthesis.
-thinking: medium
+model: openai-codex/gpt-6-sol
+thinking: high
 tools: read, grep, find, ls, bash
 lifecycle: one-shot
 ---

package/examples/workers/scout.md

@@ -1,6 +1,7 @@
 ---
 name: scout
 description: Answers a small factual repository question through shallow, read-only inspection.
+model: openai-codex/gpt-6-luna
 thinking: low
 tools: read, grep, find, ls, bash
 lifecycle: one-shot

package/examples/workers/web.md

@@ -1,7 +1,7 @@
 ---
 name: web
 description: Researches the public web with one or more Codex searches and returns a source-grounded synthesis.
-model: openai-codex/gpt-5.6-sol
+model: openai-codex/gpt-6-sol
 thinking: medium
 tools: bash
 skills: []
@@ -31,7 +31,7 @@ stderr_log="$work_dir/stderr.log"
 
 codex exec - \
   --ignore-user-config \
-  --model gpt-5.6-sol \
+  --model gpt-6-sol \
   -c 'model_reasoning_effort="medium"' \
   -c 'web_search="cached"' \
   --ephemeral \

package/examples/workers/worker.md

@@ -1,6 +1,7 @@
 ---
 name: worker
 description: Implements bounded code changes, fixes, and refactors.
+model: openai-codex/gpt-6-sol
 thinking: medium
 tools: read, bash, edit, write, grep, find, ls
 lifecycle: one-shot

package/extension/index.ts

@@ -84,7 +84,7 @@ export function createOrchestrationExtension(
         orchestration: host.orchestration,
         getCatalog: catalogFor,
         getDispatchDecision: (toolCallId) =>
-          dispatchDecisions.get(toolCallId) ?? { mode: "inline" },
+          dispatchDecisions.get(toolCallId) ?? {},
       });
       hostAttachment ??= attachProcessHost(host);
 

package/extension/orchestration/service.ts

@@ -376,14 +376,13 @@ class OrchestrationEngine implements OrchestrationService {
       const runId = this.idFactories.runId();
       const completion = yield* Deferred.make<CompletedRun>();
       const now = this.clock.currentTimeMillisUnsafe();
-      const runRecord: RunRecord = {
-        id: runId,
-        ownerSessionId: context.ownerSessionId,
-        workerId: validatedWorkerId,
+      const runRecord = makeRunRecord(
+        runId,
+        validatedWorkerId,
+        context,
         mode,
-        state: "running",
-        createdAt: now,
-      };
+        now,
+      );
 
       const admission = this.transact((draft) => {
         const ready = readyInteractiveDecision(

package/extension/parent/contract.ts

@@ -96,44 +96,35 @@ function buildContract(catalog: WorkerCatalog): string {
   return `${CONTRACT_START}
 ## Pi Orchestrate Contract
 
-You are responsible for delivering the user’s requested outcome. Work directly and use workers where parallel ownership or specialized judgment materially helps. Own the difficult decisions, shared problems, and final answer.
+You own the user’s outcome across parent and worker work. Exercise judgment: use workers when they help, continue useful work yourself, and deliver one coherent answer.
 
-### Scope
+### Outcome and scope
 
-- Scope comes from the user’s request and applicable instructions. Preserve explicitly broad tasks, but do not broaden narrow tasks because execution reveals related work.
-- Understand the requested outcome and take the next concrete step. Keep planning proportional to dependencies and risk; do not require a written scope statement, roster, or approval checkpoint unless it resolves a real ambiguity.
-- Necessary investigation and implementation details belong to the task. Separate optional improvements from the requested work; ask before making consequential changes beyond it.
-- Admit newly discovered work only when the current change would otherwise be incorrect, unsafe, nonfunctional, or unverifiable. If that work exceeds the boundary, narrow, revert, or ask the user rather than silently expanding.
-- Do not introduce cross-feature policy, infrastructure, deployment, or compatibility work unless the request or an unavoidable requirement of the current change calls for it.
-- Completed worker effort does not justify retaining an overgrown change set.
+- Preserve the requested scope, completeness, and form. Do not silently substitute an easier deliverable, narrow a broad request to a sample, or treat checks against a selected subset as evidence that the full requirement is satisfied.
+- Do the investigation and implementation needed for the outcome, but do not invent adjacent deliverables, policies, or cleanup. Ask when a material ambiguity or consequential out-of-scope change requires the user’s authority.
+- Assign write ownership so concurrent scopes are disjoint. Give one owner any shared file or integration point, and preserve changes you do not own.
 
 ### Delegation
 
-- Delegate substantive, independent parts of the problem when doing so improves speed or quality. Prefer end-to-end assignments: each worker investigates what its question requires, does the work, and checks its result. The parent should solve useful parts of the problem directly rather than defaulting to a coordination-only role.
-- Respect the user’s requested workers and counts. Otherwise choose the smallest team that usefully advances the outcome. Do not add roles merely because preparation, implementation, and review can be separated.
-- Each \`orchestrate\` call creates a fresh worker session. The same worker definition and identical brief may be used for independent judgments; do not vary briefs merely to make them appear different. Interactive follow-up continues one worker ID with its existing context.
-- Give every worker a self-contained brief with its objective, context, owned paths, forbidden changes, success criteria, expected output, and stop condition. Instruct workers to report adjacent findings without fixing them. Workers do not receive the parent conversation.
+- Delegate separable work when the expected improvement in quality or latency is worth the coordination cost. Respect worker choices and counts requested by the user; otherwise choose from the work rather than applying a minimum, maximum, or mandatory role pattern.
+- Give each worker enough context to own one outcome and scope boundary, including relevant constraints, owned paths, and consequential evidence checks. Workers do not receive the parent conversation. Have them report out-of-scope findings instead of fixing them.
+- **Important:** When independent worker assignments are ready, dispatch them using one \`multi_tool_use.parallel\` call containing every \`functions.orchestrate\` call. Do not dispatch one worker first and batch the rest afterward.
+- Each \`orchestrate\` call creates a fresh worker session. Interactive follow-up uses \`interactive_send\` with the existing worker ID and context; close a ready interactive worker with \`interactive_close\` when it is no longer needed.
 
-### Parallel dispatch
+### Dispatch and dependencies
 
-- Form the complete wave before emitting any tool call. “Complete” means every worker admitted for the current change and turn, not every potentially useful concern.
-- For one worker, make one fully briefed \`orchestrate\` call. For N workers where N > 1, make exactly one \`multi_tool_use.parallel\` call containing exactly N \`functions.orchestrate\` entries and no other tools.
-- If \`multi_tool_use.parallel\` is unavailable, emit all N \`orchestrate\` calls as native siblings in one assistant response.
-- Never split a multi-worker wave across assistant responses; an admitted sole asynchronous \`orchestrate\` call ends the parent turn.
-- The expanded tool-call group must contain only the intended \`orchestrate\` calls. Mixing another tool into the group makes orchestration inline and blocking.
+- \`orchestrate\` and \`interactive_send\` start background work and return acceptance without ending the parent run, including alongside other tools. Worker dispatches in the same response are grouped for result delivery; dispatches in later responses form separate groups.
+- After dispatch, continue useful independent work. When that work is exhausted or progress needs worker evidence, end the run normally so automatic result delivery can resume you. A brief truthful pending-status response is acceptable; do not claim final completion before necessary results are considered.
+- Do not poll \`worker_status\`, sleep, duplicate active assignments, or invent work while results are pending. Do not force parent work when none is useful, and do not stop before doing independent work that materially advances the outcome.
+- Results that settle while the parent is busy are queued and delivered when the parent run ends. Do not redispatch queued work.
+- Compaction does not stop workers. Use the fresh live-worker snapshot for active assignments and ready interactive sessions rather than stale conversation summaries. Do not redispatch work because its dispatch was compacted away. Use \`worker_status\` once only for diagnostics or recovery when the snapshot overflows or state appears inconsistent.
 
 ### Completion
 
-- After dispatching, wait for automatic result delivery instead of polling \`worker_status\`. Do not call \`sleep\`, poll with another tool, inspect progress indirectly, or issue no-op calls.
-- Compaction does not stop workers. A fresh live-worker context snapshot identifies active assignments and ready interactive sessions; use it rather than stale status in conversation summaries. Do not redispatch work because its dispatch was compacted away. If the snapshot is truncated or state appears inconsistent, use \`worker_status\` once for recovery, not polling.
-- While waiting, perform only already-admitted independent work from the current change; otherwise end the turn.
-- Classify findings before acting: fix or remove defects introduced by the current change, complete unfinished requirements inside its boundary, and record adjacent or pre-existing concerns without admitting them.
-- Dispatch another wave only for admitted work inside the current change. Independence, local correctness, reviewer concern, or consistency alone does not justify more work.
-- Inspect worker results and check the evidence behind consequential claims or changes. Add independent review when a specific risk warrants it, not as an automatic phase. Reuse credible verification already performed; investigate gaps and contradictions.
-- Inspect the combined result and worker evidence, resolve disagreements, and accept, reduce, or discard the change. Do not personally repeat delegated review or verification without a concrete reason.
-- Verification decides whether to accept the change; it is not a general source of new work. Fix failures caused by the change, but narrow, revert, report, or ask when verification demands unrelated work.
-- Stop when the acceptance criteria pass. Report delivered work separately from findings deliberately left outside scope.
-- Prefer one-shot workers. Use interactive workers only when retained context is useful and follow the lifecycle requirements in the tool descriptions.
+- Treat worker reports as input, not the answer. Resolve material conflicts and assess the combined result against the original request; a worker’s local success does not redefine completion.
+- Check consequential claims, changes, and failure modes with evidence suited to the task. Add review or integration tests only when a concrete risk warrants them, and do not repeat credible worker checks without a reason.
+- Do not give the final answer until every worker result necessary to the outcome has been delivered and considered. Report completed work and any unresolved or out-of-scope finding directly.
+- Use \`worker_abort\` only to stop active owned work. Ending the parent run, compaction, and closing a ready interactive session do not cancel other workers.
 
 ### Trusted worker catalog
 

package/extension/parent/delivery.ts

@@ -7,7 +7,7 @@ export const MAX_WORKER_DELIVERY_MARKDOWN_BYTES = 16 * 1024;
 export const DELIVERY_TRUNCATION_MARKER =
   "\n\n[Worker result truncated for parent context. Full output remains in structured details.]";
 export const DELIVERY_PARENT_INSTRUCTIONS =
-  "Parent: Synthesize all results, resolve conflicts, review changes and evidence, run integration checks, and continue the user's task. Do not merely forward worker reports.";
+  "Parent: Use these results as input to the user's task. Resolve material conflicts, check consequential evidence, and complete the requested outcome; do not merely forward worker reports or reopen work that is already satisfied.";
 
 export type ParentBindingGeneration = string | number | symbol;
 export type ScheduleIdleRecheck = (recheck: () => void) => () => void;

package/extension/parent/dispatch-policy.ts

@@ -6,7 +6,6 @@ export interface ParentToolCall {
 }
 
 export interface DispatchDecision {
-  readonly mode: "async" | "inline";
   readonly synthesisGroup?: SynthesisGroup;
 }
 
@@ -20,30 +19,21 @@ const DISPATCH_TOOL_NAMES: ReadonlySet<string> = new Set([
   "interactive_send",
 ]);
 
-// Sole dispatches and homogeneous orchestrate waves detach so the parent turn can
-// end while work continues. Mixed tools stay inline because their shared parent
-// turn still has sibling work; one wave boundary defers one synthesis turn until
-// every admitted member has settled.
+// Every public dispatch detaches so sibling parent tools can finish independently.
+// Dispatches from one assistant response share a synthesis boundary; ordinary
+// sibling tools are neither group members nor part of its expected size.
 export function classifyParentDispatches(
   toolCalls: readonly ParentToolCall[],
 ): readonly ClassifiedParentDispatch[] {
-  const isOrchestrateGroup =
-    toolCalls.length > 1 &&
-    toolCalls.every((toolCall) => toolCall.name === "orchestrate");
-  const synthesisGroup = isOrchestrateGroup
-    ? { id: `orchestrate:${toolCalls[0]?.id ?? "group"}`, size: toolCalls.length }
+  const dispatches = toolCalls.filter((toolCall) =>
+    DISPATCH_TOOL_NAMES.has(toolCall.name)
+  );
+  const synthesisGroup = dispatches.length > 1
+    ? { id: `dispatch:${dispatches[0]!.id}`, size: dispatches.length }
     : undefined;
 
-  return toolCalls.flatMap((toolCall): ClassifiedParentDispatch[] => {
-    if (!DISPATCH_TOOL_NAMES.has(toolCall.name)) return [];
-    return [{
-      toolCallId: toolCall.id,
-      decision: {
-        mode: isOrchestrateGroup || toolCalls.length === 1 ? "async" : "inline",
-        ...(toolCall.name === "orchestrate" && synthesisGroup
-          ? { synthesisGroup }
-          : {}),
-      },
-    }];
-  });
+  return dispatches.map((toolCall) => ({
+    toolCallId: toolCall.id,
+    decision: synthesisGroup ? { synthesisGroup } : {},
+  }));
 }

package/extension/parent/worker-context.ts

@@ -146,7 +146,7 @@ function renderContext(
   const guidance: string[] = [];
   if (activeCount > 0) {
     guidance.push(
-      "Do not duplicate active assignments. Wait for automatic result delivery; do not poll worker_status for completion.",
+      "Do not duplicate active assignments. Continue useful independent work when it materially advances the outcome.",
     );
   }
   if (readyCount > 0) {
@@ -155,7 +155,7 @@ function renderContext(
     );
   }
   guidance.push(
-    "Use worker_status only for diagnostics or recovery when this snapshot reports overflow or state appears inconsistent.",
+    "Settled results are delivered automatically after the parent run ends. If progress depends on pending evidence, end the run truthfully rather than polling. Use worker_status only for diagnostics or recovery when this snapshot reports overflow or state appears inconsistent.",
   );
   sections.push(`Guidance:\n- ${guidance.join("\n- ")}`);
 

package/extension/pi/tools.ts

@@ -1,4 +1,3 @@
-import type { AgentToolResult } from "@earendil-works/pi-agent-core";
 import type {
   ExtensionAPI,
   ExtensionContext,
@@ -28,10 +27,7 @@ import type {
 } from "../orchestration/admission.ts";
 import type {
   AcceptedRun,
-  CompletedRun,
   OwnerSnapshot,
-  SettlementListener,
-  WorkerRunResult,
 } from "../orchestration/service.ts";
 import type { DispatchDecision } from "../parent/dispatch-policy.ts";
 import type { OrchestrationClient } from "../parent/process-host.ts";
@@ -42,11 +38,6 @@ import {
   workerAbortToolRenderer,
   workerStatusToolRenderer,
 } from "./tool-renderer.ts";
-import {
-  encodeInlineWorkerToolDetails,
-  type InlineWorkerSettlementDetails,
-  type WorkerSettlement,
-} from "../orchestration/settlement.ts";
 
 const STRICT_OBJECT = { additionalProperties: false } as const;
 const shortTextSchema = Type.String({
@@ -114,45 +105,30 @@ export function registerOrchestrationTools(
     name: "orchestrate",
     label: "Orchestrate",
     description:
-      "Dispatch fully briefed worker scopes. Pi executes native sibling tools concurrently; Pi Orchestrate treats a successfully admitted sole orchestrate call or pure sibling group as async. Mixing orchestrate with another tool makes it inline and blocking.",
-    promptSnippet: "Dispatch fully briefed parallel worker scopes",
+      "Dispatch one fully briefed worker scope in the background. All orchestrate and interactive_send calls in the same assistant response form one result group; ordinary sibling tools execute concurrently and are not group members.",
+    promptSnippet: "Dispatch one fully briefed worker scope in the background",
     promptGuidelines: [
-      "Spin up as many workers as needed to cover every useful parallel scope and distinct validation perspective. Treat user-named workers or counts as a floor unless explicitly capped, and reuse the same worker role across multiple calls when useful.",
-      "For an intended async wave of N workers, the next assistant response must contain exactly N separate, fully briefed orchestrate calls; one call is valid only when N=1. To run it asynchronously, include no other tool calls; harmless response text does not affect runtime classification.",
-      "When a parallel tool dispatcher is available, use it once with exactly N orchestrate entries and no other tools; for example, put N functions.orchestrate entries in multi_tool_use.parallel. Otherwise emit N native sibling orchestrate calls in one assistant response.",
-      "Form all N calls before emitting or finalizing the response. Never emit one call and wait for its result before forming the rest of the wave: a successfully admitted sole async orchestrate call returns terminate=true and ends the turn.",
+      "orchestrate starts background work and returns acceptance without ending the parent run. Dispatch siblings in one assistant response share a result group; ordinary sibling tools do not join that group.",
     ],
     executionMode: "parallel",
     parameters: taskSchema,
     ...orchestrateToolRenderer,
-    async execute(toolCallId, params, signal, onUpdate, ctx) {
+    async execute(toolCallId, params, signal, _onUpdate, ctx) {
       const decision = deps.getDispatchDecision(toolCallId);
-      const mode = decision.mode;
-      const orchestrationContext = buildOrchestrationContext(ctx, deps, decision.synthesisGroup);
-      if (mode === "async") {
-        const acceptedRun = await deps.orchestration.orchestrate(
-          orchestrationContext,
-          params,
-          "async",
-          signal,
-        );
-        const readable = acceptedRunSummary(acceptedRun);
-        return {
-          ...readableToolResult(`Accepted async run ${readable.run_id}.`, readable),
-          terminate: true,
-        };
-      }
-
-      const completedRun = await deps.orchestration.orchestrate(
+      const orchestrationContext = buildOrchestrationContext(
+        ctx,
+        deps,
+        decision.synthesisGroup,
+      );
+      const acceptedRun = await deps.orchestration.orchestrate(
         orchestrationContext,
         params,
-        "inline",
+        "async",
         signal,
-        createInlineSettlementListener(onUpdate),
       );
-      const readable = completedRunSummary(completedRun);
+      const readable = acceptedRunSummary(acceptedRun);
       return readableToolResult(
-        `Completed inline run ${readable.run_id}.`,
+        `Accepted async run ${readable.run_id}.`,
         readable,
       );
     },
@@ -185,43 +161,31 @@ export function registerOrchestrationTools(
     name: "interactive_send",
     label: "Interactive Send",
     description:
-      "Send follow-up instructions only to an owned lifecycle interactive worker whose status is ready. Never use for one-shot or completed workers; one-shot sessions terminate automatically. A sole tool call runs asynchronously; sibling tool calls make it inline and blocking.",
+      "Send background follow-up instructions only to an owned lifecycle interactive worker whose status is ready. All interactive_send and orchestrate calls in the same assistant response form one result group; ordinary sibling tools execute concurrently and are not group members. Never use for one-shot or completed workers.",
     promptSnippet: "Use only for an owned lifecycle interactive worker with status ready; never one-shot/completed because one-shot sessions terminate automatically",
     promptGuidelines: [
-      "Use interactive_send only for an owned lifecycle interactive worker whose status is ready; never use it for one-shot or completed workers because one-shot sessions terminate automatically.",
+      "interactive_send starts background follow-up work and returns acceptance without ending the parent run. Dispatch siblings in one assistant response share a result group; ordinary sibling tools do not join that group.",
     ],
     parameters: interactiveSendSchema,
     ...interactiveSendToolRenderer,
-    async execute(toolCallId, params, signal, onUpdate, ctx) {
+    async execute(toolCallId, params, signal, _onUpdate, ctx) {
       const workerId = params.worker_id;
-      const mode = deps.getDispatchDecision(toolCallId).mode;
-      const orchestrationContext = buildOrchestrationContext(ctx, deps);
-      if (mode === "async") {
-        const acceptedRun = await deps.orchestration.sendInteractive(
-          orchestrationContext,
-          workerId,
-          params.instructions,
-          "async",
-          signal,
-        );
-        const readable = acceptedRunSummary(acceptedRun);
-        return {
-          ...readableToolResult(`Accepted async run ${readable.run_id}.`, readable),
-          terminate: true,
-        };
-      }
-
-      const completedRun = await deps.orchestration.sendInteractive(
+      const decision = deps.getDispatchDecision(toolCallId);
+      const orchestrationContext = buildOrchestrationContext(
+        ctx,
+        deps,
+        decision.synthesisGroup,
+      );
+      const acceptedRun = await deps.orchestration.sendInteractive(
         orchestrationContext,
         workerId,
         params.instructions,
-        "inline",
+        "async",
         signal,
-        createInlineSettlementListener(onUpdate),
       );
-      const readable = completedRunSummary(completedRun);
+      const readable = acceptedRunSummary(acceptedRun);
       return readableToolResult(
-        `Completed inline run ${readable.run_id}.`,
+        `Accepted async run ${readable.run_id}.`,
         readable,
       );
     },
@@ -289,20 +253,6 @@ function buildOrchestrationContext(
   };
 }
 
-function createInlineSettlementListener(
-  onUpdate: ((result: AgentToolResult<unknown>) => void) | undefined,
-): SettlementListener {
-  return (settlement) => {
-    onUpdate?.({
-      content: [{ type: "text", text: "Worker response received." }],
-      details: encodeInlineWorkerToolDetails({
-        mode: "inline",
-        result: inlineResultValue(settlement),
-      }),
-    });
-  };
-}
-
 function normalizeAbortTarget(params: {
   worker_ids?: string[];
   all?: boolean;
@@ -321,33 +271,6 @@ function acceptedRunSummary(run: AcceptedRun) {
   };
 }
 
-function completedRunSummary(run: CompletedRun) {
-  return encodeInlineWorkerToolDetails({
-    mode: "inline",
-    runId: run.id,
-    ownerSessionId: run.ownerSessionId,
-    result: inlineResultValue(run.result),
-  });
-}
-
-function inlineResultValue(
-  result: WorkerRunResult | WorkerSettlement,
-): InlineWorkerSettlementDetails {
-  return {
-    workerId: result.workerId,
-    worker: result.worker,
-    title: result.title,
-    status: result.status,
-    outcome: result.outcome,
-    usage: result.usage,
-    startedAt: result.startedAt,
-    settledAt: result.settledAt,
-    ...(result.sessionFile === undefined
-      ? {}
-      : { sessionFile: result.sessionFile }),
-  };
-}
-
 function statusSummary(catalog: WorkerCatalog, snapshot: OwnerSnapshot) {
   return {
     catalog: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zachwill/pi-orchestrate",
-  "version": "0.16.0",
+  "version": "0.17.0",
   "type": "module",
   "description": "Concurrent worker orchestration for Pi",
   "exports": {},