OpenWOP openwop.dev
v1.1.8 Workflow Orchestration Protocol — Core Specification

OpenWOP adds a
thinking layer
to your software. An open, vendor-neutral
protocol for durable
multi-agent orchestration.

Apache 2.0 licensed REST · SSE · gRPC wire contract Conformance tested npm · PyPI · Go SDKs

OpenWOP is an open protocol for AI agent workflows: agents decide, call tools, and talk to humans — and every run can be paused, resumed, replayed, and moved to another host.

  1. CLIENT opens REST + SSE to the host.
  2. ORCHESTRATOR (supervisor agent) decides one of: next-worker, ask-user, or terminate.
  3. Decision dispatches to a WORKER (calls tools), a CONVERSATION (multi-turn with a human), or TERMINATE (emits run.completed).
  4. Every event flows into the EVENT LOG and streams to subscribers: WEBHOOKS (signed with HMAC) and OTel (OTel — trace + cost).
An OpenWOP-compliant workflow editor: node pack catalog on the left (Agent Run, Tool, Memory, Output Parser, Model Selector, Chat Completion, Structured Output), a directed-acyclic-graph canvas in the center wiring a Kickoff node through three parallel Extract Source branches into Normalize and Enrich nodes, and a Workflow inspector panel on the right showing the run's name, ID, and default-inputs JSON.
An OpenWOP-compliant workflow editor. Node pack catalog left, workflow canvas center, run inspector right — every artifact on this screen is described by the open v1 spec. Open the live builder
§ 01 / Running today

What ships right now.

Real, verifiable artifacts behind the protocol — not roadmap claims. Every number below links to the evidence.

§ 02 / Where to start

Pick your path.

OpenWOP is a protocol with four common entry points. Each card lists the real specs and tools the role uses; nothing routes off into vapor.

§ 03 / Prologue

The hard part isn't the model.

It's the layer between the calls: when one agent hands off to another, what happens when a human steps in, what state survives a restart, how the run replays for an auditor. Software used to be deterministic — every output traced back to a rule a human wrote. The applications worth building now make decisions during the run, and that layer is where intelligence enters them. It's also where state, durability, and observability have to be rebuilt to support it.

Every platform reinvents that layer with its own conventions — LangGraph, Temporal, Step Functions, vendor agent frameworks, in-house runtimes — and the implementations aren't wire-compatible. Code written against one host doesn't move to another. The debugger you wrote for your runtime can't read someone else's. Customers who pick a platform inherit its lifecycle, whether they want to or not.

OpenWOP is the wire contract this layer has been missing. It's a protocol, not a runtime or a framework, that defines how clients and hosts start, stream, interrupt, resume, replay, validate, and observe durable multi-agent workflows. The layer where your software thinks becomes portable: something you can move between hosts, inspect across versions, or replace when the runtime stops serving you.

It's also the layer where agents fail in production. An agent is a loop — reason, call a tool, observe, repeat — and the failure modes everyone hits are properties of that loop, not the model inside it: small per-step error rates compound across steps, every lap costs tokens, an open-ended loop may never decide it's done, and a model that can call a tool can be tricked into calling the wrong one. A better model doesn't fix any of those. Bounding the loop does. Because OpenWOP owns the run, the controls that fence a production agent live in the protocol: a cap on loop iterations and wall-clock time, a budget that reserves and exhausts spend with breach events, an approval interrupt that suspends before an irreversible action and resumes deterministically, and a trust boundary that marks tool and retrieval output untrusted so poisoned input can't advance an approval gate. The protocol doesn't make the model smarter — it makes the loop observable, bounded, and fail-closed. See how the three layers compare →

OpenWOP is the common language for the layer where your software thinks.

§ 04 / Specification

Three things the protocol standardizes.

01core

Durable run control

Start a run once, pause it for a human, resume it after a deploy, replay it for an auditor — and get the same behavior on every compliant host. The lifecycle (idempotent creation, suspend / resume, replay / fork, terminal event ordering) is typed and spec-pinned.

