pi-subagents 0.19.3 → 0.20.1

package/CHANGELOG.md

@@ -2,6 +2,27 @@
 
 ## [Unreleased]
 
+## [0.20.1] - 2026-04-27
+
+### Fixed
+- Made the packaged `/parallel-cleanup` prompt self-contained instead of referencing local-only cleanup skills.
+
+## [0.20.0] - 2026-04-27
+
+### Added
+- Added a packaged `/parallel-cleanup` prompt for focused cleanup review passes.
+
+### Changed
+- Consolidated the `oracle-executor` role into `worker`: `worker` now uses `openai-codex/gpt-5.3-codex` with high thinking and stricter approved-direction guardrails, while `researcher` and `context-builder` now use medium thinking.
+- Updated the bundled `scout` agent model/thinking defaults.
+- Hard-cut over grouped intercom bridge result delivery: with the bridge active, parent-side `pi-subagents` emits one grouped `subagent:result-intercom` message per foreground parent run (single, top-level parallel, or chain) and one per completed async result file. Acknowledged foreground delivery returns a compact receipt instead of duplicating full output in the normal tool result; unacknowledged delivery preserves the normal full output. Grouped messages include child intercom targets and full child summaries.
+
+### Fixed
+- Fixed status and manager row rendering so multiline or tabbed content cannot overflow table rows.
+
+### Removed
+- Removed the bundled `oracle-executor` agent and `/oracle-executor` prompt template in favor of using `worker` for approved oracle handoffs.
+
 ## [0.19.3] - 2026-04-27
 
 ### Changed

package/README.md

@@ -67,7 +67,7 @@ Run parallel reviewers on this diff. I want one focused on correctness, one on t
 ```
 
 ```text
-Implement this plan with oracle-executor. Afterward, run parallel reviewers, summarize their feedback, and apply the fixes that make sense.
+Have worker implement this approved plan. Afterward, run parallel reviewers, summarize their feedback, and apply the fixes that make sense.
 ```
 
 ```text
@@ -85,7 +85,7 @@ Those are ordinary Pi requests. Pi decides whether to call `subagent`, which age
 | Review a diff | “Use reviewer to review this diff.” |
 | Run parallel reviewers | “Run reviewers for correctness, tests, and cleanup.” |
 | Implement then review | “Implement this, then review it.” |
-| Execute a plan carefully | “Use oracle-executor to implement this plan, then run reviewers and apply the feedback.” |
+| Execute a plan carefully | “Have worker implement this approved plan, then run reviewers and apply the feedback.” |
 | Scout before planning | “Use scout to inspect the auth flow before planning.” |
 | Run in the background | “Run this in the background.” |
 | Browse agents | “Show me the available subagents.” |
@@ -102,11 +102,10 @@ The extension ships with builtin agents you can use immediately.
 | `scout` | Fast local codebase recon: relevant files, entry points, data flow, risks, and where another agent should start. |
 | `researcher` | Web/docs research with sources: official docs, specs, benchmarks, recent changes, and a concise research brief. |
 | `planner` | A concrete implementation plan from existing context. It should read and plan, not edit code. |
-| `worker` | General implementation work. It reads context or a plan, edits files, and runs validation when it can. |
+| `worker` | Implementation work, including approved oracle handoffs. It edits files, validates, and escalates unapproved decisions instead of guessing. |
 | `reviewer` | Code review and small fixes. It checks the implementation against the task/plan, tests, edge cases, and simplicity. |
 | `context-builder` | A stronger setup pass before planning: gathers code context and writes handoff material such as `context.md` and `meta-prompt.md`. |
 | `oracle` | A second opinion before acting. It challenges assumptions, catches drift, and recommends the safest next move without editing. |
-| `oracle-executor` | Careful implementation after a direction has been approved. It is the “go do the approved thing” agent. |
 | `delegate` | A lightweight general delegate when you want a child agent that behaves close to the parent session. |
 
 A simple rule of thumb: use `scout` before you understand the code, `researcher` before you trust external facts, `planner` before a bigger change, `worker` to implement, `reviewer` to check, and `oracle` when the decision itself feels risky.
@@ -184,7 +183,6 @@ The package includes reusable prompt templates for common workflows. You do not
 | `/parallel-review` | Launch fresh-context reviewers with distinct angles, then synthesize what to fix. |
 | `/parallel-research` | Combine `researcher` and `scout` for external evidence, local code context, and practical tradeoffs. |
 | `/gather-context-and-clarify` | Scout/research first, then ask the user the clarification questions that matter. |
-| `/oracle-executor` | Send an explicitly approved implementation task to `oracle-executor` with inherited context. |
 
 ## Optional pi-intercom companion
 
@@ -206,12 +204,12 @@ Run this implementation in the background. If the worker gets blocked or needs a
 Ask oracle to review this plan. If it sees a decision I need to make, have it ask me instead of assuming.
 ```
 
-The child can use two kinds of messages:
+The child can use two kinds of coordination messages:
 
 - `ask`: the child needs a decision or clarification from the parent session
 - `send`: the child sends a short update when blocked or explicitly asked for progress
 
-Routine completion does not go through intercom. The normal subagent result still comes back through `pi-subagents`.
+Child-side routine completion handoffs are still not expected. With the intercom bridge active, parent-side `pi-subagents` sends grouped completion results through `pi-intercom`: one grouped message per foreground parent `subagent` run and one per completed async result file. Acknowledged foreground delivery returns a compact receipt with artifact/session paths; if unacknowledged, 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 `/subagents-status`, interrupting the run, or nudging the child.
 
@@ -315,7 +313,7 @@ You can combine them in either order:
 /run reviewer "review this diff" --bg --fork
 ```
 
-The `oracle` and `oracle-executor` builtins are designed for an explicit decision loop. A typical pattern is to ask `oracle` for diagnosis and a recommended execution prompt, then only run `oracle-executor` after the main agent approves that direction.
+The `oracle` and `worker` builtins are designed for an explicit decision loop. A typical pattern is to ask `oracle` for diagnosis and a recommended execution prompt, then only run `worker` after the main agent approves that direction.
 
 ## Clarify and launch UI
 
@@ -386,7 +384,7 @@ Agent locations, lowest to highest priority:
 
 Project discovery also reads legacy `.agents/{name}.md` files. If both `.agents/` and `.pi/agents/` define the same project agent, `.pi/agents/` wins. Use `agentScope: "user" | "project" | "both"` to control discovery; `both` is the default and project definitions win name collisions.
 
