OpenWOP openwop.dev
v1.1.7 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 multi-agent workflow orchestration: a supervisor agent decides, worker agents call tools, and conversation agents talk to humans — all streamed over REST, SSE, and signed webhooks, so runs stay durable, replayable, and portable across compliant hosts without a proprietary runtime lock-in.

Try the live demo ↗ Run the quickstart → View the spec → Read the paper ↗
  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, DAG 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.

5
hosts measured
4 reference · 1 independent host live in production at api.myndhyve.ai — the first to be certified a full openwop-agent-platform, passing every conformance check it claims
3
first-party SDKs
TypeScript on npm · Python on PyPI · Go module
52
spec documents
REST · SSE · signed webhooks · BYOK · replay · node packs
v1.1.7
stable · additive
Apache 2.0 · 86 of 90 RFC extensions Accepted · additive-only evolution under COMPATIBILITY.md
§ 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.

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

§ 04 / Specification

Three things the protocol standardizes.

01core

Durable run control

A typed run lifecycle with idempotent creation, suspend / resume, replay / fork, and terminal event ordering that compliant hosts expose consistently.

02policy

Provider policy & BYOK

API scopes, per-run provider routing, BYOK secret resolution, and redaction rules are part of the host contract rather than hidden client convention.

03observability

Trace & cost, end‑to‑end

OpenTelemetry names, W3C trace context, run events, and cost-attribution fields give compliant hosts a shared vocabulary for debugging and operations.

§ 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
View the channels & reducers spec →
§ 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

v1.0 wire contract frozen 2026-05-08 · v1.1.0 released 2026-05-12 · v1.1.4 released 2026-05-26 (MyndHyve's production extensions live + the autonomous-agent runtime + 19 spec milestones landed) · v1.1.5 released 2026-05-28 (the OpenWOP command-line tool launched, chat reaches workflows from Signal · WhatsApp · iMessage · Discord, agents you can list and run — proven on an independent host, and new result-type and chat-card packs) · v1.1.7 released 2026-06-02 (the Active→Accepted graduation program + agent-platform capstone — and the agent-platform read surface published to the Python and Go SDKs, alongside a TypeScript SDK minor at v1.2.0). Current work expands behavior coverage without breaking required fields, event payloads, endpoint contracts, or package names. Since v1.1.5 the agent-platform extension program graduated end-to-end on the independent MyndHyve host: a full openwop-agent-platform (RFC 0085) — standing agent rosters, org-charts, live manifest dispatch, an eval → deploy → eval-gated-promotion lifecycle, a portable tool catalog with credential-provenance/egress policy, per-run budget & cost governance, and reconciled agent memory — alongside SAML/SCIM enterprise identity, a Core Standard Profile floor, and a real-isolation WASM sandbox reference host. 86 of the 90 RFCs are now Accepted. The active surface now includes auth profiles, gRPC transport, WASM pack execution, multi-agent identity and reasoning, memory, orchestrator dispatch, agent workspace, host heartbeat, sub-workflow output attestation, tool-invocation hooks, and fixture-backed host behavior.

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.

SDKs

npm · PyPI · Go

Packages

@openwop/openwop · @openwop/openwop-conformance · openwop-client · openwop/sdk/go

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.

301scenario files
62indexed packs
88signed pack versions
4reference hosts
55JSON 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.

§ 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 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.

Run the quickstart → Reference hosts ↗
~/projects/openwop · zsh ⌘⇧T
# Start the in-memory reference host
$git clone https://github.com/openwop/openwop.git
$cd openwop/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.

Install the demo app →
§ 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).

Command catalog & quickstart → @openwop/cli on npm ↗

§ 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 44 published core.openwop.* packs, 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