02policy

Provider policy & BYOK

Whose API keys a run uses, which providers it may call, and what gets redacted from logs are part of the host contract — BYOK secret resolution, API scopes, and per-run provider routing, instead of hidden client convention.

03observability

Trace & cost, end‑to‑end

See what every agent did, why, and what it cost — on any compliant host, with the same tooling. OpenTelemetry names, W3C trace context, run events, and cost-attribution fields are the shared debugging and operations vocabulary.

§ 05 / Anatomy

What lives inside an OpenWOP run.

Seven primitives. Pick one to expand — each is independently specified, conformance-tested, and linked to the canonical doc.

A

Workflow definition

workflow-definition.schema.json

An OpenWOP workflow is a declarative graph. Nodes are units of work; edges wire them together; typed channels carry shared state between them; reducers resolve concurrent writes at fan-in points; and per-run policy inputs parameterize each invocation without leaking into the definition itself.

The definition is content-addressable JSON — the same input always builds the same graph, so two hosts loading the same definition produce the same engine surface. Hosts validate definitions on registration and again at run-create time, so a malformed graph never reaches the engine.

Per-run inputs (provider routing, BYOK secrets, idempotency keys, run options, workflow version pin) flow into the engine alongside the definition. They never mutate the graph — they parameterize how the engine executes it.

PER-RUN POLICY · resolved at run-create time providers · secrets · idempotency · runOptions · workflowVersion · BYOK refs applied by engine ↓ applied at run-create intake T: Brief draft scan merge reducer: appendUnique T: Report publish graph + types + reducers = the engine's view of the workflow channels-and-reducers.md
FIG. 02A · WORKFLOW DEFINITIONDAG · CHANNELS · REDUCERS
§ 06 / Stability

Stable, versioned, readable in an afternoon.

Below is the contract — every row points at a stable surface (transport, schema, license, versioning) that compliant hosts can be measured against.

Version

1.1.x (v1 stable)

What this means

The v1.0 wire contract froze 2026-05-08; the current release line is v1.1.x. Everything since the freeze is additive — new capabilities ship as optional, capability-gated extensions (98 of 103 RFCs Accepted to date), so a host built against v1.0 still passes today's required surface. The extension surface now spans the full agent platform (rosters, dispatch, memory, tool catalogs, budgets), auth profiles with enterprise identity, gRPC transport, and WASM pack execution — and one independent production host (MyndHyve) runs the complete agent-platform set live. Release-by-release detail is in the changelog.

Transport

REST · SSE · gRPC

What this means

OpenAPI 3.1 for request / response endpoints; AsyncAPI 3.1 for event streams. The gRPC transport profile (api/grpc/openwop.proto, canonical openwop.v1.Engine service) is profile-gated via capabilities.supportedTransports and gives byte-identical run semantics over a typed RPC contract for hosts that need it.

Discovery

/.well-known/openwop

What this means

Hosts advertise protocol version, capability profiles, limits, fixtures, host surfaces, and implementation metadata so clients negotiate features instead of guessing. The v1.x profile set covers core run control, SSE and poll streams, secrets, provider policy, replay/fork, fixtures, node packs, production posture, audit integrity, scoped discovery, interrupt profiles, auth profiles, and optional agent-reasoning streaming. Optional profiles are claimed only when the host implements them end-to-end.

Tracing

W3C trace context

What this means

Canonical OpenTelemetry names and attributes for runs, nodes, interrupts, provider calls, and cost attribution.

Schema

JSON Schema 2020-12

What this means

Machine-readable workflow, run, event, capability, pack, and debug-bundle shapes.

Reference hosts

4 hosts + sample app

What this means

In-memory (Node), SQLite (Node), Python (stdlib-only), and Postgres. The Postgres host is the production-shaped path with mechanical proof for claim acquisition, orphan recovery, backpressure, retention, and auth profiles. The Python host passes 100% of applicable scenarios in @openwop/openwop-conformance, proving cross-language wire-shape portability. The workflow-engine sample app now ships a fixture-backed backend and React UI for hands-on adoption. See INTEROP-MATRIX.md for full claims and conformance evidence.

