pi-dynamic-workflows: Open-Source AI Coding Agent Extensions

What Is pi-dynamic-workflows?

pi-dynamic-workflows is an open-source AI Coding Agent Extension for Pi built by Michaelliv that adds a workflow tool for fan-out subagent orchestration, aimed at Pi users who need repository audits, refactors, and research across many isolated contexts. pi-dynamic-workflows is one of the best AI Coding Agent Extensions tools for Pi users who need parallel code audits, multi-perspective reviews, and large refactors, and it exposes 8 workflow globals (agent, parallel, pipeline, phase, log, args, cwd, budget) instead of forcing a single sequential assistant pass.

The practical difference is that pi-dynamic-workflows lets the model author a small JavaScript workflow script, then execute many isolated Pi subagents with separate context windows. That makes it a fit for codebase inspection, fan-out research, and cross-checking conclusions across multiple passes without manually juggling prompts.

Quick Overview

Who Should Use pi-dynamic-workflows?

• Platform engineers doing repo-wide audits who want separate subagents to inspect structure, modules, and edge cases without context bleed.
• Indie hackers refactoring a growing codebase who need a repeatable way to split analysis, summarize findings, and synthesize a final plan.
• Security reviewers who want isolated scans for sensitive files, dependency risk, and suspicious code paths with structured outputs.
• Research-heavy developers running fan-out investigations across multiple hypotheses, source trees, or implementation patterns.

Not ideal for:

• Teams that want a visual, canvas-first interaction model rather than writing workflow scripts.
• Users who need persisted or resumable workflow runs, because this project is still a prototype.
• Small prompts where a single Pi turn is enough and subagent overhead would just add latency.

Key Features of pi-dynamic-workflows

• Fan-out subagent orchestration — agent() creates isolated Pi subagents, so each task runs with its own working context and tool access. That is a cleaner model for audits and refactors than one long assistant chain.
• Parallel execution primitives — parallel(thunks) runs subagent calls concurrently, while pipeline(items, ...stages) fans items through sequential stages. This is the core reason pi-dynamic-workflows works well for large repositories and multi-step analysis.
• Live phase progress — phase(title) drives the inline status view, so long jobs expose incremental progress instead of dumping a single final response. The page shows progress like 3/3 done, which is useful when a workflow fans out to many sub-tasks.
• Structured outputs with JSON Schema — agent(..., { schema }) returns validated objects instead of raw text when the task needs machine-readable data. Under the hood, pi-dynamic-workflows maps that to Pi's structured_output tool with terminate: true, which avoids an extra assistant turn.
• Sandboxed workflow runtime — workflow scripts execute inside a Node vm sandbox with deterministic restrictions. Date.now(), Math.random(), require, import, fs, network APIs, spreads, computed keys, and function calls inside meta are intentionally blocked.
• Editor IntelliSense — reusable workflow files can add /// <reference types='pi-dynamic-workflows/workflow' /> for typed hints. That surfaces globals like agent, parallel, pipeline, phase, log, args, cwd, and budget in TypeScript-aware editors.
• Cancelable runs — pressing Esc aborts the active workflow and skips outstanding subagents. That matters when a repository scan turns up noisy results and you want to cut the run short.

pi-dynamic-workflows vs Alternatives

Pick Claude Code Canvas if you want a more visual experience and your team prefers manipulating work in a canvas rather than writing workflow code. Pick OpenSwarm when the primary need is broader multi-agent coordination outside the Pi extension model.

Use Brainstorm MCP when the job is to generate options, outline a plan, or structure an investigation before execution. Choose pi-dynamic-workflows when the workflow itself needs to run inside Pi, with explicit phases, sandbox rules, and machine-readable outputs.

How pi-dynamic-workflows Works

pi-dynamic-workflows is built around a small execution pipeline: the Pi model first writes a workflow script, then the workflow tool parses and validates the script, and finally the script runs inside a Node vm sandbox. The important design choice is that the script is not an opaque prompt blob; it is executable JavaScript with a constrained global surface, which keeps orchestration inspectable and reproducible.

The workflow metadata must be a literal export const meta = { ... }, and the runtime discovers phase(...) calls as the script executes. That means branches, loops, and conditional paths can appear naturally without predeclaring every phase up front. The result is a better fit for codebase audits than static step lists, because the script can adapt to repository shape while still reporting progress clearly.

export const meta = {
  name: 'inspect_project',
  description: 'Inspect a repository and summarize the main modules',
  phases: [
    { title: 'Scan' },
    { title: 'Analyze' },
  ],
}

phase('Scan')
const inventory = await agent('Inspect the repository structure.', {
  label: 'repo inventory',
})

phase('Analyze')
const summary = await agent(
  'Summarize the main modules from this inventory:\n' + inventory,
  { label: 'module summary' },
)

return { inventory, summary }

That script creates two subagent passes, labels them for progress rendering, and returns a structured result to the parent assistant. In practice, you get a compact execution trace, isolated analysis contexts, and a final synthesized answer without manually micromanaging the fan-out.

Pros and Cons of pi-dynamic-workflows

Pros:

• Deterministic orchestration surface — the sandbox blocks non-deterministic APIs and side effects, which makes workflow behavior easier to reason about.
• Parallel analysis support — parallel() and pipeline() let you split work across subagents without collapsing everything into one context window.
• Structured results — JSON Schema validation makes it possible to return objects instead of free-form text for downstream automation.
• Strong progress visibility — phase() plus inline rendering gives you live feedback on long-running repository jobs.
• Pi-native integration — the extension installs into Pi directly and activates on session start, so there is no separate daemon or external service to manage.
• Good fit for refactors and audits — isolated subagents reduce context contamination when you need multiple views of the same codebase.

Cons:

• Prototype status — the project does not yet ship persisted or resumable runs, so interrupted workflows are not checkpointed.
• No /workflows manager — there is no dedicated management UI for saved workflow inventory or run history.
• Sandbox restrictions are strict — blocked APIs like require, fs, and network access inside meta limit what a workflow can do during orchestration.
• Requires script-shaped thinking — users who want purely conversational control will find the JavaScript workflow model more demanding.

Getting Started with pi-dynamic-workflows

Install pi-dynamic-workflows into Pi with the package or a local checkout, then reload the session so the extension registers its workflow tool. After that, you can ask Pi for a workflow in plain language and let it synthesize the script automatically.

pi install npm:pi-dynamic-workflows
# or from a local checkout
pi install /path/to/pi-dynamic-workflows

# inside Pi
/reload

Once the extension is active, ask for a task like inspecting the repository or summarizing modules. If you want to build your own workflow files, add the TypeScript reference comment and start with a literal meta export so the runtime can parse the script safely.

Verdict

pi-dynamic-workflows is the strongest option for Pi users who need fan-out code review and repository analysis when the workflow must stay scriptable and inspectable. Its biggest strength is isolated subagents with parallel orchestration and structured output; its main caveat is that it is still a prototype without persisted runs. Use it if you want deterministic multi-agent execution inside Pi, not a chat-only assistant.