Dynamic Workflows

A normal workflow runs inside a single Slo session: one agent, one context window, one thing at a time. A dynamic workflow is different. Slo becomes an orchestrator — it reads the workflow, breaks it into phases, and fans each phase out to its own sub-agent running in its own process. The orchestrator dispatches the phases, watches the children, retries what fails, and synthesizes the results into one answer.

The trigger phrase is exactly that: say "dynamic workflows" (Slo also understands the common misspelling "dyanmic workflows") and Slo switches from doing the work itself to decomposing and delegating it.

Why the name? The plan isn't fixed up front. The orchestrator decides — at run time — how many sub-agents to spawn, what each one does, and whether phases run one-after-another or all at once. The shape of the work is discovered as it runs.

Why dynamic workflows give better results

A single agent working a long, multi-step task accumulates everything in one context window: the spec, the code it wrote three steps ago, the test output, the review notes. Signal gets diluted and later steps drift.

Dynamic workflows fix that by giving each phase a clean, dedicated context:

• Focus — the "write tests" sub-agent sees only what it needs to write tests. Nothing from the review phase is crowding its window.
• Isolation — a phase that fails or goes off the rails is one child process. The orchestrator retries it once with corrected parameters instead of poisoning the whole run.
• Parallelism — independent phases run at the same time, up to the concurrency cap, so a review that touches five modules finishes in the time of the slowest one, not the sum of all five.
• Oversight — the orchestrator is a supervisor that never does the bulk work. Its only job is to decompose, dispatch, check in, and synthesize — so it always has room to reason about the whole.

A simple example: code-test-review

The code-test-review workflow has four phases — write code, write tests, review, ship a PR. Run it the ordinary way and one agent carries all four in a single context.

Run it as a dynamic workflow and each phase becomes a sub-agent:

slo run \
  -p "Use dynamic workflows: run the code-test-review workflow for
      the feature in specs/42-payments/overview.md" \
  --orchestrator \
  --enable-history \
  --session-id ctr-20260718 \
  --json

Here is what changes:

The code-test-review workflow is a pipeline, so its phases run serially: code → test → review → ship, each waiting for the previous phase's READY verdict before the next is dispatched. A parallel workflow (for example, reviewing several modules at once) dispatches all independent phases in one call and then runs a synthesis phase after they all complete.

Watching sub-agents with slo visualize

When phases run in parallel across several processes, you want to see them. slo visualize is a read-only TUI that attaches to the orchestrator's session and shows every sub-agent, its live status, and its transcript. It reads from the history store — it never interferes with the running workflow, and you can open it while the workflow is still going or after it has finished.

The orchestrator prints the exact command when it starts. Run it in a second terminal:

slo visualize --session ctr-20260718 --follow --refresh-seconds 2

• Left pane — every discovered sub-agent, each with a status icon: ⏳ running, ✓ completed, ✗ failed, ⊘ aborted, ◌ pending.
• Right pane — the transcript of the selected child: its prompt, tool calls, test output, and final verdict.
• Status bar — parent session id, workflow state (running / complete), child count, follow mode, and the last refresh time.

Keyboard controls

Use --follow (the default) to poll for live updates while the workflow runs; polling stops automatically once the orchestrator reaches a terminal state. Use --no-follow to inspect a workflow that has already finished:

slo visualize --session ctr-20260718 --no-follow

How the orchestrator supervises its children

The --orchestrator flag injects a built-in orchestrator system prompt, so you don't have to explain the role — you describe the task, not the procedure. Under the hood the orchestrator:

1. Reads the workflow file and enumerates its phases.
2. Builds a self-contained prompt for each phase (no pronouns, no "the previous step" — every sub-agent prompt stands alone).
3. Dispatches phases serially (pipeline) or in parallel, up to SLO_SUBAGENT_MAX_CONCURRENCY (default 6 for workflows).
4. Checks in on the children as they run, retrying a failed or aborted phase once with corrected parameters.
5. Collects every child's answer and synthesizes one coherent result.

For a long workflow, set the guard timeouts before launching so a big synthesis call is never mistaken for a hang:

export SLO_STREAM_INACTIVITY_TIMEOUT_SECONDS=2400   # orchestrator's own LLM stream
export SLO_SUBAGENT_INACTIVITY_TIMEOUT_SECONDS=1800 # each child's stdout pipe
export SLO_SUBAGENT_MAX_CONCURRENCY=6               # simultaneous sub-agents

When to reach for a dynamic workflow

• A multi-phase workflow where phases benefit from clean, separate context (code-test-review, specification-development).
• A review or audit that fans out over many files or modules and should run in parallel.
• Any unattended, long-running job you want to launch headlessly and watch from the visualizer.
• Recurring supervised work — pair it with the scheduler so the orchestrator wakes on a timer and checks in on its own sub-agents.

Next steps

• Run it headlessly — the full slo run --orchestrator reference.
• Schedule it — fire a dynamic workflow on a timer.
• Code-test-review — the workflow used in the example above.