vs Claude workflows
How clu (a durable coordination substrate) compares to Claude Code's dynamic workflows (ephemeral in-session subagent orchestration) — a checklist, when to use which, and how they compose.
clu and Claude Code's dynamic workflows
both help you get large, multi-step work done with agents — but they sit at
different layers, and the most useful way to think about them is together,
not either/or.
- clu is a durable coordination substrate: a local SQLite issue graph that many agents (and humans) read and write over time. Work is recorded as tickets with dependencies; agents come and go; state survives the session.
- Claude dynamic workflows are ephemeral in-session orchestration: a JavaScript script the Claude runtime executes for one run, fanning out dozens to hundreds of subagents. The plan lives in the script; intermediate results live in script variables; the final answer lands in your context.
One holds the work (durable, shared, tool-agnostic). The other holds the plan for a burst of work (codified, massively parallel, Claude-native). They overlap less than they look — and they compose well.
At a glance
| Capability | clu | Claude dynamic workflows |
|---|---|---|
| State persists across sessions | ✅ one SQLite file | ❌ resumable only within the same session; exit = fresh |
| Survives restart / shareable between machines | ✅ copy .clu/data.sqlite | ❌ run is tied to the live session |
| Durable dependency graph of work | ✅ issues + edges, ready/blocked | 🟡 deps live in script variables for that run only |
| Atomic claim across many workers | ✅ UPDATE … RETURNING, racing agents get different issues | 🟡 the runtime schedules its own agents; no shared claim pool |
| Long-horizon work (days, many sessions) | ✅ the graph is the memory | ❌ scoped to a single run |
| Spawns & orchestrates agents itself | ❌ it's the substrate; you drive it | ✅ the runtime executes the script and spawns subagents |
| Massive fan-out in one shot | ❌ | ✅ up to 16 concurrent, 1,000 per run |
| Background run while the session stays free | 🟡 commands are instant; --watch is push | ✅ runs in the background |
| Built-in quality patterns (adversarial review, multi-angle) | ❌ not its job | ✅ codified in the script |
| Durable human-approval gates | ✅ checkpoint / clu approve, persists until cleared | ❌ no mid-run input; split sign-off into separate workflows |
| Audit trail of who did what, when | ✅ clu history / clu log | 🟡 live progress view during the run, not a durable log |
| Tool-agnostic (any agent, CLI, or human) | ✅ it's just a CLI + SQLite | ❌ Claude Code / Anthropic API / Bedrock·Vertex·Foundry |
| Works offline, no account, no network | ✅ | ❌ paid plan + a provider |
| Instantiate a whole task graph from a script | ✅ clu batch (validated, atomic, thousands of issues) | 🟡 the script is the graph, but it's ephemeral |
| Import from other trackers (Linear, Notion, …) | ✅ pipe into clu batch | ❌ |
| Repeatable, codified orchestration | 🟡 templates + batch generators | ✅ save a run's script as a /command |
| See the shape of the work | ✅ web UI: board, ready, approvals | 🟡 terminal progress view |
✅ first-class · 🟡 partial / different shape · ❌ not a goal
When to reach for which
Reach for clu when the work outlives a single session or spans more than one agent or person: a shared backlog several Claude/Codex sessions pull from, a dependency graph you build up over days, work that needs a human approval gate that stays pending until someone clears it, or an audit trail of what happened. clu doesn't run anything for you — it's where the work lives.
Reach for a Claude workflow when one task needs more agents than a single conversation can coordinate right now: a codebase-wide bug sweep, a 500-file migration, research cross-checked across sources, or a plan drafted from several angles and weighed against each other. The orchestration is the point, and it's over when the run is.
In short: clu is the backlog and the coordination rules; a Claude workflow is a burst of horsepower against part of it.
How they compose
Because clu is just a CLI over a local database, a Claude workflow's agents can use it as their durable shared memory — so results outlive the run instead of evaporating into a context window.
-
Workflow → clu. A workflow's final stage pipes its findings into
clu batch, turning an ephemeral run into a persistent, dependency-aware backlog you (and later agents) keep working:# inside a workflow agent's step generate-findings-json | clu batch --group "Audit 2026-06" -
clu → workflow. A coordinator drains the durable backlog and hands a slice to a workflow for parallel execution, then records the outcome back:
clu ready --json -l run:clu-audit99 | …spawn a workflow over these… clu close clu-a3f8 # record the result durably -
Durable gate around a burst. Put a
clucheckpoint before and after a workflow stage so a human signs off — something a single workflow can't do mid-run (it has no mid-run input; you'd split it into separate workflows).
The two aren't competitors so much as different layers: clu remembers; a workflow does.
This comparison reflects Claude Code's dynamic workflows while they're in research preview, and clu as documented here. Both move quickly — check each project's own docs for the current details.