3 · Advanced

Goal: run real work. Multiple agents, in parallel, across tools, unattended — and be able to re-run just the part that failed.

These examples call provider CLIs and cost real tokens. Set a spend ceiling first.

3.1 ǁ Ply — parallel waves

Ply is the maximum number of independent ready nodes that may execute at once. Default 4; set it in ≔ params.

The runner works in waves: every node whose predecessors are all complete becomes ready, and up to ply of them run together. With ply: 1 a fan-out serializes; with ply: 3 three agents work at the same time and the wall clock collapses to the slowest one.

Between waves, the graph spend ceiling is re-checked — parallelism never outruns your budget by more than one wave.

▶ Example: Ply fan + majority knot (two parallel asks → majority knot → duration fuse)

See Ply.

3.2 The fan-out / fan-in shape

This is the workhorse pattern:

prompt ──┬─▶ agent A ──┐
         ├─▶ agent B ──┼─▶ ⋈ knot (majority) ──▶ ✓ approval ──▶ ⇤ output
         └─▶ agent C ──┘

Three independent opinions, one merged answer, one human check. Change the knot strategy to synthesize with a model on the node and you get a written synthesis instead of a vote.

Multi-provider is the interesting variant: A on Claude, B on opencode, C on Cursor. threadle is the only place that shape is one graph.

3.3 Iterating with agents

Put an ∀ Iterator in front of an agent and the agent runs once per item — sequentially, in one session, so it accumulates context across items — with the outputs collected for whatever comes next.

Wire a tripwire after it to catch the run where item 7 returns nothing.

▶ Example: Iterator → agent

3.4 The full spine: plan → implement → review

The bundled Starter workflow is the canonical multi-stage pipeline: plan with one agent, implement with another, review the diff with a third, gated by approvals, driven by a single task param.

Open it and read the wiring — it uses most of what you’ve learned, including a muted optional skill node you can switch on.

▶ Example: Starter workflow (plan-implement-review)

threadle run plan-implement-review --param task="fix the flaky auth test" --approve-all

3.5 Partial runs — don’t redo what worked

Right-click any node:

run from this node — that node and everything downstream
test this node — just that one

Nodes outside the scope don’t re-execute. They contribute their last known result read-only: stored prompt text, an output node’s saved content, a materialized payload, or the tail of an agent’s linked session. So you can fix the third stage of a five-stage pipeline and re-run only the tail, without paying for stages one and two again.

3.6 Error policy per node

Right-click → set retry (off / 1× / 3× with backoff) and continue on error for any node. With continue-on-error the node goes red, the run keeps going, and downstream nodes starve rather than the whole graph dying.

Pair it with a retries tripwire, which trips once the run’s failure count crosses a threshold — “tolerate two flaky steps, abort on the third”.

See Errors & retries.

3.7 Headless runs

Everything above runs without a browser — same executor:

threadle run <graphId|template|file.json> \
  --param task="..." \
  --approve-all \
  --dir ~/code/my-project

Two rules for detached runs:

Interactive gates need --approve-all (or ≫ + confirm). Otherwise the run refuses rather than silently swallowing a checkpoint — use in-tab ▶ when you need splice.
Context nodes must already be materialized. A server job won’t distill a payload on the fly.

Close the browser during a long run; reopen the workflow or use threadle jobs / logs. Check threadle services before a long unattended batch. See Detached runs.

You’re done when…

your graphs fan out and back in instead of running in a line
you re-run stage four instead of the whole pipeline
you can run any saved workflow from the terminal with params
you know which parts of your graph would block a detached run

4 · Expert — extend threadle itself.