@bastani/atomic 0.9.5 → 0.9.6-alpha.1

package/CHANGELOG.md

@@ -2,6 +2,14 @@
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Restored workflow-first Atomic guidance for non-trivial work with verifiable objectives and synchronized help/docs around rich inline TypeScript workflow authoring, including dynamic branching, fan-out, verification, candidate-selection, human-gate, child-workflow, and bounded-loop patterns.
+- Documented compositional workflow authoring in model prompts and onboarding/help surfaces, including importing bundled workflows from `@bastani/workflows/builtin`, nesting definitions with `ctx.workflow(...)`, and building deeper reusable workflow graphs within `maxDepth`.
+- Restored tool-driven bundled Intercom startup so foreground subagent launches and bridged child session startup no longer connect either session automatically; the model or user must invoke Intercom when coordination is needed.
+
 ## [0.9.5] - 2026-07-11
 
 ### Breaking Changes

package/dist/builtin/cursor/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Published a synchronized Atomic 0.9.6-alpha.1 prerelease for the Cursor provider package; no functional Cursor provider changes were made after 0.9.5.
+
 ## [0.9.5] - 2026-07-11
 
 ### Changed

package/dist/builtin/cursor/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/cursor",
-  "version": "0.9.5",
+  "version": "0.9.6-alpha.1",
   "private": true,
   "description": "Experimental first-party Atomic extension for Cursor OAuth, model discovery, and streaming provider registration.",
   "contributors": [
@@ -40,7 +40,7 @@
     }
   },
   "dependencies": {
-    "@bastani/atomic-natives": "0.9.5",
+    "@bastani/atomic-natives": "0.9.6-alpha.1",
     "@bufbuild/protobuf": "^2.12.1",
     "@earendil-works/pi-ai": "^0.80.6"
   }

package/dist/builtin/intercom/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to the `pi-intercom` extension will be documented in this fi
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Restored fully tool-driven Intercom connections: parent and bridged child sessions no longer import or connect to the broker merely because a subagent starts. The runtime now connects only when the model or user invokes an Intercom tool, command, shortcut, or relay.
+
 ## [0.9.5] - 2026-07-11
 
 ### Added

package/dist/builtin/intercom/README.md

@@ -24,7 +24,7 @@ Intercom also integrates with delegated subagents: child agents get a child-only
 
 ## In One Minute
 
-Interactive parents lazily connect to the tiny local broker when an Intercom tool is used or immediately before a foreground child launches; the launch waits for inbound handlers and broker readiness so child coordination is available from its first turn. Delegated foreground and background children with supervisor bridge metadata register before agent work begins. The lightweight extension avoids importing the heavy runtime for unused parent sessions, disabled sessions, and noninteractive management-only work, and concurrent tool callers share one import and connection attempt. Definition/control-only subagent actions (`list`, `get`, `create`, `update`, `delete`, `status`, `interrupt`, and `doctor`) do not warm Intercom; `resume` may relaunch or contact a child and therefore retains readiness gating. If optional Intercom import, broker startup, or connection fails, the parent or child session continues with a diagnostic and later calls may retry. Lazy broker state is leased to the active session generation and cleaned up on shutdown or replacement.
+Intercom connections are tool-driven. Parent and delegated child sessions keep the lightweight wrapper unloaded until the model or user invokes an Intercom tool, `/intercom`, or the `ALT+M` overlay. A bridged child receives its deterministic Intercom identity and `contact_supervisor` tool at startup, but invoking that tool establishes its broker connection; merely launching a foreground or background child does not connect either session. Concurrent first-use callers share one import and connection attempt, and lazy broker state is leased to the active session generation and cleaned up on shutdown or replacement.
 
 ## Install
 