License

Apache 2.0

What this means

Trademark-clean, patent-granting, no field-of-use restrictions.

Compatibility

v1.x stable

What this means

Wire shapes and package names are stable through v1.x releases. Four versioning axes — engine, event-log, per-event schema, and per-(run, changeId) pinning — keep in-flight runs safe across deploys. See COMPATIBILITY.md and PUBLISHING.md.

§ 07 / Implementation proof

The recent work turns the contract into runnable evidence.

OpenWOP is not just prose. The repository carries reference hosts, a deployable sample app, vendored fixture workflows, and black-box conformance checks that keep host claims honest.

343scenario files
62indexed packs
88signed pack versions
4reference hosts
70JSON schemas
01 · sample host

Fixtures ship with the app image.

The workflow-engine sample now loads and advertises conformance fixtures at discovery time, and its Docker image vendors the fixture corpus as real files with a sync gate to prevent drift.

02 · host surfaces

Storage and messaging paths are exercised.

Table schemas, cursor pagination, SQL transactions, cache and key-value TTLs, blob roundtrips, presigned blob URLs, vector search, full-text search, queues, dead-letter routing, and stream snapshots all have runnable sample-host seams.

03 · replay

Determinism has concrete checks.

The suite now probes a canonical LLM cache-key recipe, correlation replay behavior, schema-version floors, and BYOK redaction so replay-sensitive integrations can test the pieces that usually hide inside a runtime.

04 · agents

Agents you can list and put to work.

A host now publishes the agents it offers, so you can pick one, hand it a task, and watch it think and decide as it goes — the reasoning streamed in order with a clean finish. The first independent host already runs them in production for its own customers.

05 · messaging

Reach a workflow from your chat apps.

Signal, iMessage, WhatsApp, and Discord can each talk to a workflow or an agent, keep the whole conversation in one thread, and stay behind the pairing and allow-lists you set.

06 · packs

Hosts can share their own result types and chat cards.

Beyond the workflow building blocks, a host can now package its own kinds of output — checked and rendered for you — plus interactive cards that come to life right inside a chat.

07 · capability honesty

Claims are tested as behavior.

Capability toggles let the harness verify register-time refusal paths, while hosts that do not claim a feature skip cleanly instead of pretending to implement it.

08 · release hygiene

CI blocks common drift.

The corpus gate enforces fixture sync, conformance soak builds the TypeScript SDK before running, and Docker build arguments keep the sample image honest about whether fixtures are present.

09 · reviewable learning

Agents propose; people approve.

What an agent learns is saved as an inert proposal — it changes nothing until a person reviews it and applies it through the host's approval gate. Nothing rewrites itself behind your back.

10 · standing goals

Objectives that persist across runs.

Hand a host a durable goal and it keeps working toward it across many runs — until an independent judge calls it satisfied or a safety bound stops it. No goal runs unattended forever.

11 · portability

Move your setup between hosts.

Export your agents, packs, schedules, and rosters as a refs-only bundle and import them into another host. Secrets never travel as values — you rebind them at the destination. Dry-run first, always.

12 · external triggers

Outside events can start a run.

A webhook, inbound email, or form submission can kick off a workflow. The incoming event is handed to the run as trigger data and never written to the event log, with SSRF and content-redaction guards built in.

13 · durable A2A tasks

Long agent-to-agent work survives restarts.

Agent-to-agent calls can run as durable tasks you re-attach to and get push-notified about — not just synchronous request/response — so cross-host work outlives a single connection.

§ 08 / In context

Where it sits, and what it isn't.

The agentic stack · A2A · MCP · OpenWOP

Three layers, not three rivals.

Agentic systems need three different contracts — and these three open protocols each own one. They compose rather than compete.

