OpenWOP openwop.dev

For workflow authors

For workflow authors.

You're building a product that runs multi-agent workflows. You want the durable, replayable, resumable parts handled by something other than your application code, and you don't want to be locked to one runtime. This page is the shortest path from here to a running workflow on an OpenWOP-compatible host.

Run the quickstartTry the live host

What you actually need to know

OpenWOP gives you a wire contract — REST endpoints to start runs, SSE streams to consume events, signed webhooks for durable delivery, and a typed run lifecycle that survives restarts.

Read these three spec docs first

That's the minimum surface to author and submit a non-trivial workflow.

Reach for these when you hit them

What you'll write yourself

  • The workflow definition (graph + channels + reducers + nodes — declarative).
  • The node implementations OR a manifest pointing at pre-published node packs.
  • Your client code — a thin wrapper over the REST endpoints; the TypeScript (@openwop/openwop), Python (openwop-client) and Go SDKs in openwop/openwop-sdks cover the canonical methods.

What you don't write

  • A durable event log.
  • A suspend/resume mechanism.
  • A replay engine.
  • An interrupt state machine.
  • Provider routing and BYOK secret resolution.
  • HMAC-signed webhook delivery.

Those are host responsibilities, defined normatively in the spec corpus and verified by the conformance suite.

The full guide

Everything on this page, in order, with every link.

What you actually need to know

OpenWOP gives you a wire contract — REST endpoints to start runs, SSE streams to consume events, signed webhooks for durable delivery, and a typed run lifecycle that survives restarts. You write workflows declaratively (nodes + edges + typed channels + reducers) and submit them to any conformance-tested host. The host owns the runtime; your code owns the workflow shape.

You don't need to know how the host stores its event log, how it routes provider calls, or how it implements suspend/resume. Those are host concerns gated behind capability flags you can read from GET /.well-known/openwop.

Read these three spec docs first

  • Run options & lifecycle — what a run actually is, the per-run policy inputs, and the state machine.
  • REST endpoints — the canonical endpoint catalog (create, get, stream, interrupt, fork, etc.).
  • Stream modes — values / updates / messages / debug and how to pick the right one for your UI.

That's the minimum surface to author and submit a non-trivial workflow.

Reach for these when you hit them

  • Interrupts — when your workflow needs to pause for a human (clarification, approval, quorum, external event).
  • Webhooks — when you need durable, signed delivery of run events to your backend.
  • Replay — when you need to fork a run from a historical checkpoint (debugging, "what if" exploration, retroactive policy change).
  • Agent memory — when your supervisor agent needs to carry context across runs without leaking secrets or crossing tenant boundaries.

Get to a running workflow

The fastest path: start the v2 reference host (Node, about two minutes), create a run over HTTP, and watch its events stream back over SSE. The ten-minute quickstart walks the whole thing. The quickstart then covers approvals, forks and webhooks.

What you'll write yourself

  • The workflow definition (graph + channels + reducers + nodes — declarative).
  • The node implementations OR a manifest pointing at pre-published node packs.
  • Your client code — a thin wrapper over the REST endpoints; the TypeScript (@openwop/openwop), Python (openwop-client) and Go SDKs in openwop/openwop-sdks cover the canonical methods.

What you don't write

  • A durable event log.
  • A suspend/resume mechanism.
  • A replay engine.
  • An interrupt state machine.
  • Provider routing and BYOK secret resolution.
  • HMAC-signed webhook delivery.

Those are host responsibilities, defined normatively in the spec corpus and verified by the conformance suite.

Your next step.