@@ -34,7 +34,7 @@ Atomic bundles `@bastani/intercom` as a first-party extension; no separate insta
 pi install npm:pi-intercom
 ```
 
-Then restart Atomic or Pi. The extension registers the bundled `intercom` skill at startup. Interactive parents connect lazily on Intercom use or foreground-child launch, while bridged children connect before agent work begins; disabled sessions and noninteractive management-only operations do not load the heavy runtime or start the broker.
+Then restart Atomic or Pi. The extension registers the bundled `intercom` skill and lightweight tools at startup, but it does not connect the session until the model or user invokes Intercom.
 
 **Recommended:** Add this snippet to your project's `AGENTS.md` to help agents understand when to coordinate across sessions:
 
@@ -53,7 +53,7 @@ Coordinate with other local Atomic/pi sessions on related codebases. Use `/skill
 A session becomes intercom-connected when all of these are true:
 - the intercom extension is installed/bundled and loaded in that session
 - `enabled` is not set to `false` in `~/.atomic/agent/intercom/config.json` (Atomic) or the legacy `~/.pi/agent/intercom/config.json` fallback
-- the session has started or reloaded after the extension was installed
+- the model or user has invoked an Intercom tool, `/intercom`, or the `ALT+M` overlay in that session
 - the local broker is running or can be auto-started
 
 The session list only shows intercom-connected sessions, not every open Pi process on the machine.

package/dist/builtin/intercom/index-heavy.ts