-Builtin agents load at the lowest priority, so a user or project agent with the same name overrides them. `oracle` is an advisory reviewer that critiques direction and proposes an execution prompt without editing files. `oracle-executor` is an implementation escalator intended to run only after the main agent approves a course of action.
+Builtin agents load at the lowest priority, so a user or project agent with the same name overrides them. `oracle` is an advisory reviewer that critiques direction and proposes an execution prompt without editing files. `worker` is the implementation agent for normal tasks and approved oracle handoffs.
 
 The `researcher` builtin uses `web_search`, `fetch_content`, and `get_search_content`; those require [pi-web-access](https://github.com/nicobailon/pi-web-access):
 
@@ -939,7 +937,12 @@ Async events:
 - `subagent:async-started`
 - `subagent:async-complete`
 
-The result watcher emits `subagent:async-complete`; `index.ts` registers the notification handler that consumes it. Control/attention events are surfaced as visible parent notices and persisted for async runs. With `pi-intercom`, needs-attention notices can also reach the orchestrator over intercom.
+Intercom delivery events:
+
+- `subagent:control-intercom`
+- `subagent:result-intercom`
+
+The result watcher emits `subagent:async-complete`; `index.ts` registers the notification handler that consumes it. Control/attention events are surfaced as visible parent notices and persisted for async runs. With `pi-intercom`, needs-attention notices and grouped parent-side subagent result deliveries can reach the orchestrator over intercom.
 
 ## Prompt-template integration
 

package/agents/context-builder.md

@@ -3,6 +3,7 @@ name: context-builder
 description: Analyzes requirements and codebase, generates context and meta-prompt
 tools: read, grep, find, ls, bash, write, web_search
 model: openai-codex/gpt-5.5
+thinking: medium
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false

package/agents/oracle.md

@@ -17,7 +17,7 @@ Before you do anything else, reconstruct the key inherited decisions, constraint
 
 If you need clarification from the main agent, use `intercom`. If runtime bridge instructions are present, use them as the source of truth for which orchestrator session to contact and how to phrase coordination.
 
-Use `intercom({ action: "ask", ... })` when you need a real decision or clarification. Use `intercom({ action: "send", ... })` for concise conversational handoffs during the review and for a short final recommendation before you return your full result. Keep intercom traffic tight and purposeful. Do not narrate your whole review through intercom, but do treat `intercom` as the preferred path for back-and-forth with the orchestrator when bridge instructions are available.
+Use `intercom({ action: "ask", ... })` when you need a real decision or clarification. Use `intercom({ action: "send", ... })` only for concise updates when blocked, explicitly asked for progress, or when a recommendation or concern would benefit from immediate discussion. Keep intercom traffic tight and purposeful. Do not narrate your whole review through intercom, and do not send routine completion handoffs.
 
 Core responsibilities:
 - reconstruct inherited decisions, constraints, and open questions from the context
@@ -32,7 +32,7 @@ Core responsibilities:
 What you do not do by default:
 - do not edit files or write code
 - do not propose additional parallel decision-makers or new subagent trees unless explicitly asked
-- do not assume an `oracle-executor` handoff is the default outcome
+- do not assume a `worker` implementation handoff is the default outcome
 - do not propose broad pivots unless the context clearly supports them
 - do not continue the user conversation directly
 
@@ -40,8 +40,7 @@ Working rules:
 - Use `bash` only for inspection, verification, or read-only analysis.
 - If information is missing and it matters, ask the main agent via `intercom` instead of guessing.
 - If the answer depends on a decision the main agent has not made yet, stop and ask via `intercom` before continuing.
-- When bridge instructions are present, send concise intercom messages when a recommendation, concern, or question would benefit from immediate discussion instead of waiting silently until the final return.
-- Before returning your full structured result, send a short intercom handoff summarizing the recommended next move when bridge instructions are present.
+- When bridge instructions are present, send concise intercom messages only when a recommendation, concern, or question would benefit from immediate discussion instead of waiting silently until the final return.
 - Prefer narrow, specific corrections to the current path over rewriting the whole plan.
 
 Your output should follow this shape. If no executor handoff is warranted, say so plainly.
@@ -70,5 +69,5 @@ Need from main agent:
 - specific question or decision required before continuing, if any
 
 Suggested execution prompt:
-- a concrete prompt for `oracle-executor`, only if an executor handoff is actually warranted
+- a concrete prompt for `worker`, only if an implementation handoff is actually warranted
 - if no handoff is warranted, say so explicitly

package/agents/researcher.md

@@ -3,6 +3,7 @@ name: researcher
 description: Autonomous web researcher — searches, evaluates, and synthesizes a focused research brief
 tools: read, write, web_search, fetch_content, get_search_content
 model: openai-codex/gpt-5.5
+thinking: medium
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false

package/agents/scout.md

@@ -2,7 +2,8 @@
 name: scout
 description: Fast codebase recon that returns compressed context for handoff
 tools: read, grep, find, ls, bash, write
-model: openai-codex/gpt-5.4-mini
+model: openai-codex/gpt-5.5
+thinking: medium
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false

package/agents/worker.md

@@ -1,7 +1,8 @@
 ---
 name: worker
-description: General-purpose subagent with full capabilities
-model: openai-codex/gpt-5.5
+description: Implementation agent for normal tasks and approved oracle handoffs
+model: openai-codex/gpt-5.3-codex
+thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false
@@ -9,36 +10,43 @@ defaultReads: context.md, plan.md
 defaultProgress: true
 ---
 
-You are an implementation subagent.
+You are `worker`: the implementation subagent.
 
-Use the provided tools directly to complete the task. Read the supplied context first, then make the smallest correct set of changes needed to finish the job.
+You are the single writer thread. Your job is to execute the assigned task or approved direction with narrow, coherent edits. The main agent and user remain the decision authority.
+
+Use the provided tools directly. First understand the inherited context, supplied files, plan, and explicit task. Then implement carefully and minimally.
+
+If the task is framed as an approved direction, oracle handoff, or execution plan, treat that direction as the contract. Validate it against the actual code, but do not silently make new product, architecture, or scope decisions.
+
+If the implementation reveals a decision that was not approved and is required to continue safely, pause and escalate. If runtime bridge instructions are present, use them as the source of truth for which parent session to contact and how to coordinate. Use `intercom({ action: "ask", ... })` when a new decision is needed. Use `intercom({ action: "send", ... })` only for concise blocked/progress updates when that extra coordination is helpful or explicitly requested.
+
+Default responsibilities:
+- validate the task or approved direction against the actual code
+- implement the smallest correct change
+- follow existing patterns in the codebase
+- verify the result with appropriate checks when possible
+- keep `progress.md` accurate when asked to maintain it
+- report back clearly with changes, validation, risks, and next steps
 
 Working rules:
-- Follow existing patterns in the codebase.
-- Prefer simple changes over clever ones.
-- Do not leave speculative scaffolding, placeholder code, or TODOs unless the task explicitly requires them.
-- Run relevant tests or validation commands when you can.
-- If you are asked to maintain progress, keep it accurate and up to date.
-- When you finish, summarize what changed, what you verified, and anything still unresolved.
+- Prefer narrow, correct changes over broad rewrites.
+- Do not add speculative scaffolding or future-proofing unless explicitly required.
+- Do not leave placeholder code, TODOs, or silent scope changes.
+- Use `bash` for inspection, validation, and relevant tests.
+- If there is supplied context or a plan, read it first.
+- If implementation reveals a gap in the approved direction, pause and escalate instead of silently patching around it with an implicit decision.
+- If implementation reveals an unapproved product or architecture choice, pause and ask instead of deciding it yourself.
+- If you send a blocked/progress update through intercom, keep it short and still return the full structured task result normally.
 
 When running in a chain, expect instructions about:
 - which files to read first
 - where to maintain progress tracking
 - where to write output if a file target is provided
 
-Suggested `progress.md` structure when asked to maintain it:
-
-# Progress
-
-## Status
-[In Progress | Completed | Blocked]
-
-## Tasks
-- [x] Completed task
-- [ ] Current task
-
-## Files Changed
-- `path/to/file.ts` - what changed
+Your final response should follow this shape:
 
-## Notes
-Key decisions, blockers, or follow-up items.
+Implemented X.
+Changed files: Y.
+Validation: Z.
+Open risks/questions: R.
+Recommended next step: N.

package/async-execution.ts

@@ -64,6 +64,7 @@ export interface AsyncExecutionContext {
 
 export interface AsyncChainParams {
 	chain: ChainStep[];
+	resultMode?: "parallel" | "chain";
 	agents: AgentConfig[];
 	ctx: AsyncExecutionContext;
 	availableModels?: AvailableModelInfo[];
@@ -345,6 +346,7 @@ export function executeAsyncChain(
 				controlConfig,
 				controlIntercomTarget,
 				childIntercomTargets,
+				resultMode: params.resultMode ?? "chain",
 			},
 			id,
 			runnerCwd,
@@ -484,6 +486,7 @@ export function executeAsyncSingle(
 				controlConfig,
 				controlIntercomTarget,
 				childIntercomTargets: childIntercomTarget ? [childIntercomTarget(agent, 0)] : undefined,
+				resultMode: "single",
 			},
 			id,
 			runnerCwd,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-subagents",
-  "version": "0.19.3",
+  "version": "0.20.1",
   "description": "Pi extension for delegating tasks to subagents with chains, parallel execution, and TUI clarification",
   "author": "Nico Bailon",
   "license": "MIT",

package/prompts/parallel-cleanup.md

@@ -0,0 +1,42 @@
+---
+description: Parallel cleanup review
+---
+
+Launch two fresh-context reviewer subagents for an adversarial cleanup review of the current work. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. Do not rely on this prompt as a substitute for reading the code.
+
+Reviewer 1: deslop pass.
+
+Ask this reviewer to look for AI-slop patterns in the changed scope:
+- comments that restate code, placeholder text, stale rationale, or debug leftovers;
+- defensive checks that hide useful errors, return vague defaults, or validate trusted internal data after a real boundary was already crossed;
+- type escapes, broad casts, duplicated type definitions, or object-bag typing where a local source-of-truth type exists;
+- style drift from nearby non-slop code and project instructions;
+- generated-sounding docs, changelog text, UI copy, status text, or test names;
+- pass-through wrappers, dead helpers, duplicate helper signatures, duplicated test harness setup, or abstractions that do not enforce an invariant;
+- UI or CLI copy that is noisy, vague, brittle, or makes the user do extra interpretation.
+
+Tell this reviewer to treat tool output and slop-scan-style findings as leads, not verdicts. It should flag only concrete issues in the requested scope with evidence, severity, file/line references, and the smallest safe fix.
+
+Reviewer 2: verbosity pass.
+
+Ask this reviewer to look for needless verbosity in code, tests, docs, status text, grouped messages, receipts, and changelog wording:
+- single-use helpers that merely paraphrase an expression;
+- temporary variables that only name obvious expressions;
+- nested returns or branches that can become direct returns without hiding intent;
+- multi-line cleanup scaffolding that can use a local direct pattern while preserving cleanup semantics;
+- repeated boilerplate that can use an existing local fixture or a small local helper;
+- tests that restate formatter details already covered at a cheaper layer;
+- prose that says the same thing twice, sounds generic, or buries the important rule.
+
+Tell this reviewer that shorter is only better when it is clearer and preserves behavior, error signals, cleanup semantics, useful invariants, and local style.
+
+Both reviewers are review-only. They must not edit files unless I explicitly ask for a writer pass. Their response should be review feedback, not a context summary. Ask them to return concise, evidence-backed findings with file/line references and suggested fixes.
+
+While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
+- fixes worth doing now;
+- optional improvements;
+- feedback to ignore or defer, with a short reason.
+
+Do not blindly apply every reviewer suggestion. Ask before applying fixes unless I already told you to address review feedback.
+
+$@

package/render-helpers.ts

@@ -1,5 +1,5 @@
 import type { Theme } from "@mariozechner/pi-coding-agent";
-import { visibleWidth } from "@mariozechner/pi-tui";
+import { truncateToWidth, visibleWidth } from "@mariozechner/pi-tui";
 
 function fuzzyScore(query: string, text: string): number {
 	const lq = query.toLowerCase();
@@ -37,7 +37,9 @@ export function pad(s: string, len: number): string {
 
 export function row(content: string, width: number, theme: Theme): string {
 	const innerW = width - 2;
-	return theme.fg("border", "│") + pad(content, innerW) + theme.fg("border", "│");
+	const singleLine = content.replace(/[\r\n]+/g, " ").replace(/\t/g, "  ");
+	const clipped = truncateToWidth(singleLine, innerW);
+	return theme.fg("border", "│") + pad(clipped, innerW) + theme.fg("border", "│");
 }
 
 export function renderHeader(text: string, width: number, theme: Theme): string {

package/result-intercom.ts

@@ -0,0 +1,235 @@
+import { randomUUID } from "node:crypto";
+import {
+	type Details,
+	type IntercomEventBus,
+	type SingleResult,
+	type SubagentResultIntercomChild,
+	type SubagentResultIntercomPayload,
+	type SubagentResultStatus,
+	SUBAGENT_RESULT_INTERCOM_DELIVERY_EVENT,
+	SUBAGENT_RESULT_INTERCOM_EVENT,
+} from "./types.ts";
+
+export function resolveSubagentResultStatus(input: {
+	exitCode?: number;
+	success?: boolean;
+	state?: string;
+	interrupted?: boolean;
+	detached?: boolean;
+}): SubagentResultStatus {
+	if (input.detached) return "detached";
+	if (input.interrupted || input.state === "paused") return "paused";
+	if (typeof input.success === "boolean") return input.success ? "completed" : "failed";
+	if (input.state === "complete") return "completed";
+	if (input.state === "failed") return "failed";
+	if (typeof input.exitCode === "number") return input.exitCode === 0 ? "completed" : "failed";
+	return "failed";
+}
+
+function countStatuses(children: SubagentResultIntercomChild[]): Record<SubagentResultStatus, number> {
+	const counts: Record<SubagentResultStatus, number> = {
+		completed: 0,
+		failed: 0,
+		paused: 0,
+		detached: 0,
+	};
+	for (const child of children) {
+		counts[child.status] += 1;
+	}
+	return counts;
+}
+
+function formatStatusCounts(counts: Record<SubagentResultStatus, number>): string {
+	const parts = [
+		counts.completed ? `${counts.completed} completed` : undefined,
+		counts.failed ? `${counts.failed} failed` : undefined,
+		counts.paused ? `${counts.paused} paused` : undefined,
+		counts.detached ? `${counts.detached} detached` : undefined,
+	].filter((part): part is string => Boolean(part));
+	return parts.length ? parts.join(", ") : "0 results";
+}
+
+function resolveGroupedStatus(children: SubagentResultIntercomChild[]): SubagentResultStatus {
+	const counts = countStatuses(children);
+	if (counts.failed > 0) return "failed";
+	if (counts.paused > 0) return "paused";
+	if (counts.completed > 0) return "completed";
+	if (counts.detached > 0) return "detached";
+	return "failed";
+}
+
+export interface GroupedResultIntercomMessageInput {
+	to: string;
+	runId: string;
+	mode: "single" | "parallel" | "chain";
+	source: "foreground" | "async";
+	children: SubagentResultIntercomChild[];
+	asyncId?: string;
+	asyncDir?: string;
+	chainSteps?: number;
+}
+
+export function formatSubagentResultIntercomMessage(input: {
+	runId: string;
+	mode: "single" | "parallel" | "chain";
+	status: SubagentResultStatus;
+	children: SubagentResultIntercomChild[];
+	asyncId?: string;
+	asyncDir?: string;
+	chainSteps?: number;
+}): string {
+	const counts = countStatuses(input.children);
+	const lines: string[] = [
+		"subagent results",
+		"",
+		`Run: ${input.runId}`,
+		`Mode: ${input.mode}`,
+		`Status: ${input.status}`,
+		`Children: ${formatStatusCounts(counts)}`,
+	];
+	if (input.mode === "chain" && typeof input.chainSteps === "number") {
+		lines.push(`Chain steps: ${input.chainSteps}`);
+	}
+	if (input.asyncId) lines.push(`Async id: ${input.asyncId}`);
+	if (input.asyncDir) lines.push(`Async dir: ${input.asyncDir}`);
+	if (input.children.some((child) => child.intercomTarget)) {
+		lines.push("");
+		lines.push("For clarification, message a listed subagent at its Intercom target.");
+	}
+
+	for (let index = 0; index < input.children.length; index++) {
+		const child = input.children[index]!;
+		lines.push("");
+		lines.push(`${index + 1}. ${child.agent} — ${child.status}`);
+		if (child.intercomTarget) lines.push(`Intercom target: ${child.intercomTarget}`);
+		if (child.artifactPath) lines.push(`Output artifact: ${child.artifactPath}`);
+		if (child.sessionPath) lines.push(`Session: ${child.sessionPath}`);
+		lines.push("Summary:");
+		lines.push(child.summary);
+	}
+
+	return lines.join("\n");
+}
+
+export function buildSubagentResultIntercomPayload(input: GroupedResultIntercomMessageInput): SubagentResultIntercomPayload {
+	const children = input.children.map((child) => ({
+		...child,
+		summary: child.summary.trim() || "(no output)",
+	}));
+	const status = resolveGroupedStatus(children);
+	const summary = formatStatusCounts(countStatuses(children));
+	const firstChild = children[0];
+	const payload: SubagentResultIntercomPayload = {
+		to: input.to,
+		runId: input.runId,
+		mode: input.mode,
+		status,
+		summary,
+		source: input.source,
+		children,
+		...(input.asyncId ? { asyncId: input.asyncId } : {}),
+		...(input.asyncDir ? { asyncDir: input.asyncDir } : {}),
+		...(typeof input.chainSteps === "number" ? { chainSteps: input.chainSteps } : {}),
+		...(firstChild?.agent ? { agent: firstChild.agent } : {}),
+		...(firstChild?.index !== undefined ? { index: firstChild.index } : {}),
+		...(firstChild?.artifactPath ? { artifactPath: firstChild.artifactPath } : {}),
+		...(firstChild?.sessionPath ? { sessionPath: firstChild.sessionPath } : {}),
+		message: "",
+	};
+	payload.message = formatSubagentResultIntercomMessage(payload);
+	return payload;
+}
+
+export async function deliverSubagentResultIntercomEvent(
+	events: IntercomEventBus,
+	payload: SubagentResultIntercomPayload,
+	timeoutMs = 500,
+): Promise<boolean> {
+	if (typeof events.on !== "function" || typeof events.emit !== "function") return false;
+	const requestId = payload.requestId ?? randomUUID();
+	return new Promise((resolve) => {
+		let settled = false;
+		let unsubscribe: (() => void) | undefined;
+		let timer: ReturnType<typeof setTimeout> | undefined;
+		const finish = (delivered: boolean) => {
+			if (settled) return;
+			settled = true;
+			if (timer) clearTimeout(timer);
+			unsubscribe?.();
+			resolve(delivered);
+		};
+		unsubscribe = events.on(SUBAGENT_RESULT_INTERCOM_DELIVERY_EVENT, (data) => {
+			if (!data || typeof data !== "object") return;
+			const delivery = data as { requestId?: unknown; delivered?: unknown };
+			if (delivery.requestId !== requestId) return;
+			finish(delivery.delivered === true);
+		});
+		timer = setTimeout(() => finish(false), timeoutMs);
+		try {
+			events.emit(SUBAGENT_RESULT_INTERCOM_EVENT, { ...payload, requestId });
+		} catch {
+			finish(false);
+		}
+	});
+}
+
+function stripSingleResultOutputs(result: SingleResult): SingleResult {
+	return {
+		...result,
+		messages: undefined,
+		finalOutput: undefined,
+		truncation: undefined,
+	};
+}
+
+export function stripDetailsOutputsForIntercomReceipt(details: Details): Details {
+	return {
+		...details,
+		results: details.results.map(stripSingleResultOutputs),
+	};
+}
+
+export function formatSubagentResultReceipt(input: {
+	mode: "single" | "parallel" | "chain";
+	runId: string;
+	payload: SubagentResultIntercomPayload;
+}): string {
+	const counts = countStatuses(input.payload.children);
+	const modeLabel = input.mode === "single"
+		? "single subagent result"
+		: input.mode === "parallel"
+			? "parallel subagent results"
+			: "chain subagent results";
+	const lines = [
+		`Delivered ${modeLabel} via intercom.`,
+		`Run: ${input.runId}`,
+		`Children: ${formatStatusCounts(counts)}`,
+	];
+
+	const artifacts = input.payload.children.filter((child) => typeof child.artifactPath === "string");
+	if (artifacts.length > 0) {
+		lines.push("Artifacts:");
+		for (const child of artifacts) {
+			lines.push(`- ${child.agent} [${child.status}]: ${child.artifactPath}`);
+		}
+	}
+
+	const intercomTargets = input.payload.children.filter((child) => typeof child.intercomTarget === "string");
+	if (intercomTargets.length > 0) {
+		lines.push("Intercom targets:");
+		for (const child of intercomTargets) {
+			lines.push(`- ${child.agent} [${child.status}]: ${child.intercomTarget}`);
+		}
+	}
+
+	const sessions = input.payload.children.filter((child) => typeof child.sessionPath === "string");
+	if (sessions.length > 0) {
+		lines.push("Sessions:");
+		for (const child of sessions) {
+			lines.push(`- ${child.agent} [${child.status}]: ${child.sessionPath}`);
+		}
+	}
+
+	lines.push("Full grouped output was sent over intercom.");
+	return lines.join("\n");
+}

package/result-watcher.ts

@@ -1,9 +1,17 @@
 import * as fs from "node:fs";
 import * as path from "node:path";
 import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
-import { buildCompletionKey, markSeenWithTtl } from "./completion-dedupe.js";
-import { createFileCoalescer } from "./file-coalescer.js";
-import { SUBAGENT_ASYNC_COMPLETE_EVENT, type SubagentState } from "./types.js";
+import { buildCompletionKey, markSeenWithTtl } from "./completion-dedupe.ts";
+import { createFileCoalescer } from "./file-coalescer.ts";
+import {
+	SUBAGENT_ASYNC_COMPLETE_EVENT,
+	type SubagentState,
+} from "./types.ts";
+import {
+	buildSubagentResultIntercomPayload,
+	deliverSubagentResultIntercomEvent,
+	resolveSubagentResultStatus,
+} from "./result-intercom.ts";
 
 function isNotFoundError(error: unknown): boolean {
 	return typeof error === "object"
@@ -22,13 +30,30 @@ export function createResultWatcher(
 	primeExistingResults: () => void;
 	stopResultWatcher: () => void;
 } {
-	const handleResult = (file: string) => {
+	const handleResult = async (file: string) => {
 		const resultPath = path.join(resultsDir, file);
 		if (!fs.existsSync(resultPath)) return;
 		try {
 			const data = JSON.parse(fs.readFileSync(resultPath, "utf-8")) as {
+				id?: string;
+				runId?: string;
+				agent?: string;
+				success?: boolean;
+				state?: string;
+				mode?: string;
+				summary?: string;
+				results?: Array<{
+					agent?: string;
+					output?: string;
+					success?: boolean;
+					artifactPaths?: { outputPath?: string };
+					intercomTarget?: string;
+				}>;
 				sessionId?: string;
 				cwd?: string;
+				sessionFile?: string;
+				asyncDir?: string;
+				intercomTarget?: string;
 			};
 			if (data.sessionId && data.sessionId !== state.currentSessionId) return;
 			if (!data.sessionId && data.cwd && data.cwd !== state.baseCwd) return;
@@ -40,6 +65,45 @@ export function createResultWatcher(
 				return;
 			}
 
+			const intercomTarget = data.intercomTarget?.trim();
+			if (intercomTarget) {
+				const childResults = Array.isArray(data.results) && data.results.length > 0
+					? data.results
+					: [{
+						agent: data.agent,
+						output: data.summary,
+						success: data.success,
+					}];
+				const runId = data.runId ?? data.id ?? file.replace(/\.json$/i, "");
+				const mode = data.mode === "single" || data.mode === "parallel" || data.mode === "chain"
+					? data.mode
+					: childResults.length > 1 ? "chain" : "single";
+				const payload = buildSubagentResultIntercomPayload({
+					to: intercomTarget,
+					runId,
+					mode,
+					source: "async",
+					children: childResults.map((result = {}, index) => ({
+						agent: result.agent ?? data.agent ?? `step-${index + 1}`,
+						status: resolveSubagentResultStatus({
+							success: result.success,
+							state: data.state === "paused" || typeof result.success !== "boolean" ? data.state : undefined,
+						}),
+						summary: result.output ?? data.summary ?? "(no output)",
+						index,
+						artifactPath: result.artifactPaths?.outputPath,
+						sessionPath: data.sessionFile,
+						intercomTarget: result.intercomTarget,
+					})),
+					asyncId: data.id,
+					asyncDir: data.asyncDir,
+				});
+				const delivered = await deliverSubagentResultIntercomEvent(pi.events, payload);
+				if (!delivered) {
+					console.error(`Subagent async grouped result intercom delivery was not acknowledged for '${resultPath}'.`);
+				}
+			}
+
 			pi.events.emit(SUBAGENT_ASYNC_COMPLETE_EVENT, data);
 			fs.unlinkSync(resultPath);
 		} catch (error) {
@@ -48,7 +112,9 @@ export function createResultWatcher(
 		}
 	};
 
-	state.resultFileCoalescer = createFileCoalescer(handleResult, 50);
+	state.resultFileCoalescer = createFileCoalescer((file) => {
+		void handleResult(file);
+	}, 50);
 
 	const scheduleRestart = () => {
 		state.watcherRestartTimer = setTimeout(() => {

package/skills/pi-subagents/SKILL.md

@@ -16,7 +16,7 @@ agents into a workflow, or create/edit agents and chains on demand.
 ## When to Use
 
 - **Advisory review**: use fresh-context `reviewer` agents for adversarial code review, or fork to `oracle` when inherited decisions and drift matter
-- **Implementation handoff**: have `oracle` advise, then `oracle-executor` or `worker` implement only after an approved direction
+- **Implementation handoff**: have `oracle` advise, then `worker` implement only after an approved direction
 - **Recon and planning**: use `scout` or `context-builder`, then `planner`
 - **Parallel exploration**: run multiple non-conflicting tasks concurrently
 - **Long-running work**: launch async/background runs and inspect them later
@@ -43,7 +43,6 @@ Packaged prompt shortcuts are also available for repeatable workflows:
 - `/parallel-review` — fresh-context reviewers with distinct review angles, then synthesis
 - `/parallel-research` — combine `researcher` and `scout` for external evidence plus local code context
 - `/gather-context-and-clarify` — scout/research first, then ask the user clarifying questions with `interview`
-- `/oracle-executor` — send an explicitly approved implementation task to `oracle-executor`
 
 ## Builtin Agents
 
@@ -54,13 +53,12 @@ and user/project agents override builtins with the same name.
 |-------|---------|-------|------------------------|
 | `scout` | Fast codebase recon | `openai-codex/gpt-5.4-mini` | Writes `context.md` handoff material |
 | `planner` | Creates implementation plans | `openai-codex/gpt-5.5` | Writes `plan.md` |
-| `worker` | General implementation | `openai-codex/gpt-5.5` | Edits code directly |
+| `worker` | Implementation and approved oracle handoffs | `openai-codex/gpt-5.3-codex` | Single-writer implementation with decision escalation |
 | `reviewer` | Review-and-fix specialist | `openai-codex/gpt-5.5` | Can edit/fix reviewed code |
 | `context-builder` | Requirements/codebase handoff builder | `openai-codex/gpt-5.5` | Writes structured context files |
 | `researcher` | Web research brief generator | `openai-codex/gpt-5.5` | Writes `research.md` |
 | `delegate` | Lightweight generic delegate | inherits parent model | No fixed output; generic delegated work |
 | `oracle` | Decision-consistency advisory review | `openai-codex/gpt-5.5` | Advisory review, intercom coordination |
-| `oracle-executor` | Implementation after approval | `openai-codex/gpt-5.5` | Single-writer implementation after approval |
 
 Override builtin defaults before copying full agent files when a small tweak is enough.
 
@@ -282,7 +280,7 @@ The intended oracle loop is:
 2. `oracle` reviews direction, drift, assumptions, and risks
 3. `oracle` can coordinate back to the orchestrator via `intercom`
 4. the main agent decides what direction to approve
-5. only then should `oracle-executor` implement
+5. only then should `worker` implement
 
 ```typescript
 // Advisory review in a branched thread
@@ -294,7 +292,7 @@ subagent({
 
 // Implementation only after explicit approval
 subagent({
-  agent: "oracle-executor",
+  agent: "worker",
   task: "Implement the approved approach: ...",
   context: "fork"
 })
@@ -319,7 +317,7 @@ Use `intercom` when:
 Message conventions:
 - `ask` means the child needs a decision or clarification from the parent session.
 - `send` means a short blocked/progress update, only when blocked or explicitly asked.
-- Routine completion does not go through intercom. The normal subagent result still returns through `pi-subagents`.
+- Child-side routine completion handoffs are not expected. With the intercom bridge active, parent-side `pi-subagents` sends grouped completion results through `pi-intercom`: one grouped message per foreground parent run and one per completed async result file. Acknowledged foreground delivery returns a compact receipt with artifact/session paths; if unacknowledged, the normal full output is preserved. Grouped messages include child intercom targets and full child summaries.
 
 If a bridge target is available, a child can ask:
 
@@ -426,9 +424,8 @@ copying a full builtin file.
 ## Prompt Template Integration
 
 The package includes prompt shortcuts for common workflows: `/parallel-review`,
-`/parallel-research`, `/gather-context-and-clarify`, and `/oracle-executor`.
-Use them when the user wants repeatable review, research, clarification, or
-approved execution patterns.
+`/parallel-research`, and `/gather-context-and-clarify`. Use them when the user
+wants repeatable review, research, or clarification patterns.
 
 If `pi-prompt-template-model` is installed, additional user prompt templates can delegate into
 `pi-subagents`. This is useful when a slash command should always run through a
@@ -453,8 +450,7 @@ particular agent or with forked context.
 ### Keep writes single-threaded by default
 
 A strong pattern is one main decision-maker plus advisory/research/review
-subagents around it. Use `oracle` for advice and `oracle-executor` or `worker`
-for the actual write path.
+subagents around it. Use `oracle` for advice and `worker` for the actual write path.
 
 ### Use fork for branched advisory or execution threads
 

package/subagent-executor.ts

@@ -32,6 +32,13 @@ import { applyIntercomBridgeToAgent, INTERCOM_BRIDGE_MARKER, resolveIntercomBrid
 import { formatControlIntercomMessage, formatControlNoticeMessage, resolveControlConfig, shouldNotifyControlEvent } from "./subagent-control.ts";
 import { finalizeSingleOutput, injectSingleOutputInstruction, resolveSingleOutputPath } from "./single-output.ts";
 import { compactForegroundDetails, getSingleResultOutput, mapConcurrent, readStatus, resolveChildCwd } from "./utils.ts";
+import {
+	buildSubagentResultIntercomPayload,
+	deliverSubagentResultIntercomEvent,
+	formatSubagentResultReceipt,
+	resolveSubagentResultStatus,
+	stripDetailsOutputsForIntercomReceipt,
+} from "./result-intercom.ts";
 import { inspectSubagentStatus } from "./run-status.ts";
 import { applyForceTopLevelAsyncOverride } from "./top-level-async.ts";
 import {
@@ -261,6 +268,64 @@ function createForegroundControlNotifier(data: Pick<ExecutionContextData, "contr
 	});
 }
 
+async function emitForegroundResultIntercom(input: {
+	pi: ExtensionAPI;
+	intercomBridge: IntercomBridgeState;
+	runId: string;
+	mode: "single" | "parallel" | "chain";
+	results: SingleResult[];
+	chainSteps?: number;
+}): Promise<ReturnType<typeof buildSubagentResultIntercomPayload> | null> {
+	if (!input.intercomBridge.active || !input.intercomBridge.orchestratorTarget) return null;
+	const children = input.results.flatMap((result, index) => result.detached ? [] : [{
+		agent: result.agent,
+		status: resolveSubagentResultStatus({
+			exitCode: result.exitCode,
+			interrupted: result.interrupted,
+			detached: result.detached,
+		}),
+		summary: getSingleResultOutput(result) || result.error || "(no output)",
+		index,
+		artifactPath: result.artifactPaths?.outputPath,
+		sessionPath: result.sessionFile,
+		intercomTarget: resolveSubagentIntercomTarget(input.runId, result.agent, index),
+	}]);
+	if (children.length === 0) return null;
+	const payload = buildSubagentResultIntercomPayload({
+		to: input.intercomBridge.orchestratorTarget,
+		runId: input.runId,
+		mode: input.mode,
+		source: "foreground",
+		children,
+		...(typeof input.chainSteps === "number" ? { chainSteps: input.chainSteps } : {}),
+	});
+	const delivered = await deliverSubagentResultIntercomEvent(input.pi.events, payload);
+	if (!delivered) return null;
+	return payload;
+}
+
+async function maybeBuildForegroundIntercomReceipt(input: {
+	pi: ExtensionAPI;
+	intercomBridge: IntercomBridgeState;
+	runId: string;
+	mode: "single" | "parallel" | "chain";
+	details: Details;
+}): Promise<{ text: string; details: Details } | null> {
+	const payload = await emitForegroundResultIntercom({
+		pi: input.pi,
+		intercomBridge: input.intercomBridge,
+		runId: input.runId,
+		mode: input.mode,
+		results: input.details.results,
+		...(typeof input.details.totalSteps === "number" ? { chainSteps: input.details.totalSteps } : {}),
+	});
+	if (!payload) return null;
+	return {
+		text: formatSubagentResultReceipt({ mode: input.mode, runId: input.runId, payload }),
+		details: stripDetailsOutputsForIntercomReceipt(input.details),
+	};
+}
+
 function validateExecutionInput(
 	params: SubagentParamsLike,
 	agents: AgentConfig[],
@@ -563,6 +628,7 @@ function runAsyncPath(data: ExecutionContextData, deps: ExecutorDeps): AgentTool
 				concurrency: resolveTopLevelParallelConcurrency(params.concurrency, deps.config.parallel?.concurrency),
 				worktree: params.worktree,
 			}],
+			resultMode: "parallel",
 			agents,
 			ctx: asyncCtx,
 			availableModels,
@@ -746,6 +812,24 @@ async function runChainPath(data: ExecutionContextData, deps: ExecutorDeps): Pro
 		});
 	}
 
+	const chainDetails = chainResult.details ? compactForegroundDetails(chainResult.details) : undefined;
+	const intercomReceipt = chainDetails && !chainDetails.results.some((result) => result.interrupted)
+		? await maybeBuildForegroundIntercomReceipt({
+			pi: deps.pi,
+			intercomBridge: data.intercomBridge,
+			runId,
+			mode: "chain",
+			details: chainDetails,
+		})
+		: null;
+	if (intercomReceipt) {
+		return {
+			...chainResult,
+			content: [{ type: "text", text: intercomReceipt.text }],
+			details: intercomReceipt.details,
+		};
+	}
+
 	return chainResult;
 }
 
@@ -1120,6 +1204,7 @@ async function runParallelPath(data: ExecutionContextData, deps: ExecutorDeps):
 			}));
 			return executeAsyncChain(id, {
 				chain: [{ parallel: parallelTasks, concurrency: parallelConcurrency, worktree: params.worktree }],
+				resultMode: "parallel",
 				agents,
 				ctx: asyncCtx,
 				availableModels,
@@ -1216,15 +1301,30 @@ async function runParallelPath(data: ExecutionContextData, deps: ExecutorDeps):
 		}
 
 		const interrupted = results.find((result) => result.interrupted);
+		const details = compactForegroundDetails({
+			mode: "parallel",
+			results,
+			progress: params.includeProgress ? allProgress : undefined,
+			artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
+		});
 		if (interrupted) {
 			return {
 				content: [{ type: "text", text: `Parallel run paused after interrupt (${interrupted.agent}). Waiting for explicit next action.` }],
-				details: compactForegroundDetails({
-					mode: "parallel",
-					results,
-					progress: params.includeProgress ? allProgress : undefined,
-					artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
-				}),
+				details,
+			};
+		}
+
+		const intercomReceipt = await maybeBuildForegroundIntercomReceipt({
+			pi: deps.pi,
+			intercomBridge: data.intercomBridge,
+			runId,
+			mode: "parallel",
+			details,
+		});
+		if (intercomReceipt) {
+			return {
+				content: [{ type: "text", text: intercomReceipt.text }],
+				details: intercomReceipt.details,
 			};
 		}
 
@@ -1248,12 +1348,7 @@ async function runParallelPath(data: ExecutionContextData, deps: ExecutorDeps):
 
 		return {
 			content: [{ type: "text", text: fullContent }],
-			details: compactForegroundDetails({
-				mode: "parallel",
-				results,
-				progress: params.includeProgress ? allProgress : undefined,
-				artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
-			}),
+			details,
 		};
 	} finally {
 		if (worktreeSetup) cleanupWorktrees(worktreeSetup);
@@ -1472,54 +1567,54 @@ async function runSinglePath(data: ExecutionContextData, deps: ExecutorDeps): Pr
 		savedPath: r.savedOutputPath,
 		saveError: r.outputSaveError,
 	});
+	const details = compactForegroundDetails({
+		mode: "single",
+		results: [r],
+		progress: params.includeProgress ? allProgress : undefined,
+		artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
+		truncation: r.truncation,
+	});
+
+	if (!r.detached && !r.interrupted) {
+		const intercomReceipt = await maybeBuildForegroundIntercomReceipt({
+			pi: deps.pi,
+			intercomBridge: data.intercomBridge,
+			runId,
+			mode: "single",
+			details,
+		});
+		if (intercomReceipt) {
+			return {
+				content: [{ type: "text", text: intercomReceipt.text }],
+				details: intercomReceipt.details,
+				...(r.exitCode !== 0 ? { isError: true } : {}),
+			};
+		}
+	}
 
 	if (r.detached) {
 		return {
 			content: [{ type: "text", text: `Detached for intercom coordination: ${params.agent}` }],
-			details: compactForegroundDetails({
-				mode: "single",
-				results: [r],
-				progress: params.includeProgress ? allProgress : undefined,
-				artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
-				truncation: r.truncation,
-			}),
+			details,
 		};
 	}
 
 	if (r.interrupted) {
 		return {
 			content: [{ type: "text", text: `Run paused after interrupt (${params.agent}). Waiting for explicit next action.` }],
-			details: compactForegroundDetails({
-				mode: "single",
-				results: [r],
-				progress: params.includeProgress ? allProgress : undefined,
-				artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
-				truncation: r.truncation,
-			}),
+			details,
 		};
 	}
 
 	if (r.exitCode !== 0)
 		return {
 			content: [{ type: "text", text: r.error || "Failed" }],
-			details: compactForegroundDetails({
-				mode: "single",
-				results: [r],
-				progress: params.includeProgress ? allProgress : undefined,
-				artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
-				truncation: r.truncation,
-			}),
+			details,
 			isError: true,
 		};
 	return {
 		content: [{ type: "text", text: finalizedOutput.displayOutput || "(no output)" }],
-		details: compactForegroundDetails({
-			mode: "single",
-			results: [r],
-			progress: params.includeProgress ? allProgress : undefined,
-			artifacts: allArtifactPaths.length ? { dir: artifactsDir, files: allArtifactPaths } : undefined,
-			truncation: r.truncation,
-		}),
+		details,
 	};
 }
 

package/subagent-runner.ts

@@ -75,6 +75,7 @@ interface SubagentRunConfig {
 	controlConfig?: ResolvedControlConfig;
 	controlIntercomTarget?: string;
 	childIntercomTargets?: Array<string | undefined>;
+	resultMode?: "single" | "parallel" | "chain";
 }
 
 interface StepResult {
@@ -82,6 +83,7 @@ interface StepResult {
 	output: string;
 	success: boolean;
 	skipped?: boolean;
+	intercomTarget?: string;
 	model?: string;
 	attemptedModels?: string[];
 	modelAttempts?: ModelAttempt[];
@@ -542,6 +544,7 @@ async function runSingleStep(
 	modelAttempts?: ModelAttempt[];
 	artifactPaths?: ArtifactPaths;
 	interrupted?: boolean;
+	intercomTarget?: string;
 }> {
 	const placeholderRegex = new RegExp(ctx.placeholder.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"), "g");
 	const task = step.task.replace(placeholderRegex, () => ctx.previousOutput);
@@ -671,6 +674,7 @@ async function runSingleStep(
 		output: outputForSummary,
 		exitCode: finalResult?.exitCode ?? 1,
 		error: finalResult?.error,
+		intercomTarget: ctx.childIntercomTarget,
 		model: finalResult?.model,
 		attemptedModels: attemptedModels.length > 0 ? attemptedModels : undefined,
 		modelAttempts,
@@ -1147,6 +1151,7 @@ async function runSubagent(config: SubagentRunConfig): Promise<void> {
 						output: pr.output,
 						success: pr.exitCode === 0,
 						skipped: pr.skipped,
+						intercomTarget: pr.intercomTarget,
 						model: pr.model,
 						attemptedModels: pr.attemptedModels,
 						modelAttempts: pr.modelAttempts,
@@ -1225,6 +1230,7 @@ async function runSubagent(config: SubagentRunConfig): Promise<void> {
 				agent: singleResult.agent,
 				output: singleResult.output,
 				success: singleResult.exitCode === 0,
+				intercomTarget: singleResult.intercomTarget,
 				model: singleResult.model,
 				attemptedModels: singleResult.attemptedModels,
 				modelAttempts: singleResult.modelAttempts,
@@ -1386,6 +1392,7 @@ async function runSubagent(config: SubagentRunConfig): Promise<void> {
 		writeJson(resultPath, {
 			id,
 			agent: agentName,
+			mode: config.resultMode ?? statusPayload.mode,
 			success: !interrupted && results.every((r) => r.success),
 			state: interrupted ? "paused" : results.every((r) => r.success) ? "complete" : "failed",
 			summary: interrupted ? "Paused after interrupt. Waiting for explicit next action." : summary,
@@ -1394,6 +1401,7 @@ async function runSubagent(config: SubagentRunConfig): Promise<void> {
 				output: r.output,
 				success: r.success,
 				skipped: r.skipped || undefined,
+				intercomTarget: r.intercomTarget,
 				model: r.model,
 				attemptedModels: r.attemptedModels,
 				modelAttempts: r.modelAttempts,
@@ -1409,6 +1417,7 @@ async function runSubagent(config: SubagentRunConfig): Promise<void> {
 			asyncDir,
 			sessionId: config.sessionId,
 			sessionFile: effectiveSessionFile,
+			intercomTarget: config.controlIntercomTarget,
 			shareUrl,
 			gistUrl,
 			shareError,

package/types.ts

@@ -69,6 +69,37 @@ export interface ControlEvent {
 	message: string;
 }
 
+export type SubagentResultStatus = "completed" | "failed" | "paused" | "detached";
+
+export interface SubagentResultIntercomChild {
+	agent: string;
+	status: SubagentResultStatus;
+	summary: string;
+	index?: number;
+	artifactPath?: string;
+	sessionPath?: string;
+	intercomTarget?: string;
+}
+
+export interface SubagentResultIntercomPayload {
+	to: string;
+	message: string;
+	requestId?: string;
+	runId: string;
+	mode: "single" | "parallel" | "chain";
+	status: SubagentResultStatus;
+	summary: string;
+	source: "foreground" | "async";
+	children: SubagentResultIntercomChild[];
+	asyncId?: string;
+	asyncDir?: string;
+	chainSteps?: number;
+	agent?: string;
+	index?: number;
+	artifactPath?: string;
+	sessionPath?: string;
+}
+
 // ============================================================================
 // Progress Tracking
 // ============================================================================
@@ -310,6 +341,8 @@ export const SUBAGENT_ASYNC_STARTED_EVENT = "subagent:async-started";
 export const SUBAGENT_ASYNC_COMPLETE_EVENT = "subagent:async-complete";
 export const SUBAGENT_CONTROL_EVENT = "subagent:control-event";
 export const SUBAGENT_CONTROL_INTERCOM_EVENT = "subagent:control-intercom";
+export const SUBAGENT_RESULT_INTERCOM_EVENT = "subagent:result-intercom";
+export const SUBAGENT_RESULT_INTERCOM_DELIVERY_EVENT = "subagent:result-intercom-delivery";
 
 // ============================================================================
 // Execution Options

package/agents/oracle-executor.md

@@ -1,49 +0,0 @@
----
-name: oracle-executor
-description: High-context implementation agent that executes only after main-agent approval
-tools: read, grep, find, ls, bash, edit, write, intercom
-model: openai-codex/gpt-5.5
-thinking: high
-systemPromptMode: replace
-inheritProjectContext: true
-inheritSkills: false
-defaultProgress: true
----
-
-You are `oracle-executor`: a high-context implementation subagent.
-
-You are the single writer thread. Your job is to execute approved direction, not to make new architectural or product decisions.
-
-You are invoked after the main agent has already decided on a direction, often based on advice from `oracle`. You are allowed to act, but you are not the owner of product or architecture decisions. The main agent remains the final decision authority.
-
-If runtime bridge instructions are present, use them as the source of truth for which orchestrator session to contact and how to coordinate. Use `intercom({ action: "ask", ... })` when a new decision is needed to continue safely. Use `intercom({ action: "send", ... })` for concise progress or completion handoffs when that extra coordination is helpful.
-
-First understand the inherited context and the explicit task. Then execute carefully and minimally.
-
-If the task appears to require a new decision that has not clearly been approved by the main agent, stop and ask via `intercom` instead of making that decision yourself.
-
-Default responsibilities:
-- validate the approved direction against the actual code
-- implement the approved change with minimal, coherent edits
-- verify the result with appropriate checks
-- report back clearly, including risks and next steps
-
-Working rules:
-- Follow existing patterns in the codebase.
-- Prefer narrow, correct changes over broad rewrites.
-- Do not add speculative scaffolding or future-proofing unless explicitly required.
-- Use `bash` for inspection, validation, and relevant tests.
-- Escalate uncertainty to the main agent with `intercom` when needed.
-- If the implementation reveals a gap in the approved direction, pause and escalate via `intercom` rather than silently patching around it with an implicit decision.
-- If implementation reveals an unapproved product or architecture choice, pause and ask via `intercom` instead of deciding it yourself.
-- If you send a completion handoff through `intercom`, keep it short and still return the full structured task result normally.
-- Keep `progress.md` accurate when asked to maintain it.
-- Do not silently change the scope of the task.
-
-Your completion handoff should follow this exact shape:
-
-Implemented X.
-Changed files: Y.
-Validation: Z.
-Open risks/questions: R.
-Recommended next step: N.

package/prompts/oracle-executor.md

@@ -1,9 +0,0 @@
----
-description: Send an explicitly approved task to oracle-executor with full inherited context.
-subagent: oracle-executor
-inheritContext: true
----
-
-Launch the oracle-executor subagent with a strict implementation meta prompt that points it at the plan and asks it to execute:
-
-$@