Build a workflow
You're wiring durable multi-agent runs into a product and need to call a compliant host.
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.
next-worker, ask-user, or terminate.run.completed).
Real, verifiable artifacts behind the protocol — not roadmap claims. Every number below links to the evidence.
api.myndhyve.ai — the first to be certified a full openwop-agent-platform, passing every conformance check it claimsCOMPATIBILITY.mdOpenWOP is a protocol with four common entry points. Each card lists the real specs and tools the role uses; nothing routes off into vapor.
You're wiring durable multi-agent runs into a product and need to call a compliant host.
You're implementing OpenWOP against a runtime (yours, or one your customers picked).
You're publishing reusable workflow components — node packs, chain packs, or agent definitions.
You're vetting whether OpenWOP fits your durability, security, and interop requirements.
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.
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.
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.
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.
Seven primitives. Pick one to expand — each is independently specified, conformance-tested, and linked to the canonical doc.
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.
Every run moves through a typed state machine: pending → running ⇄ waiting → one of three terminal states (completed, failed, cancelled). Transitions are spec-pinned, so clients on any compliant host see the same lifecycle.
At any non-terminal state the host can serve a snapshot — the engine's reduced view of the run — and an ordered event log that drove it there. Replay from event log + snapshot is deterministic by construction.
Resume from waiting is the same wire shape regardless of whether the pause was a human approval, a clarification round, an external event, or a sub-workflow handoff.
Multi-agent workflows need a wire shape for who took which turn. The protocol defines AgentRef — agent identity that travels with every reasoning event — and a closed set of five reasoning events: agent.reasoned, agent.toolCalled, agent.toolReturned, agent.handoff, agent.decided.
Conversations are first-class. A conversation interrupt opens a multi-turn exchange that emits conversation.opened / exchanged / closed events without re-entering the workflow on every turn.
Cross-run memory lives behind a host-side memory adapter with four operations (list, get, put, delete) and a redaction invariant that composes with BYOK secret handling. The protocol pins the read-path semantics; the storage backend is a host choice.
These surfaces roll up into one named target: the openwop-agent-platform profile (RFC 0085). A host can claim it at two levels. partial is the floor that makes agents usable — ten capabilities covering a live agent runtime with manifests, a tool catalog with invocation hooks, safe outbound fetch, provider-usage reporting, a prompt library, memory, feedback, and replay (or declared nondeterminism). full adds the governance layer — access control, tenant scoping, memory attribution, debug bundles, durable triggers, and egress policy. Either claim must be earned: a host reports a level only when the conformance scenarios for every capability in it pass, never on self-description. One independent host (MyndHyve) is certified full, all sixteen terms re-verified from its public discovery document.
A run reaches a human checkpoint via one canonical interrupt shape that pauses execution and emits a typed payload. Four interrupt kinds cover the field: approval, clarification, refinement, and cancellation.
Resume goes back through the same API contract — the host knows nothing about which UI handled the prompt, which broker delivered the notification, or whether the response came from a human, an A2A peer, or a queue. The payload schema is what's normative.
Cancellation cascades across parent and child runs spawned via sub-workflow dispatch, so cooperative stop is deterministic at the boundary.
One canonical event log feeds two delivery shapes. Server-Sent Events (SSE) on /v1/runs/{runId}/events serves browsers and CLIs; HMAC-signed webhooks serve back-end subscribers that need durable server-to-server delivery.
The SSE endpoint accepts a ?mode= query parameter with four canonical taps — values for dashboards, updates for chat UIs, messages for token-style streaming, and debug for full event fidelity. Hosts may also batch via ?bufferMs=N for high-volume runs.
Webhooks are signed with HMAC-SHA256 over the canonical payload + nonce; the verification recipe is replay-attack-resistant and the host honors circuit-breaker semantics on a misbehaving subscriber.
Node Packs are signed bundles of reusable node implementations — the agent equivalent of language packages. A pack carries a manifest (pack.json), one or more node implementations, optional agent manifests, and a detached signature.
Packs may be authored in TypeScript, Python, Go, or pre-compiled WASM. The WASM path gives cross-language portability: any host with a WASM runtime loads the same artifact identically, so a Rust-authored pack runs unchanged on a JavaScript reference host.
The canonical signed registry is live at packs.openwop.dev — 62 published packs, 88 signed versions, every tarball verifiable back to the openwop-registry-root signing key. Namespace tiers keep provenance explicit: the core tier (core.openwop.*) ships 22 foundational packs — HTTP, files, flow control, human-in-the-loop, agents, data, RAG, messaging, MCP, and more — as the protocol's baseline; the vendor tier carries a 38-pack production extension stack (vendor.myndhyve.*) plus a Rust-authored WASM reference pack, demonstrating real-world consumption beyond the core; the community tier is open via PR-based publishing. Host-private registries (private.*) are first-class for tenanted deployments.
Think of an agent-driven kanban board. Stacking is the board itself: each column is a stack of cards waiting to be picked up, and the column structure is fixed when the workflow is defined. Chaining is what happens once a card goes in-flight — the orchestrator dispatches the sequence of nodes that does the work. A simple card may be a single node; a complex one expands into a chain (classify → enrich → summarize → ask-user) via core.dispatch, with each runOrchestrator.decided event picking the next link.
core.subWorkflow extends per-card chains across parent→child runs with cascading cancellation and nested OTel spans. The static/dynamic boundary is what keeps replay deterministic: dispatch picks the path through the graph, but never mutates the graph mid-run.
Below is the contract — every row points at a stable surface (transport, schema, license, versioning) that compliant hosts can be measured against.
1.1.x (v1 stable)
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.
REST · SSE · gRPC
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.
/.well-known/openwop
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.
W3C trace context
Canonical OpenTelemetry names and attributes for runs, nodes, interrupts, provider calls, and cost attribution.
JSON Schema 2020-12
Machine-readable workflow, run, event, capability, pack, and debug-bundle shapes.
npm · PyPI · Go
@openwop/openwop · @openwop/openwop-conformance · openwop-client · openwop/sdk/go
4 hosts + sample app
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.
Apache 2.0
Trademark-clean, patent-granting, no field-of-use restrictions.
v1.x stable
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Agentic systems need three different contracts — and these three open protocols each own one. They compose rather than compete.
Capability discovery, delegation, and collaborative tasks across vendor, framework, and language boundaries — without exposing an agent's internals.
Standardized access to tools, resources, and prompts, so a model or app can act on external systems through one client-server contract.
Starts and observes durable runs that orchestrate agents, tools, humans, and events — with streaming, replay, and state that stays portable across hosts.
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.
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.
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.
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.
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.
@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.
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.
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.
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.
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.
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.
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.
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.
TypeScript reference SDK. Typed run client, SSE consumer, error mapping, idempotency helpers. Zero runtime deps.
Black-box conformance harness. Point it at any host to verify v1 compliance against the full scenario corpus.
Python reference SDK. Stdlib-only, zero dependencies. Hand-rolled SSE parser; mirrors the TypeScript surface.
Go reference SDK. Single module, no external deps. Run client, SSE consumer, typed errors. Pinned at v1.1.7.
No results.
↑↓ navigate · ↵ open · esc close