Dynamic workflows

Why workflows exist

spawn_agent is flexible but easy to misuse: too many children, duplicated context, and no phase structure. WorkflowSpec declares phases (topologically sorted), tasks inside each phase, max concurrency, caps on total agents, and optional verify→iterate gates.

workflow_runtime.ts runs the spec with injected spawn, summarize (fast model), and verify hooks. Results land in WorkflowStore on disk; the parent sees PhaseSummary strings, not every child tool stream.

Cross-phase context

Each phase publishes to SharedMemoryBus under ctx/wf/<runId>/<phaseId>. Later tasks set contextBusPrefix so children auto-receive upstream digests plus can query_workflow for per-agent detail. This is how phase 3 “implement fixes” sees phase 1 “audit findings” without you manually pasting logs.

Configuration

AGENT_WORKFLOWS=1
AGENT_WORKFLOW_MAX_CONCURRENT=4
AGENT_WORKFLOW_MAX_AGENTS=64
AGENT_WORKFLOW_TIMEOUT_MS=1800000
AGENT_WORKFLOW_MODEL=   # optional fast model for planner/summarizer

Tools (root-only)

• plan_workflow — produce or refine a WorkflowSpec JSON.
• run_workflow — approval-gated execution.
• workflow_status — running / completed state.
• query_workflow — BM25 search over stored agent outputs.

When to use workflows vs spawn

Use workflows for repeatable multi-phase templates (audit → fix → verify, research → debate → write). Use spawn_agent for one-off side tasks. Workflows do not nest — child harnesses do not get workflow tools, preventing runaway recursion.