Introduction

flowwork is a durable, agent-native workflow engine that ships as one static binary. You author workflows in a flat JavaScript DSL and drive them with flowctl, the command-line client. State lives in a local Postgres the binary manages for you — so a workflow survives crashes, restarts, and long waits without losing its place.

What makes it agent-native is that one workflow can blend three paths:

• Deterministic — steps, branches, loops, and retries that run the same way every time.
• Generative — an LLM call as just another step (the LLM connector).
• Agentic — hand a step to a general agent like Claude Code or Codex to get the work done (the agent() step), and let agents author and operate the workflows themselves.

Author once, then mix hard logic, model inference, and agent judgement exactly where each fits.

The mental model: park & resume

A run advances one step at a time. When a step needs the outside world — a human to fill a form, an external system to call a webhook, a service reached through a connector, or an AI agent to make a judgement — the run parks: its state is written to Postgres and it drops out of the engine’s scheduler entirely (zero CPU, no in-memory timer). When the awaited event arrives, the run resumes exactly where it left off.

step ──▶ step ──▶ [form]  ·· parked in Postgres (WAITING_FORM) ··  resumes ──▶ step ──▶ done
                    ▲                                                  │
                    └────────── human submits the form ───────────────┘

That’s the whole idea: durable execution without you hand-rolling retries, leases, timers, and state machines in your own code.

What you get

• A real engine, not a library. Retries with backoff, error routing, conditional branches, loops, fan-out/fan-in, scheduled triggers, human-in-the-loop, and a full audit trail — built in.
• Authored in JavaScript. One workflow({ … }) call per file; step logic is plain functions.
• Connectors. Call HTTP APIs, LLMs, and any MCP server from a workflow step.
• AI-native. An agent() step hands a prompt to the Claude Code session driving the run, and a channel bridge pushes parked forms/prompts straight into that session — no polling.
• Runs on your machine. A single binary with an embedded database; nothing else to stand up.

Built for Claude Code

A workflow engine that can’t be driven by an AI agent is a 2010s tool. flowwork is agent-native from the ground up, and that shows up in two first-class features:

• The flowwork skill. flowctl skill install teaches Claude Code the entire loop — author the JavaScript DSL, register it, start runs, and drive them. You describe what you want; the agent writes and operates the workflow.
• Claude Code channels. Start a run with a channel attached and the engine pushes parked forms, webhooks, and agent() prompts straight into your session — no polling. The agent gathers the input or makes the judgement and submits it, and the run resumes.

Together they make “build and run a durable workflow” a conversation: the agent authors it, runs it, and answers the questions it raises — while the engine guarantees the durability underneath.

When to use flowwork

Reach for it when a process is multi-step and long-lived, needs to survive interruptions, or waits on humans or external systems: approvals, AI pipelines with a human gate, scheduled report-and-notify jobs, webhook-driven orchestration, multi-stage data processing. If you’d otherwise be writing your own state table, retry loop, and “where was I?” recovery logic, that’s the sweet spot.

It’s less of a fit for a single synchronous request/response with no waiting and no durability need — a plain function or script is simpler there.

Next steps

• Quickstart — install and run your first workflow in five minutes.
• Tutorial: an approval workflow — build a real human-in-the-loop flow.
• Core concepts — the vocabulary and lifecycle in one place.