Hydrate orchestration vs Claude Workflow

The overlap is real: both let one agent orchestrate many. So if you've used Workflow and wondered whether it replaces Hydrate's orchestration — or vice versa — this page draws the line. The short answer is that they compose: use Workflow for the bounded, in-session fan-out phases of a job (audit, design panel, research sweep), and Hydrate for the long-lived, cross-runtime epic that has to outlive any single context window.

What is Claude Workflow?

Claude Workflow (Claude Code v2.1.154+, all paid plans) is Anthropic's multi-agent orchestration tool. You describe a task; Claude writes a JavaScript script that spawns subagents using primitives like agent(), parallel() and pipeline(); a dedicated runtime executes that script in the background while your session stays responsive.

• The plan lives in code. Loops, branching and intermediate results sit in script variables — so only the final answer lands back in Claude's context window. That context-isolation is the headline win.
• Scale: up to 16 concurrent agents, 1,000 total per run.
• Observability: a /workflows view shows every phase, agent, prompt, tool call and token total live, with pause / resume / restart controls.
• Reusable: a successful run can be saved as a /command into .claude/workflows/.

It's a genuinely good tool, and for a bounded job that fits in one sitting it can beat hand-rolled orchestration. The rest of this page is about what happens when the job doesn't fit in one sitting — or one runtime.

Architecture differences (the deep version)

Where the fleet runs

• Claude Workflow runs in a background runtime inside your Claude Code session. Per Anthropic's docs: “If you exit Claude Code while a workflow is running, the next session starts the workflow fresh.” The fleet is bound to the session that launched it.
• Hydrate runs the fleet inside the hydrate-server daemon. The orchestrating session only issues HTTP/MCP calls — clearing its context, or closing it entirely, loses nothing the daemon holds. Worker goroutines use context.WithoutCancel so an HTTP handler returning doesn't kill the fleet.

Durability model

• Claude Workflow keeps intermediate results in script variables and can resume within the same session (completed agents return cached results). Across a session exit there is no resume — the run restarts.
• Hydrate persists every state transition via CAS writes to orch_dev_* tables in ~/.hydrate/data.db. On daemon restart, expired-lease tasks are swept and redriven; units carry lease_expires_at + worker_pid so orphaned work is reclaimed. The epic survives crashes, restarts and context boundaries.

Cross-runtime & cross-family

• Claude Workflow agents are Claude Code subagents. You can route a stage to a different Claude tier (Opus / Sonnet / Haiku), but the worker bodies are Claude. A workflow agent can call an MCP delegation tool to reach Codex, but that's a tool call, not a native worker.
• Hydrate spawns claude and codex CLIs as first-class worker bodies. The default develop loop has Claude implement and a second, independent model review and judge — swappable to Codex (HYDRATE_DEV_REVIEWER_BODY=codex). Cross-family review — one model family auditing another's work — is the deliberate quality moat, and it's structurally impossible in a single-family tool.

Observability & audit

• Claude Workflow has excellent live observability — the /workflows TUI is more polished out of the box than anything Hydrate ships. But it is ephemeral: it lives in the session, and there is no durable record to query once the session ends.
• Hydrate writes the raw plan, patch, review and verdict JSON for every unit and round to orch_dev_artifacts, keyed by unit + round + kind. The trade is real: Hydrate's live view is plainer, but its audit trail is permanent and queryable long after the run.

Control flow & sign-off

• Claude Workflow wins on authoring flexibility — arbitrary JS control flow you write per task. But it takes no human input mid-run; for a sign-off between stages you run each stage as its own workflow.
• Hydrate ships fixed, hardened modes (design dialectic, parallel develop) rather than free-form scripting, but bakes in human gates: a unit can land in needs_human or awaiting_signoff and wait — mid-epic — for a decision.

Where Claude Workflow is stronger

• Authoring flexibility. If your orchestration shape is bespoke — a tournament bracket, a self-repair loop, a one-off migration sweep — Workflow lets you script it directly in JS. Hydrate gives you two opinionated modes; anything outside them is a code change to the engine.
• Built-in live observability. The /workflows view — phases, per-agent prompts, tool calls, token totals, pause/resume/restart — is more polished, with zero setup, than Hydrate's dashboard.
• Save-as-command ergonomics. A successful run becomes a reusable /command in one keystroke. Hydrate's reusable unit is a skill template plus engine config.
• No infrastructure. It's part of Claude Code. No daemon to install, keep alive, or restart.
• It doesn't contend a global spawn cap. Workflow agents are governed by their own per-run concurrency cap, independent of Hydrate's daemon-wide spawn-rate limits — so for a bounded fan-out they sidestep the throttle contention a busy Hydrate daemon can hit.

Where Hydrate is stronger

• It survives the session ending. Hydrate's fleet is daemon-side, persisted in SQLite. Close the terminal, restart the machine, /clear the orchestrator — the epic keeps running and reconnects. Workflow restarts fresh.
• Cross-runtime and cross-family. Claude implements, Codex reviews and judges. A single-family tool cannot do adversarial cross-family review — and Hydrate's reach extends to Codex, Vibe and Copilot, not just Claude Code.
• A permanent, queryable audit trail. Every plan, patch, review and verdict is durable SQLite, not an in-session view that evaporates. You can answer “why did unit 3 fail round 2?” a week later.
• Human sign-off gates mid-epic. A unit can block on needs_human and wait for a decision without tearing down the run. Workflow takes no mid-run input.
• Crash recovery. Lease expiry + reaper redrive reclaim orphaned work after a daemon restart. There is no “start fresh” failure mode.

When to pick each one

In practice the two compose: drive a long Hydrate epic daemon-side, and reach for a Workflow run for the bounded, in-session fan-out phases inside it. They're not rivals so much as different altitudes of the same problem.