@@ -37,7 +37,6 @@ export default function piIntercomExtension(pi: ExtensionAPI) {
   let reconnectTimer: NodeJS.Timeout | null = null;
   let reconnectPromise: Promise<IntercomClient> | null = null;
   let reconnectPromiseGeneration: number | null = null;
-  let startupConnectTimer: NodeJS.Timeout | null = null;
   let reconnectAttempt = 0;
   let shuttingDown = false;
   let disposed = true;
@@ -99,10 +98,6 @@ export default function piIntercomExtension(pi: ExtensionAPI) {
     if (reconnectTimer) clearTimeout(reconnectTimer);
     reconnectTimer = null;
   }
-  function clearStartupConnectTimer(): void {
-    if (startupConnectTimer) clearTimeout(startupConnectTimer);
-    startupConnectTimer = null;
-  }
   function clearInboundFlushTimer(): void {
     if (inboundFlushTimer) clearTimeout(inboundFlushTimer);
     inboundFlushTimer = null;
@@ -425,17 +420,13 @@ export default function piIntercomExtension(pi: ExtensionAPI) {
     incrementRuntimeGeneration: () => { runtimeGeneration += 1; foregroundDetachHandoff.reset(); return runtimeGeneration; },
     resetReconnectAttempt: () => { reconnectAttempt = 0; },
     clearReconnectTimer,
-    clearStartupConnectTimer,
     setRuntimeContext: (value) => { runtimeContext = value; },
     setCurrentSessionId: (value) => { currentSessionId = value; },
     setCurrentModel: (value) => { currentModel = value; },
     setSessionStartedAt: (value) => { sessionStartedAt = value; },
     setAgentRunning: (value) => { agentRunning = value; },
     activeTools,
-    setStartupConnectTimer: (value) => { startupConnectTimer = value; },
     getLiveContext,
-    ensureConnected,
-    scheduleReconnect,
     rejectReplyWaiter,
     replyTracker,
     pendingIdleMessages,
@@ -480,12 +471,4 @@ export default function piIntercomExtension(pi: ExtensionAPI) {
     ensureConnected,
     syncPresenceIdentity,
   });
-  return { enabled: config.enabled,
-    async awaitAutomaticBrokerReady(): Promise<void> {
-      if (config.enabled) await ensureConnected("startup");
-    },
-    async awaitForegroundBrokerReady(): Promise<void> {
-      if (config.enabled) await ensureConnected("tool");
-    },
-  };
 }

package/dist/builtin/intercom/index.ts

@@ -1,8 +1,7 @@
-import { APP_NAME, getEnvValue, type ExtensionAPI, type ExtensionContext, type SessionStartEvent, type ToolDefinition, type ToolExecutionStartEvent } from "@bastani/atomic";
+import { APP_NAME, getEnvValue, type ExtensionAPI, type ExtensionContext, type SessionStartEvent, type ToolDefinition } from "@bastani/atomic";
 import { Text } from "@earendil-works/pi-tui";
 import { Type } from "typebox";
 import { renderIntercomToolResult } from "./result-renderers.js";
-import { loadConfig } from "./config.js";
 import { executeHeavyTool, runHeavyCommand, type HeavyHandle } from "./lazy-tool-execution.js";
 import { assertCurrentLifecycleLease, createLifecycleLease, retainSettledLifecycleCleanup, retireLifecycleLease, SerializedLifecycleForwarder, type LifecycleLease } from "./lifecycle-lease.js";
 import { rejectLazyResultRelay } from "./lazy-subagent-ack.js";
@@ -13,7 +12,6 @@ import {
 	dispatchHandlers,
 	type CapturedHeavy,
 	type ForwardedEventMap,
-	type HeavyRuntimeReadiness,
 	type ToolRenderResultArgs,
 } from "./lazy-heavy-proxy.js";
 
@@ -34,22 +32,9 @@ type ActiveLifecycleState = {
 	modelSelect: LifecycleSnapshot<"model_select"> | null;
 };
 interface LightweightIntercomOptions {
-	importHeavy?: () => Promise<{ default: (pi: ExtensionAPI) => void | HeavyRuntimeReadiness | Promise<void | HeavyRuntimeReadiness> }>;
-	isEnabled?: () => boolean;
+	importHeavy?: () => Promise<{ default: (pi: ExtensionAPI) => void | Promise<void> }>;
 }
 
-const MANAGEMENT_ONLY_SUBAGENT_ACTIONS = new Set(["list", "get", "create", "update", "delete", "status", "interrupt", "doctor"]);
-
-function isInteractiveForegroundSubagentStart(event: ToolExecutionStartEvent, ctx: ExtensionContext): boolean {
-	if (!ctx.hasUI || event.toolName !== "subagent") return false;
-	if (!event.args || typeof event.args !== "object" || Array.isArray(event.args)) return true;
-	const args = event.args as { action?: unknown; async?: unknown };
-	const action = typeof args.action === "string" ? args.action.trim() : "";
-	if (action && MANAGEMENT_ONLY_SUBAGENT_ACTIONS.has(action)) return false;
-	return args.async !== true;
-}
-
-
 const SUBAGENT_CONTROL_INTERCOM_EVENT = "subagent:control-intercom";
 const SUBAGENT_RESULT_INTERCOM_EVENT = "subagent:result-intercom";
 
@@ -74,8 +59,6 @@ function renderHeavyToolResult(loadedHeavy: CapturedHeavy | null, name: string,
 	return renderIntercomToolResult(name, args);
 }
 export default function intercom(pi: ExtensionAPI, options: LightweightIntercomOptions = {}) {
-	const enabled = options.isEnabled?.() ?? loadConfig().enabled;
-	const delegatedSession = hasSubagentIntercomEnv();
 	const delegatedSessionName = readSubagentEnv("INTERCOM_SESSION_NAME");
 	let heavyAttempt: HeavyAttempt | null = null;
 	let loadedHeavy: IntercomHeavyHandle | null = null;
@@ -187,8 +170,7 @@ export default function intercom(pi: ExtensionAPI, options: LightweightIntercomO
 			try {
 				const mod = await (options.importHeavy?.() ?? import("./index-heavy.js"));
 				assertLease(lease);
-				const runtimeReadiness = await mod.default(createHeavyProxy(pi, captured));
-				if (runtimeReadiness) captured.runtimeReadiness = runtimeReadiness;
+				await mod.default(createHeavyProxy(pi, captured));
 				assertLease(lease);
 				if (!sessionSnapshot && ctx) {
 					sessionSnapshot = { event: createSyntheticSessionStartEvent(), ctx, generation: ++lifecycleGeneration, lease };
@@ -214,23 +196,6 @@ export default function intercom(pi: ExtensionAPI, options: LightweightIntercomO
 		);
 		return promise;
 	}
-	async function registerAutomatically(ctx: ExtensionContext, phase: string, foreground = false): Promise<boolean> {
-		try {
-			const handle = await loadHeavy(ctx);
-			const readiness = handle.heavy.runtimeReadiness;
-			if (!readiness) throw new Error("Intercom heavy runtime did not expose broker readiness");
-			if (readiness.enabled) {
-				if (foreground) await readiness.awaitForegroundBrokerReady();
-				else await readiness.awaitAutomaticBrokerReady();
-			}
-			handle.assertCurrent();
-			return readiness.enabled;
-		} catch (error) {
-			const message = error instanceof Error ? error.message : String(error);
-			console.error(`Intercom ${phase} failed; session will continue and a later call may retry: ${message}`, error);
-			return false;
-		}
-	}
 	pi.on("session_start", async (event, ctx) => {
 		if (delegatedSessionName && typeof pi.setSessionName === "function") pi.setSessionName(delegatedSessionName);
 		if (activeLease.retired) activeLease = createLifecycleLease<ShutdownSnapshot>(nextLeaseId++, activeLease.cleanupBarrier);
@@ -244,12 +209,7 @@ export default function intercom(pi: ExtensionAPI, options: LightweightIntercomO
 		}
 		const generation = ++lifecycleGeneration;
 		sessionSnapshot = { event, ctx, generation, lease };
-		if (loadedHeavy) {
-			await ensureSessionStartReplayed(loadedHeavy.heavy, lease);
-			return;
-		}
-		if (!enabled || (!ctx.hasUI && !delegatedSession)) return;
-		if (delegatedSession) await registerAutomatically(ctx, "bridged child automatic registration");
+		if (loadedHeavy) await ensureSessionStartReplayed(loadedHeavy.heavy, lease);
 	});
 	pi.on("session_shutdown", async (event, ctx) => {
 		const lease = activeLease;
@@ -307,28 +267,7 @@ export default function intercom(pi: ExtensionAPI, options: LightweightIntercomO
 	});
 	pi.on("tool_execution_start", async (event, ctx) => {
 		if (activeLease.retired) return;
-		const lease = activeLease;
-		const toolSnapshot: LifecycleSnapshot<"tool_execution_start"> = { event, ctx };
-		activeLifecycle.activeTools.set(event.toolCallId, toolSnapshot);
-		if (isInteractiveForegroundSubagentStart(event, ctx) && enabled) {
-			const session = sessionSnapshot;
-			const warmHeavy = loadedHeavy?.heavy ?? null;
-			const warmReplayComplete = warmHeavy !== null
-				&& session?.lease === lease
-				&& replayedGeneration === session.generation;
-			// Successful readiness gates launch; optional Intercom failures degrade
-			// without preventing the subagent tool itself from executing.
-			await registerAutomatically(ctx, "foreground parent warmup", true);
-			if (warmReplayComplete
-				&& activeLease === lease
-				&& !lease.retired
-				&& sessionSnapshot === session
-				&& activeLifecycle.activeTools.get(event.toolCallId) === toolSnapshot
-				&& loadedHeavy?.heavy === warmHeavy) {
-				await lifecycleForward.enqueue(() => dispatchHandlers(warmHeavy, "tool_execution_start", event, ctx));
-			}
-			return; // Cold initialization replay owns this active tool's delivery.
-		}
+		activeLifecycle.activeTools.set(event.toolCallId, { event, ctx });
 		const heavy = loadedHeavy?.heavy;
 		if (heavy) await lifecycleForward.enqueue(() => dispatchHandlers(heavy, "tool_execution_start", event, ctx));
 	});
@@ -367,8 +306,8 @@ export default function intercom(pi: ExtensionAPI, options: LightweightIntercomO
 			});
 		});
 	}
-	// Bridged children are registered synchronously by the primary session-start
-	// handler, before their first agent turn can send or receive intercom messages.
+	// Heavy Intercom state stays unloaded until the model or user invokes an
+	// Intercom tool, command, shortcut, or relay that needs it.
 	pi.registerTool({
 		name: "intercom",
 		label: "Intercom",

package/dist/builtin/intercom/lazy-heavy-proxy.ts

@@ -27,11 +27,6 @@ type LazyLifecycleEvent = keyof ForwardedEventMap;
 type ForwardedHandler<K extends LazyLifecycleEvent> = ExtensionHandler<ForwardedEventMap[K]>;
 type ForwardedHandlerMap = { [K in LazyLifecycleEvent]: ForwardedHandler<K>[] };
 type AnyForwardedHandler = { [K in LazyLifecycleEvent]: ForwardedHandler<K> }[LazyLifecycleEvent];
-export interface HeavyRuntimeReadiness {
-  enabled: boolean;
-  awaitAutomaticBrokerReady(): Promise<void>;
-  awaitForegroundBrokerReady(): Promise<void>;
-}
 
 export type CapturedHeavy = {
   tools: Map<string, ToolDefinition>;
@@ -39,7 +34,6 @@ export type CapturedHeavy = {
   handlers: ForwardedHandlerMap;
   shortcuts: Map<string, CapturedShortcut>;
   eventHandlers: Map<string, EventHandler[]>;
-  runtimeReadiness?: HeavyRuntimeReadiness;
 };
 
 export function createForwardedHandlerMap(): ForwardedHandlerMap {

package/dist/builtin/intercom/lifecycle.ts

@@ -14,17 +14,13 @@ interface LifecycleDeps {
   incrementRuntimeGeneration(): number;
   resetReconnectAttempt(): void;
   clearReconnectTimer(): void;
-  clearStartupConnectTimer(): void;
   setRuntimeContext(ctx: ExtensionContext | null): void;
   setCurrentSessionId(id: string | null): void;
   setCurrentModel(model: string): void;
   setSessionStartedAt(value: number | null): void;
   setAgentRunning(value: boolean): void;
   activeTools: Map<string, string>;
-  setStartupConnectTimer(timer: NodeJS.Timeout | null): void;
   getLiveContext(ctx?: ExtensionContext | null, generation?: number): ExtensionContext | null;
-  ensureConnected(reason: "startup"): Promise<IntercomClient>;
-  scheduleReconnect(): void;
   rejectReplyWaiter(error: Error): void;
   replyTracker: ReplyTracker;
   pendingIdleMessages: InboundMessageEntry[];
@@ -44,7 +40,6 @@ export function registerIntercomLifecycle(pi: ExtensionAPI, deps: LifecycleDeps)
     deps.setShuttingDown(true);
     deps.setDisposed(true);
     deps.incrementRuntimeGeneration();
-    deps.clearStartupConnectTimer();
     deps.clearReconnectTimer();
     deps.rejectReplyWaiter(new Error(reason));
     deps.replyTracker.reset();
@@ -74,25 +69,15 @@ export function registerIntercomLifecycle(pi: ExtensionAPI, deps: LifecycleDeps)
     deps.setShuttingDown(false);
     deps.setDisposed(false);
     deps.setRuntimeStarted(true);
-    const startupGeneration = deps.incrementRuntimeGeneration();
+    deps.incrementRuntimeGeneration();
     deps.resetReconnectAttempt();
     deps.clearReconnectTimer();
-    deps.clearStartupConnectTimer();
     deps.setRuntimeContext(ctx);
     deps.setCurrentSessionId(ctx.sessionManager.getSessionId());
     deps.setCurrentModel(ctx.model?.id ?? "unknown");
     deps.setSessionStartedAt(Date.now());
     deps.setAgentRunning(false);
     deps.activeTools.clear();
-    deps.setStartupConnectTimer(setTimeout(() => {
-      deps.setStartupConnectTimer(null);
-      if (!deps.getLiveContext(ctx, startupGeneration)) return;
-      void deps.ensureConnected("startup").catch(() => {
-        if (!deps.getLiveContext(ctx, startupGeneration)) return;
-        deps.setClient(null);
-        deps.scheduleReconnect();
-      });
-    }, 0));
   });
 
   pi.on("session_shutdown", async () => {

package/dist/builtin/intercom/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/intercom",
-  "version": "0.9.5",
+  "version": "0.9.6-alpha.1",
   "private": true,
   "description": "Atomic extension providing a private coordination channel between parent and child agent sessions. Fork of: https://github.com/nicobailon/pi-intercom",
   "contributors": [

package/dist/builtin/mcp/CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Published a synchronized Atomic 0.9.6-alpha.1 prerelease for the MCP extension; no functional MCP changes were made after 0.9.5.
+
 ## [0.9.5] - 2026-07-11
 
 ### Changed

package/dist/builtin/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/mcp",
-  "version": "0.9.5",
+  "version": "0.9.6-alpha.1",
   "private": true,
   "description": "Atomic extension that adapts MCP (Model Context Protocol) servers into the coding agent. Fork of: https://github.com/nicobailon/pi-mcp-adapter",
   "contributors": [

package/dist/builtin/subagents/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Aligned model-facing subagent guidance with workflow-first routing: subagents remain focused specialists inside workflow stages or bounded direct delegation, rather than becoming an ad hoc implementation/review/retry pipeline for workflow-fit work.
+- Changed bundled Intercom coordination back to model-driven connection: launching foreground or background children no longer connects the parent or child session automatically; an Intercom tool or UI action must establish each session's broker connection.
+
 ## [0.9.5] - 2026-07-11
 
 ### Added

package/dist/builtin/subagents/README.md

@@ -230,7 +230,7 @@ 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.
 
 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. Intercom-confirmed foreground 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. The separate in-process completion event keeps its legacy synchronous semantics: emission is accepted unless a listener explicitly rejects it during the call, and no listener is not treated as an error.
-When the companion is enabled and available, both foreground and background child sessions register with Intercom during session startup, before agent work can send or receive coordination messages. The interactive parent connects lazily, and a foreground launch waits for its broker/inbound-handler readiness before starting the child. Management-only `list`, `get`, `create`, `update`, `delete`, `status`, `interrupt`, and `doctor` actions do not launch a child and therefore do not force Intercom loading or broker startup; `resume` can relaunch or contact a child and retains readiness gating. If the optional companion cannot import, start its broker, or connect, subagent launch continues with diagnostics and a later call can retry.
+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/background launch and management-only actions do not force Intercom loading or broker startup.
 
 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 background or unmatched messages retain queued-until-idle behavior.
 

package/dist/builtin/subagents/package.json

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

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

@@ -423,7 +423,7 @@ subagent({
 
 ## Subagent + Intercom Coordination
 
-Atomic subagents work without intercom. When Atomic's bundled intercom companion or upstream `pi-intercom` is installed and enabled, the intercom bridge can automatically give child agents a private coordination channel back to the parent session.
+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 specialists in this skill do not declare the `intercom` tool, so they finish their pass and return without coordinating. They cannot pause to ask the parent for a decision mid-run; if you need that, write a custom agent that lists `intercom` (or that the runtime bridge can inject `contact_supervisor` into).
 

package/dist/builtin/subagents/src/extension/prompt-guidance.ts

@@ -1,10 +1,9 @@
 export const DEFAULT_PROMPT_GUIDANCE: string[] = [
-	`**Subagent orchestration**: Use subagents selectively for bounded specialist delegation while the parent remains in control.
-  - Keep interactive, exploratory, conceptual, and conversation-led work inline when direct discussion and user steering are more useful than delegation.
-  - Use a single subagent for a focused specialty, a chain for a bounded sequential handoff, or parallel tasks for independent work. Multiple steps, files, tests, validation, or parallelism alone do not require a workflow.
-  - Delegate noisy or context-heavy command investigation when isolation helps, but run concise commands inline when that is simpler. Do not split work with substantial overlap across independent subagents.
-  - Use async/background execution selectively for genuinely long-running or independently useful delegated work. Foreground execution is appropriate when the parent needs the result before proceeding; do not duplicate a delegated job while waiting.
-  - For clearly delegated, well-defined autonomous jobs that are likely long-running/background-oriented or materially need durable stages, checkpoints, resumability, human input, gates, retries, or bounded loops, prefer an appropriate workflow rather than stretching subagent orchestration into an ad hoc workflow.
-  - Debug conceptual questions or exploratory analysis inline when appropriate. Use the debugger subagent for actual failures that need reproduction, root-cause diagnosis, and a validated fix; additional debugger or research delegates are optional when they add a distinct useful angle.`,
+	`**Subagent orchestration**: Use subagents for focused specialist work inside workflows or as bounded delegation when a workflow would be unnecessary overhead.
+  - Because workflows are the default for non-trivial structured work with verifiable objectives, do not stretch parent-controlled subagent calls into an ad hoc implementation, review, or retry pipeline; use a workflow and let its stages delegate specialists.
+  - Use a single subagent for a focused specialty, a chain for a bounded sequential handoff, or parallel tasks for independent work. Keep substantial-overlap tasks together rather than duplicating investigation across agents.
+  - Delegate noisy or context-heavy command investigation when isolation helps, but run concise commands inline when that is simpler.
+  - Use async/background execution when delegated work is genuinely long-running or independently useful. Foreground execution is appropriate when the parent needs the result before proceeding; do not duplicate a delegated job while waiting.
+  - Use the debugger subagent for actual failures that need reproduction, root-cause diagnosis, and a validated fix; additional debugger or research delegates are optional when they add a distinct useful angle.`,
 ];
 

package/dist/builtin/web-access/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Published a synchronized Atomic 0.9.6-alpha.1 prerelease for the web-access extension; no functional web-access changes were made after 0.9.5.
+
 ## [0.9.5] - 2026-07-11
 
 ### Changed

package/dist/builtin/web-access/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/web-access",
-  "version": "0.9.5",
+  "version": "0.9.6-alpha.1",
   "private": true,
   "description": "Atomic extension for web search, URL fetching, GitHub repo cloning, PDF/video extraction. Fork of: https://github.com/nicobailon/pi-web-access",
   "contributors": [

package/dist/builtin/workflows/CHANGELOG.md

@@ -6,6 +6,14 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.9.6-alpha.1] - 2026-07-12
+
+### Changed
+
+- Restored workflow-first model routing for non-trivial, structured, and verifiable work while retaining the newer ability to author task-specific TypeScript workflows inline. Prompt guidance now explicitly combines the documented classify/branch, fan-out/synthesis, adversarial verification, generate/filter, tournament, and bounded loop patterns instead of forcing every workflow-fit task into an installed workflow, direct shape, or builtin.
+- Restored Ralph's builtin implementation-stage prompts to require subagent-led investigation, editing, and validation, reversing the selective direct-implementation wording introduced with intent-first routing.
+- Expanded model-facing workflow guidance to treat composition as a first-class design option: custom parents can import reusable project/package workflows or bundled builtin definitions, invoke them through `ctx.workflow(...)`, and nest further child workflows within `maxDepth` while preserving expanded graph visibility, HIL, durability, controls, and declared output contracts.
+
 ## [0.9.5] - 2026-07-11
 
 ### Breaking Changes

package/dist/builtin/workflows/README.md

@@ -5,7 +5,7 @@
   An open-source Atomic workflow extension: install it, author workflows in TypeScript, run them from chat.
 </p>
 
-Use the least orchestration that fits the user's intent: keep interactive/exploratory work inline, use bounded single/chain/parallel subagents while the parent remains in control, and use workflows for clearly delegated, well-defined autonomous jobs that are likely long-running/background-oriented or materially need durable stages, artifacts/checkpoints, resumability, HIL, gates, retries, or bounded loops. Multiple steps, files, tests, validation, or parallelism alone do not require a workflow. Loop or stop-condition requests such as `do X until Y`, `repeat until`, `iterate until`, `review/fix until passing`, `run checks and fix until green`, or `keep going until done` are key workflow signals when the user delegates execution because they already define control flow and a completion condition. When workflow execution fits, Atomic may always author a custom TypeScript `workflow({...})` inline with normal coding tools if that shape best achieves the task; it is not limited to installed workflows or direct modes. Named workflows can be builtin, project, user, or package supplied, and direct task/tasks/chain modes cover one-off tracked shapes.
+Default to workflows for non-trivial work and requests with inherent structure plus a verifiable objective; reserve direct chat for tiny deterministic low-risk work. Workflow-first is not builtin-only or monolithic: Atomic can author custom TypeScript `workflow({...})` definitions inline, import reusable project/package workflows or builtins from `@bastani/workflows/builtin`, and nest them with `ctx.workflow(...)`. Imported children may nest further workflows within `maxDepth`, so compose proven research, implementation, design, verification, and approval graphs rather than copying them. Custom parents can also use runtime classification, dynamic fan-out and synthesis, adversarial verification, candidate tournaments, HIL gates, and bounded convergence.
 
 <p align="center">
   <a href="#authoring-api">Authoring API</a>
@@ -552,12 +552,12 @@ Prompt answer replay is live-memory only. `StageSnapshot.promptAnswerState` repo
 
 ### `workflow` tool (LLM-callable)
 
-<!-- Keep the description below in sync with WORKFLOW_TOOL_DESCRIPTION in packages/workflows/src/extension/index.ts; integration tests assert this. -->
+<!-- Keep the description below in sync with WORKFLOW_TOOL_DESCRIPTION in packages/workflows/src/extension/workflow-prompts.ts; integration tests assert this. -->
 
 ```json
 {
   "name": "workflow",
-  "description": "Run named builtin, project, user, or package workflows, or direct one-off task/tasks/chain workflows; when workflow execution fits but another shape would better achieve the task, author a custom TypeScript workflow({...}) inline with normal coding tools, reload it, and run it; discover with list/get/inputs, inspect status/stages/stage details, send prompt answers or steering, pause/resume/interrupt/kill runs, and reload workflow resources. For large stage handoffs, write context to files/artifacts, pass paths via reads, and prompt downstream agents to 'Read the file at <path>...' instead of injecting large previous text. For transcripts, prefer status/stages/stage to get sessionFile/transcriptPath, quote the exact path without rewriting separators (Windows backslashes are valid), then search it with rg/grep and read small ranges; transcript is path-only by default when sessionFile/transcriptPath exists, explicit tail/limit returns bounded previews, and missing transcript paths fall back to a small preview.",
+  "description": "Run named builtin, project, user, or package workflows, or direct one-off task/tasks/chain workflows; custom definitions may import reusable project/package workflows or builtin definitions from @bastani/workflows/builtin and nest them with ctx.workflow(...), including deeper composition within the configured maxDepth; when workflow execution fits but another shape would better achieve the task, author a custom TypeScript workflow({...}) inline with normal coding tools, reload it, and run it; discover with list/get/inputs, inspect status/stages/stage details, send prompt answers or steering, pause/resume/interrupt/kill runs, and reload workflow resources. For large stage handoffs, write context to files/artifacts, pass paths via reads, and prompt downstream agents to 'Read the file at <path>...' instead of injecting large previous text. For transcripts, prefer status/stages/stage to get sessionFile/transcriptPath, quote the exact path without rewriting separators (Windows backslashes are valid), then search it with rg/grep and read small ranges; transcript is path-only by default when sessionFile/transcriptPath exists, explicit tail/limit returns bounded previews, and missing transcript paths fall back to a small preview.",
   "parameters": {
     "workflow": "string (optional) — workflow ID or normalized name",
     "inputs": "object (optional) — key/value map of workflow inputs",

package/dist/builtin/workflows/builtin/ralph-core.ts

@@ -434,10 +434,10 @@ export function renderForkedOrchestratorPrompt(args: {
     [
       "output_format",
       [
-        "After the implementation work is complete, return Markdown with headings:",
+        "After subagents have done the work, return Markdown with headings:",
         "1. Research file — the path you read",
-        "2. Delegations performed — subagents used and what each completed, or none when direct work was sufficient",
-        "3. Changes made — concrete completed changes, not intentions",
+        "2. Delegations performed — subagents spawned and what each completed",
+        "3. Changes made — concrete changes from subagent work, not intentions",
         "4. Files touched",
         "5. Validation run / recommended",
         "6. Deferred work or blockers",