A2A
Horizontal · agent ↔ agent

Capability discovery, delegation, and collaborative tasks across vendor, framework, and language boundaries — without exposing an agent's internals.

MCP
Vertical · agent ↔ tool/context

Standardized access to tools, resources, and prompts, so a model or app can act on external systems through one client-server contract.

OpenWOP
Durable · workflow control

Starts and observes durable runs that orchestrate agents, tools, humans, and events — with streaming, replay, and state that stays portable across hosts.

A2A is the horizontal agent-to-agent layer. MCP is the vertical agent-to-tool/context layer. OpenWOP is the durable workflow-control layer that can orchestrate agents, tools, humans, events, and replayable state.
Read the full A2A · MCP · OpenWOP comparison
Adjacent · MCP

Above the model, not beside it.

Model Context Protocol exposes tools, resources, and prompts to LLM apps. OpenWOP sits at the workflow layer: starting runs, pausing them for humans, streaming events, replaying history, and validating host behavior. The two compose: v1.1+ hosts can advertise an MCP client capability and route an LLM through the core.mcp.toolCall node, with MCP content carried under an untrusted trust-boundary per the OpenWOP threat model.

MCP standardizes tool access. OpenWOP standardizes durable workflow execution. A v1.1+ host can call the former from inside the latter.
Vs. proprietary

Open by default. Vendor-neutral on purpose.

Agent frameworks are great when one runtime owns the application. OpenWOP is the wire contract between clients, hosts, SDKs, debuggers, and conformance tooling, so product code can depend on a public protocol.

The protocol is portable; each host still owns its runtime guarantees.

At a glance.

OpenWOP is a protocol; the other surfaces below are runtimes, libraries, or peer protocols at a different layer. The grid is a property check, not a verdict — each picks a different point in the design space.

Property OpenWOP MCP LangGraph Temporal Step Functions
Public wire specification Yes Yes Library Proprietary Proprietary
Multiple independent implementations 4 reference + 1 sibling Multiple Single library Single vendor Single vendor
Durable replay & fork Yes n/a (tool layer) Checkpoints Yes Yes
Multi-agent orchestration scope Yes n/a (tool layer) Yes General workflows General workflows
Public conformance suite Yes Inspector tool
Cross-host client portability Yes Yes Runtime-bound Vendor-bound Vendor-bound

† Sibling project = same maintainer org as OpenWOP itself. The "1 sibling" referenced in the row above is vendor.myndhyve; a genuinely independent third-party host is tracked under ROADMAP.md → Independent-implementation tripwire.

Sources: modelcontextprotocol.io, LangGraph docs, Temporal docs, AWS Step Functions docs. Last reviewed 2026-05-21. Corrections welcome via GitHub issues.

§ 09 / Get started

Ten minutes to a running workflow.

Clone the openwop-examples repo, start the in-memory reference host, create a run over HTTP, and inspect the same run through the v1 API. No cloud account, vendor SDK, or managed service required. Three further reference hosts — SQLite, Python (stdlib-only), and Postgres — exercise durability, cross-language portability, and multi-process paths against the same conformance suite.

~/projects/openwop-examples · zsh ⌘⇧T
# Start the in-memory reference host
$git clone https://github.com/openwop/openwop-examples.git
$cd openwop-examples/examples/hosts/in-memory
$npm install && npm start

# Discover host capabilities
$curl http://127.0.0.1:3737/.well-known/openwop
protocolVersion: 1.0

# Create a conformance fixture run
$curl -s -X POST http://127.0.0.1:3737/v1/runs \
-H 'Authorization: Bearer openwop-inmem-dev-key' \
-H 'Content-Type: application/json' \
-d '{"workflowId":"conformance-noop"}'
▸ runId = run-...
▸ status = pending → running → completed

# Stream events for the run
$curl -N -H 'Authorization: Bearer openwop-inmem-dev-key'
http://127.0.0.1:3737/v1/runs/run-.../events
event: run.started
event: run.completed

