pi-workflow-engine 0.3.0 → 0.5.0

package/README.md

@@ -2,7 +2,7 @@
 
 # pi-workflow-engine
 
-Claude Code style workflows for the [pi](https://pi.dev) coding agent.
+Programmable multi-agent workflows for the [pi](https://pi.dev) coding agent.
 
 This is not just a way to run a prompt. It is a way to turn an agentic procedure into code: scope the task, fork isolated subagents, fan out across review lenses, validate every handoff with schemas, verify candidate findings, and synthesize one ranked result.
 
@@ -10,7 +10,7 @@ The built-in workflows are advisory: they inspect, fan out, verify, and report.
 
 ## Why workflows matter
 
-Claude Code popularised a useful pattern: the best agentic coding work is not a single chat turn. It is a loop of context gathering, delegated action, verification, and synthesis. Its docs describe the [agentic loop](https://code.claude.com/docs/en/glossary#agentic-loop), [skills and commands](https://code.claude.com/docs/en/skills), and [subagents](https://code.claude.com/docs/en/glossary#subagent) as composable building blocks for repeatable engineering work.
+The best agentic coding work is rarely a single chat turn. It is a repeatable loop of context gathering, delegated investigation, structured handoffs, verification, and synthesis.
 
 `pi-workflow-engine` brings that shape to pi with static TypeScript workflows:
 
@@ -35,7 +35,7 @@ Or from npm:
 pi install npm:pi-workflow-engine
 ```
 
-That's all. pi fetches the package and serves its core dependencies from its own bundle, so there is no clone, install, or build step. Restart pi, or run `/reload` in an open session, then confirm it is registered:
+That's all. pi fetches the package and serves its core dependencies from its own bundle, so there is no clone, install, or build step. The package entrypoint is the canonical pi extension module at `.pi/extensions/pi-workflow-engine/index.ts`. Restart pi, or run `/reload` in an open session, then confirm it is registered:
 
 ```bash
 pi list
@@ -55,6 +55,8 @@ pi remove git:github.com/timbrinded/pi-workflow-engine
 
 ## Usage
 
+For the complete installation, invocation, authoring, tuning, and troubleshooting guide, see [USAGE.md](USAGE.md).
+
 In a pi session, from inside a git repo with changes:
 
 ```text
@@ -64,15 +66,25 @@ In a pi session, from inside a git repo with changes:
 /workflow diagnose "typecheck fails after the schema change"
 /workflow perf-review "workflow startup latency"
 /workflow code-review --inspect  # open the live workflow inspector
-/workflow ping                   # quick engine smoke test
 ```
 
-The host agent can also invoke the `workflow` tool mid-conversation:
+The host agent can also invoke the `workflow` tool mid-conversation. It accepts either a registered workflow `name` or a one-off inline workflow `script`:
 
 ```text
 Run the code-review workflow on this PR and use the result before deciding what to fix.
 ```
 
+Opt into dynamic multi-agent orchestration with the literal `dynamax` token, or keep it sticky for the session:
+
+```text
+dynamax inspect this bug with multiple focused agents
+/dynamax on
+/dynamax status
+/dynamax off
+```
+
+`dynamax` is a permission signal for the host agent: once opted in, it may run an existing named workflow or author an inline workflow script through the `workflow` tool. In interactive mode, `/workflow` with no arguments also offers `✍ Author temporary one-shot workflow…`; choose it, type a brief, and pi will ask the host agent to author/run a temporary inline workflow.
+
 The advisory workflows inspect and report only; they do not edit files. They return the same shape: summary, ranked findings, evidence, impact, recommendations, and next steps.
 
 ## Built-in workflows
@@ -81,7 +93,6 @@ The advisory workflows inspect and report only; they do not edit files. They ret
 - `refactor-scout`: Looks for small, safe refactor opportunities: duplication, complexity, weak types, boundary leaks, dead code, and convention drift.
 - `diagnose`: Investigates a symptom, failing command, or regression. It generates competing root-cause hypotheses, verifies them, and returns the most likely causes with next validation steps.
 - `perf-review`: Reviews a slow path or workload for bottleneck hypotheses, measurement gaps, and safe optimization directions. It avoids claiming certainty when measurement evidence is missing.
-- `ping`: Minimal smoke workflow for checking that the engine can run one structured agent call.
 
 ## The code-review workflow
 
@@ -93,7 +104,7 @@ The bundled review workflow is deliberately shaped like a serious review process
 4. **Verify**: send each survivor to an independent verifier that must confirm, mark plausible, or refute with evidence.
 5. **Synthesize**: produce one ranked report with stats, verdicts, and concrete locations.
 
-The review lenses live in `workflows/code-review.ts`. That is where your repo's real failure modes belong.
+The review lenses live in `.pi/extensions/pi-workflow-engine/workflows/code-review.ts`. That is where your repo's real failure modes belong.
 
 ## Authoring workflows
 
@@ -135,12 +146,33 @@ export default async function run({ agent, parallel, phase }: WorkflowApi) {
 }
 ```
 
+Inline workflow scripts use the same primitives, but are passed as a string to the `workflow` tool instead of being saved as files. A minimal inline workflow starts with `export const meta` and uses the injected Type object for schemas:
+
+```ts
+export const meta = {
+  name: "inline-review",
+  description: "One-off focused review workflow.",
+};
+
+export default async function run({ agent, parallel, phase, args }) {
+  phase("Find");
+  const Finding = Type.Object({ summary: Type.String() });
+  const findings = await parallel([
+    () => agent(`Find correctness issues: ${args}`, { schema: Finding, thinkingLevel: "low" }),
+    () => agent(`Find edge cases: ${args}`, { schema: Finding, thinkingLevel: "low" }),
+  ]);
+  return { summary: JSON.stringify(findings) };
+}
+```
+
+Inline v1 rules: no imports, no dynamic `import()`, pure-literal `meta`, schemas must use the injected Type value, and scripts run in-process with the extension's permissions. This v1 path is permissive rather than sandboxed.
+
 Under the hood:
 
 - **Each `agent()` is an in-process pi `AgentSession`** using `createAgentSession` and `SessionManager.inMemory()`.
 - **Structured output is a terminating tool**. The engine registers one tool whose `parameters` is your schema; pi validates the call and the engine captures the args. There is no JSON scraping.
 - **A single global semaphore caps concurrent agents**, so `parallel` and `pipeline` can nest freely while every `agent()` call still respects the run cap.
-- **Two surfaces are registered**: `/workflow <name> [args]` for direct use, and a `workflow` tool for host-agent delegation.
+- **Three surfaces are registered**: `/workflow <name> [args]` for direct use, `/dynamax on|off|status` for sticky orchestration opt-in, and a `workflow` tool for host-agent delegation by `name` or inline `script`.
 
 ## Local development
 
@@ -151,36 +183,78 @@ git clone https://github.com/timbrinded/pi-workflow-engine
 cd pi-workflow-engine
 bun install
 bun run typecheck
-bun scripts/smoke.ts
+bun run test
 ```
 
-Load your working copy into a session without installing it. This is ephemeral and overrides nothing:
+The test suite is no-LLM and uses Bun's built-in `bun test` runner, not a third-party test framework.
+
+### Performance controls and benchmarks
+
+The workflow engine is measurement-first: tune only after checking queue wait, local orchestration, discovery, and UI render costs on the machine where you run pi.
+
+Runtime controls:
+
+- `PI_WORKFLOW_PERF=1` enables the internal per-run performance recorder used by the orchestration instrumentation.
+- `PI_WORKFLOW_CONCURRENCY=N` sets the per-run agent semaphore cap. The default remains `min(8, max(2, CPU count))`.
+- `PI_WORKFLOW_PARALLEL_SUBMISSION_LIMIT=N` limits how many `parallel()` thunks are submitted at once; this is separate from the running-agent semaphore cap.
+- `PI_WORKFLOW_LANE_ITEM_LIMIT=N` caps retained progress lane items per lane; snapshots report how many older items are hidden.
+- Slash commands can override selected controls per run: `/workflow <name> --concurrency=N --parallel-limit=N ...`.
+
+No-LLM benchmark scripts:
 
 ```bash
-pi -e ./src/index.ts -p "/workflow ping"
+bun run bench:concurrency -- --items 200 --concurrency 8 --json
+bun run bench:discovery -- --iterations 3 --json
+bun run bench:startup -- --json
+bun run bench:ui -- --agents 1000 --lane-items 1000 --json
 ```
 
-Add a workflow by creating `workflows/<name>.ts`, importing it in `src/workflows.ts`, and adding it to `BUILTIN_WORKFLOWS`. Statically imported workflows share pi's bundled `typebox`, which guarantees schema validation. Files in `workflows/` and `~/.pi/agent/workflows/` are also discovered dynamically at runtime on a best-effort basis.
+Add `--out` to write machine-local JSON under `.artifacts/benchmarks/`. These timings are advisory, not portable thresholds.
+
+Guardrails:
+
+- Do not pool or reuse subagent sessions until `agent.create_session_ms` is proven material and isolation semantics are reviewed.
+- Do not lazy-load guaranteed built-in workflow modules until pi/jiti bundled `typebox` identity is proven for that path.
+- Do not raise the default concurrency without queue-wait versus run-time evidence.
+
+Load your working copy through the package manifest without installing it. This is ephemeral and exercises the same `.pi/extensions/pi-workflow-engine/index.ts` entrypoint that installed packages use:
+
+```bash
+pi -e .
+```
+
+This repo also includes `.pi/settings.json` for project-local auto-discovery. If you also have the global package installed, pi may report duplicate `/workflow` or `workflow` tool diagnostics; remove one source or force pi to ignore discovered extensions and load this working copy instead:
+
+```bash
+pi -ne -e .
+```
+
+Add a built-in workflow by creating `.pi/extensions/pi-workflow-engine/workflows/<name>.ts`, importing it in `.pi/extensions/pi-workflow-engine/src/workflows.ts`, and adding it to `BUILTIN_WORKFLOWS`. Statically imported workflows share pi's bundled `typebox`, which guarantees schema validation. Files in `.pi/extensions/pi-workflow-engine/workflows/` and `~/.pi/agent/workflows/` are also discovered dynamically at runtime on a best-effort basis.
+
+Keep guaranteed built-ins statically imported. Optimize cold startup at the extension entrypoint or discovery boundary first; do not lazy-load built-in workflow modules unless a test proves pi/jiti preserves the same bundled `typebox` identity for dynamically imported built-ins.
 
-Tune the built-in review workflow by editing the `ANGLES` array in `workflows/code-review.ts`. Tune `model`, `thinkingLevel`, and `tools` per `agent()` call, and tune `DEFAULT_CONCURRENCY` in `src/engine.ts`.
+Tune the built-in review workflow by editing the `ANGLES` array in `.pi/extensions/pi-workflow-engine/workflows/code-review.ts`. Tune `model`, `thinkingLevel`, and `tools` per `agent()` call, and use `PI_WORKFLOW_CONCURRENCY` or `/workflow <name> --concurrency=N` for measured per-run concurrency experiments.
 
 ### Layout
 
 ```text
-src/
-  index.ts         extension entry; registers the command and tool
-  types.ts         WorkflowApi / WorkflowModule contracts
-  agent-runner.ts  createAgentSession + terminating-tool schema bridge
-  concurrency.ts   Semaphore, parallel(), pipeline()
-  engine.ts        runWorkflow(); binds primitives to one run
-  progress.ts      live phase/agent tree via ctx.ui.setWidget
-  discovery.ts     static registry + best-effort drop-in loading
-workflows/
-  code-review.ts     scope -> find -> verify -> synthesize
-  refactor-scout.ts  advisory refactor opportunities
-  diagnose.ts        advisory bug diagnosis
-  perf-review.ts     advisory performance investigation
-  ping.ts            minimal smoke workflow
+.pi/
+  settings.json                         project-local pi resource settings
+  extensions/pi-workflow-engine/
+    index.ts                            canonical extension entry; registers the command and tool
+    src/
+      types.ts                          WorkflowApi / WorkflowModule contracts
+      agent-runner.ts                   createAgentSession + terminating-tool schema bridge
+      concurrency.ts                    Semaphore, parallel(), pipeline()
+      engine.ts                         runWorkflow(); binds primitives to one run
+      progress.ts                       live phase/agent tree via ctx.ui.setWidget
+      discovery.ts                      static registry + best-effort drop-in loading
+      workflows.ts                      statically registered built-in workflows
+    workflows/
+      code-review.ts                    scope -> find -> verify -> synthesize
+      refactor-scout.ts                 advisory refactor opportunities
+      diagnose.ts                       advisory bug diagnosis
+      perf-review.ts                    advisory performance investigation
 ```
 
 ## License

package/USAGE.md

@@ -0,0 +1,183 @@
+# Usage
+
+`pi-workflow-engine` adds multi-agent workflows to pi. Most users only need two surfaces:
+
+- `/workflow <name> [args]` to run a saved workflow directly.
+- `dynamax` when you want the host agent to author a one-off inline workflow for investigation/review.
+
+## Run a workflow
+
+From inside a repo:
+
+```text
+/workflow code-review
+/workflow code-review HEAD~3
+/workflow refactor-scout src/
+/workflow diagnose "typecheck fails after the schema change"
+/workflow perf-review "workflow startup latency"
+```
+
+The built-in workflows are advisory. They inspect, verify, and report; they do **not** edit files.
+
+Useful flags:
+
+```text
+/workflow code-review --inspect          # show live inspector
+/workflow code-review --concurrency=4    # cap concurrent subagents
+/workflow code-review --refresh          # rediscover newly added workflow files
+```
+
+## Built-in workflows
+
+| Name | Purpose |
+| --- | --- |
+| `code-review` | Reviews a PR, branch diff, ref range, or focus area. |
+| `refactor-scout` | Finds small, safe refactor opportunities. |
+| `diagnose` | Investigates a bug, failing command, or regression. |
+| `perf-review` | Reviews a slow path or performance concern. |
+
+`code-review` auto-detects a diff when you do not pass args. If there is an open GitHub PR for the current branch, it uses that PR diff; otherwise it falls back to branch-vs-main/master or `HEAD~1`.
+
+## Use `dynamax` for inline workflows
+
+Use `dynamax` when the built-in workflows are not specific enough and you want the main pi agent to author a temporary workflow for the current question.
+
+Interactive shortcut: run `/workflow` with no arguments, choose `✍ Author temporary one-shot workflow…`, and type a brief. pi will send that brief back to the host agent as a `dynamax` request so it can author and run an inline workflow with the `workflow` tool's `script` argument.
+
+That inline workflow should investigate, fan out, verify, and summarize. It is **not** where code edits happen. If you want changes made, use the workflow result as evidence and then ask pi to edit separately.
+
+One-off examples:
+
+```text
+dynamax author an inline workflow to investigate why typecheck is failing
+dynamax create a one-off workflow to compare the parser and tests before we change code
+dynamax use parallel agents to review this design and report the risks
+```
+
+Sticky for the session:
+
+```text
+/dynamax on
+/dynamax off
+/dynamax status
+```
+
+With dynamax enabled, the host agent usually calls the `workflow` tool with `script`: a one-off inline workflow. It can still call a saved workflow by `name` when one already fits.
+
+## Workflow results
+
+Workflow results are rendered in pi with:
+
+- summary;
+- ranked findings;
+- locations and evidence;
+- recommendations;
+- next steps;
+- run stats when available.
+
+During a run, pi shows live phases and subagent status. Use `--inspect` if you want a larger live view.
+
+## Author a saved workflow
+
+Saved workflows are TypeScript modules with `meta` plus a default async function:
+
+```ts
+import { Type } from "typebox";
+import type { WorkflowApi, WorkflowMeta } from "../src/types.ts";
+
+export const meta: WorkflowMeta = {
+  name: "my-workflow",
+  description: "Find and summarize something important.",
+};
+
+const Finding = Type.Object({
+  summary: Type.String(),
+});
+
+export default async function run({ agent, parallel, phase, args }: WorkflowApi) {
+  phase("Find");
+  const findings = await parallel([
+    () => agent(`Find correctness issues: ${args}`, { schema: Finding, tools: ["read", "bash"], thinkingLevel: "low" }),
+    () => agent(`Find edge cases: ${args}`, { schema: Finding, tools: ["read", "bash"], thinkingLevel: "low" }),
+  ]);
+
+  phase("Synthesize");
+  return agent(`Summarize: ${JSON.stringify(findings)}`, { thinkingLevel: "medium" });
+}
+```
+
+Core primitives:
+
+| Primitive | What it does |
+| --- | --- |
+| `agent(prompt, opts)` | Runs one isolated subagent. With `schema`, returns validated structured data. |
+| `parallel(thunks)` | Runs thunks concurrently and waits for all. |
+| `pipeline(items, ...stages)` | Runs each item through stages independently. |
+| `phase(title)` / `log(message)` | Updates workflow progress UI. |
+| `progress(event)` | Emits counters, summaries, and lane items. |
+
+Set `thinkingLevel` on fan-out agents. Otherwise many subagents can inherit an expensive global reasoning level.
+
+### Where workflows live
+
+Guaranteed built-ins are statically registered:
+
+1. Add `.pi/extensions/pi-workflow-engine/workflows/<name>.ts`.
+2. Import it in `.pi/extensions/pi-workflow-engine/src/workflows.ts`.
+3. Add it to `BUILTIN_WORKFLOWS`.
+
+Drop-in workflows are also discovered best-effort from:
+
+- `.pi/extensions/pi-workflow-engine/workflows/*.ts`
+- `~/.pi/agent/workflows/*.ts`
+
+Use `/workflow <name> --refresh` after adding a drop-in file.
+
+## Author an inline workflow
+
+Inline workflows are passed to the `workflow` tool as a script string. They are useful for one-off dynamax orchestration.
+
+```ts
+export const meta = {
+  name: "inline-review",
+  description: "One-off focused review.",
+};
+
+export default async function run({ agent, parallel, phase, args }) {
+  phase("Find");
+  const Finding = Type.Object({ summary: Type.String() });
+  const findings = await parallel([
+    () => agent(`Find correctness issues: ${args}`, { schema: Finding, thinkingLevel: "low" }),
+    () => agent(`Find edge cases: ${args}`, { schema: Finding, thinkingLevel: "low" }),
+  ]);
+  return { summary: JSON.stringify(findings) };
+}
+```
+
+Inline rules:
+
+- start with `export const meta = { ... }`;
+- default-export an async workflow function;
+- no imports or dynamic `import()`;
+- use the injected `Type` object for schemas;
+- no extra exports or code after the default export.
+
+Inline workflows run in-process with extension permissions, so treat them as trusted task automation.
+
+## Runtime knobs
+
+Only tune these when a workflow is too slow, too expensive, or too noisy:
+
+| Knob | Meaning |
+| --- | --- |
+| `--concurrency=N` / `PI_WORKFLOW_CONCURRENCY=N` | Cap concurrent subagents. Default is `min(8, max(2, CPU count))`. |
+| `--parallel-limit=N` / `PI_WORKFLOW_PARALLEL_SUBMISSION_LIMIT=N` | Limit eager `parallel()` submission. |
+| `--perf` / `PI_WORKFLOW_PERF=1` | Include internal timing aggregates. |
+| `PI_WORKFLOW_LANE_ITEM_LIMIT=N` | Cap retained progress lane items. |
+
+## Common fixes
+
+- **Unknown workflow**: confirm the extension is loaded with `pi list`; use `--refresh` for new drop-ins.
+- **Inline compile error**: check the inline rules above.
+- **Slow run**: lower fan-out, set `thinkingLevel`, or reduce `--concurrency`.
+- **Duplicate command/tool warnings while developing**: avoid loading both the global package and the working copy.

package/package.json

@@ -1,23 +1,50 @@
 {
   "name": "pi-workflow-engine",
-  "version": "0.3.0",
+  "version": "0.5.0",
   "type": "module",
   "description": "A customisable multi-agent workflow-orchestration engine for the pi coding agent.",
-  "keywords": ["pi-package"],
+  "keywords": [
+    "pi-package",
+    "pi-extension",
+    "pi-workflow",
+    "workflow-engine",
+    "multi-agent",
+    "coding-agent"
+  ],
   "license": "MIT",
+  "homepage": "https://github.com/timbrinded/pi-workflow-engine#readme",
+  "bugs": {
+    "url": "https://github.com/timbrinded/pi-workflow-engine/issues"
+  },
   "repository": {
     "type": "git",
     "url": "git+https://github.com/timbrinded/pi-workflow-engine.git"
   },
-  "files": ["src", "workflows"],
+  "files": [
+    ".pi/extensions/pi-workflow-engine",
+    ".pi/settings.json",
+    "assets",
+    "README.md",
+    "USAGE.md",
+    "LICENSE"
+  ],
   "pi": {
-    "extensions": ["./src/index.ts"],
+    "extensions": [".pi/extensions/pi-workflow-engine/index.ts"],
     "image": "https://raw.githubusercontent.com/timbrinded/pi-workflow-engine/master/assets/preview.png"
   },
   "scripts": {
     "typecheck": "tsc --noEmit",
-    "test:ui": "bun scripts/test-workflow-ui.ts",
-    "prepublishOnly": "tsc --noEmit"
+    "test": "bun test",
+    "test:changedlines": "bun test tests/changedlines.test.ts",
+    "test:concurrency": "bun test tests/concurrency.test.ts",
+    "test:smoke": "bun test tests/discovery.test.ts",
+    "test:ui": "bun test tests/workflow-ui.test.ts",
+    "bench": "bun run bench:concurrency && bun run bench:discovery && bun run bench:ui",
+    "bench:concurrency": "bun run scripts/bench/concurrency.ts",
+    "bench:discovery": "bun run scripts/bench/discovery.ts",
+    "bench:startup": "bun run scripts/bench/startup.ts",
+    "bench:ui": "bun run scripts/bench/ui.ts",
+    "prepublishOnly": "tsc --noEmit && bun run test"
   },
   "peerDependencies": {
     "@earendil-works/pi-agent-core": "*",

package/src/agent-runner.ts

@@ -1,122 +0,0 @@
-import { createAgentSession, defineTool, SessionManager } from "@earendil-works/pi-coding-agent";
-import type { ModelRegistry, ToolDefinition } from "@earendil-works/pi-coding-agent";
-import type { Model } from "@earendil-works/pi-ai";
-import type { AgentState } from "@earendil-works/pi-agent-core";
-import type { AgentOptions } from "./types.ts";
-import type { Semaphore } from "./concurrency.ts";
-import type { ProgressTracker } from "./progress.ts";
-
-/** Name of the synthetic terminating tool that carries structured output. */
-const FINAL_TOOL = "final_answer";
-
-/** Shared per-run context threaded into every agent() call. */
-export interface RunContext {
-  cwd: string;
-  hostModel: Model<any> | undefined;
-  modelRegistry: ModelRegistry;
-  semaphore: Semaphore;
-  progress: ProgressTracker;
-  signal: AbortSignal | undefined;
-}
-
-/** Pull the last assistant message's plain text out of a finished session. */
-function lastAssistantText(state: AgentState): string {
-  const messages = state.messages;
-  for (let i = messages.length - 1; i >= 0; i--) {
-    const message = messages[i];
-    if ("role" in message && message.role === "assistant") {
-      const content = (message as { content?: Array<{ type: string; text?: string }> }).content ?? [];
-      return content
-        .filter((part) => part.type === "text")
-        .map((part) => part.text ?? "")
-        .join("")
-        .trim();
-    }
-  }
-  return "";
-}
-
-/**
- * Run one subagent to completion in an isolated in-memory session.
- *
- * Structured output trick: when `opts.schema` is set we register a single
- * terminating tool whose `parameters` IS the schema. The agent's last action is to
- * call it; pi validates the args against the schema, hands them to `execute`, and
- * `terminate: true` ends the turn with no extra LLM round-trip. We capture those
- * validated args in a closure — that captured object is the structured result, so
- * no event-stream parsing is needed.
- */
-export async function runAgent(rc: RunContext, prompt: string, opts: AgentOptions = {}): Promise<unknown> {
-  const label = opts.label ?? "agent";
-
-  // Track queued agents before acquiring a global concurrency slot.
-  const rowId = rc.progress.agentQueued(opts.phase, label);
-  return rc.semaphore.run(async () => {
-    rc.progress.agentStart(opts.phase, label, rowId);
-
-    let captured: unknown = null;
-    let failed = false;
-    const customTools: ToolDefinition[] = opts.schema
-      ? [
-          defineTool({
-            name: FINAL_TOOL,
-            label: "Final Answer",
-            description:
-              "Return your final structured answer. This MUST be your last action — do not write a normal reply after calling it.",
-            parameters: opts.schema,
-            async execute(_toolCallId, params) {
-              captured = params;
-              return { content: [{ type: "text", text: "Recorded." }], details: params, terminate: true };
-            },
-          }),
-        ]
-      : [];
-
-    // When the workflow restricts built-in tools, keep the terminating tool visible.
-    const allow = opts.tools
-      ? opts.schema
-        ? [...opts.tools, FINAL_TOOL]
-        : opts.tools
-      : undefined;
-
-    // Resolve the model by runtime id lookup (no compile-time model-id union); fall back to the host's model.
-    const model = opts.model ? rc.modelRegistry.find("anthropic", opts.model) ?? rc.hostModel : rc.hostModel;
-
-    const { session } = await createAgentSession({
-      cwd: rc.cwd,
-      model,
-      modelRegistry: rc.modelRegistry,
-      thinkingLevel: opts.thinkingLevel,
-      tools: allow,
-      customTools,
-      sessionManager: SessionManager.inMemory(rc.cwd),
-    });
-
-    const unsubscribe = session.subscribe((event) => {
-      if (event.type === "tool_execution_start" && event.toolName !== FINAL_TOOL) {
-        rc.progress.agentTool(label, event.toolName, rowId);
-      }
-    });
-
-    try {
-      const finalPrompt = opts.schema
-        ? `${prompt}\n\nWhen finished, return your result by calling the ${FINAL_TOOL} tool.`
-        : prompt;
-      await session.prompt(finalPrompt);
-      if (opts.schema) {
-        if (captured === null) rc.progress.log(`${label}: no structured answer returned`);
-        return captured;
-      }
-      return lastAssistantText(session.state);
-    } catch (error) {
-      failed = true;
-      rc.progress.agentFailed(label, error, rowId);
-      rc.progress.log(`${label} failed: ${error instanceof Error ? error.message : String(error)}`);
-      throw error;
-    } finally {
-      unsubscribe();
-      session.dispose();
-      if (!failed) rc.progress.agentDone(label, rowId);
-    }
-  });
-}

package/src/concurrency.ts

@@ -1,55 +0,0 @@
-/**
- * A counting semaphore: bounds how many async tasks run at once.
- *
- * This is the single global concurrency cap for a workflow run. Every `agent()`
- * call acquires a slot before spawning a session and releases it when done, so the
- * cap holds no matter how `parallel`/`pipeline` are nested — exactly like the
- * built-in Workflow tool, where "concurrent agent() calls are capped and excess queue".
- */
-export class Semaphore {
-  private active = 0;
-  private readonly waiters: Array<() => void> = [];
-
-  constructor(private readonly max: number) {}
-
-  async run<T>(fn: () => Promise<T>): Promise<T> {
-    if (this.active >= this.max) {
-      await new Promise<void>((resolve) => this.waiters.push(resolve));
-    }
-    this.active++;
-    try {
-      return await fn();
-    } finally {
-      this.active--;
-      this.waiters.shift()?.();
-    }
-  }
-}
-
-/** Run every thunk concurrently and wait for all results (a barrier). */
-export async function parallel<T>(thunks: Array<() => Promise<T>>): Promise<T[]> {
-  return Promise.all(thunks.map((thunk) => thunk()));
-}
-
-/**
- * Run each item through all stages independently. There is NO barrier between
- * stages: item A can be in stage 3 while item B is still in stage 1. Actual agent
- * concurrency is bounded by the run's Semaphore (inside each `agent()`), not here —
- * so launching every item at once is safe.
- *
- * Each stage receives (previousResult, originalItem, index).
- */
-export async function pipeline(
-  items: unknown[],
-  ...stages: Array<(prev: unknown, item: unknown, index: number) => Promise<unknown>>
-): Promise<unknown[]> {
-  return Promise.all(
-    items.map(async (item, index) => {
-      let acc: unknown = item;
-      for (const stage of stages) {
-        acc = await stage(acc, item, index);
-      }
-      return acc;
-    }),
-  );
-}