$
↓ self-host

Or run your own white-label copy.

The same workflow-engine deployment, re-skinnable to your brand without forking core logic. Step-by-step back-end, front-end, seeding, and CLI setup — plus a downloadable source bundle.

§ 09.5 / Try it from your terminal

Drive any OpenWOP host from a single command.

@openwop/cli is a control-plane CLI for any OpenWOP-compatible host — auth onboarding, capabilities discovery, run submission + SSE streaming, prompts & memory & agents inspection, HITL interrupt resume, and channel messaging (Signal · iMessage · WhatsApp · Discord, all opt-in local adapters). One npm install, no proprietary client.

~ · zsh ⌘⇧T
# Install the OpenWOP CLI
$npm install -g @openwop/cli

# Point it at any compatible host
$export OPENWOP_BASE_URL=https://app.openwop.dev/api

# Verify auth + capabilities advertisement
$openwop doctor
▸ host = app.openwop.dev
▸ profile = production
▸ auth = ok

$
  • Auth · onboard, BYOK key issuance.
  • Workflows · runs create / get / events with values/updates/messages/debug SSE.
  • Agents · agents list / dispatch against the manifest runtime.
  • HITL · interrupts list / resume via signed-token callback.
  • Channels · messaging + relay daemons (non-normative host extension).
§ 10 / Try it live

A real host, already running.

app.openwop.dev runs the workflow-engine reference deployment with the v1 conformance fixtures preloaded. Build a workflow against the published core.openwop.* pack catalog, run it, watch the live SSE event stream — anonymous, no install.

  1. 01 · open

    Land anonymously.

    Visit app.openwop.dev. The first hit creates a session-scoped identity — no email, no sign-up. You can sign in with Google or GitHub later if you want runs and workflows to persist past 24 hours.

  2. 02 · build

    Wire a workflow on the canvas.

    Drag nodes from the core.openwop.* pack library — http, files, flow, hitl, agents, data. Connect them. Save. The same workflow document the canvas writes is what the v1 API accepts on POST /v1/runs.

  3. 03 · run

    Watch the SSE stream populate.

    Press Run. Every state transition, every node start, every values / updates mode tap surfaces in the run page in real time — the exact event vocabulary defined in the spec, not a UI synthesis.

  4. 04 · interrupt

    Resolve a human checkpoint.

    Drop a core.openwop.hitl node into the path. When the run reaches it, an interrupt card surfaces in the browser. Respond — the host resumes the run through the same POST /v1/runs/{runId}/events contract a back-end subscriber would use.

  5. 05 · inspect

    Read the host's capability claims.

    Fetch /.well-known/openwop. Cross-check the advertised capability set against the conformance suite's honest-claims gate to see exactly what this deployment will and won't do.

  6. 06 · optional · BYOK

    Paste your own key.

    Sign in, open Settings → BYOK, and paste a model-provider key. It stays scoped to your session, never lands on disk, and is redacted from event payloads per the protocol's BYOK invariant. See privacy & cookies.

Open app.openwop.dev Browser-session scoped · sessions reset every 24h Smoke-test script Privacy & cookies
§ 11 / Ecosystem

Build against the protocol.

01 · npmview
@openwop/openwop

TypeScript reference SDK. Typed run client, SSE consumer, error mapping, idempotency helpers. Zero runtime deps.

$npm i @openwop/openwop
02 · npmview
@openwop/openwop-conformance

Black-box conformance harness. Point it at any host to verify v1 compliance against the full scenario corpus.

$npx @openwop/openwop-conformance
03 · PyPIview
openwop-client

Python reference SDK. Stdlib-only, zero dependencies. Hand-rolled SSE parser; mirrors the TypeScript surface.

$pip install openwop-client
04 · pkg.go.devview
openwop/sdk/go

Go reference SDK. Single module, no external deps. Run client, SSE consumer, typed errors. Pinned at v1.1.7.

$go get github.com/openwop/openwop/sdk/go