01 · Human approval
Risky actions wait for a person.
Approval is part of the protocol, not a sentence in a prompt. A run can stop before it pays, sends or deletes, route the question to the named people, and resume exactly where it left off.
v2.45.14 Open source: CC BY 4.0 spec, Apache 2.0 code
Open-source orchestration for multi-agent workflows.
AI agents now pay invoices, change code and email customers. OpenWOP is the open protocol that runs them as workflows you can watch, pause for a person's approval, and rewind. Any host that implements it runs them the same way, so no single vendor owns your agents.
OpenWOP in one minute.
The questions people ask first, answered plainly.
- What is OpenWOP?
- OpenWOP (Workflow Orchestration Protocol) is an open-source protocol for multi-agent workflow orchestration. It defines how a run of AI agents, tools and people starts, streams its events, stops for a person's approval, resumes and replays, over plain REST and Server-Sent Events, so it behaves the same on any host that implements it.
- Who is it for?
- Developers and teams building AI agent apps that take real actions, like paying, sending or changing records. Human approval, an audit trail and replay come with the protocol instead of being rebuilt in every app, and your workflows are not tied to one vendor's runtime.
- Is OpenWOP open source?
- Yes. The specification, JSON schemas and API definitions are open under CC BY 4.0, and the code is Apache 2.0: the TypeScript, Python and Go SDKs, the conformance suite, the CLI and the published packs. All of it is on GitHub, and the hosted reference app is free to try without signing up. See the repository.
- How is it different from LangGraph, CrewAI, AutoGen or Temporal?
- Those are frameworks and engines: you write agents with their library and run them in their runtime. OpenWOP is a protocol, a contract for the run itself. Any host that implements it gives you the same approvals, event log and replay, so code written against one host works against another. Compare it with each one.
- Does it replace MCP or A2A?
- No. MCP connects an agent to tools, and A2A lets agents delegate to each other. OpenWOP runs the workflow they take part in: an OpenWOP host can call MCP tools and A2A agents from inside a run. Read the comparison.
- How do I start?
- Try the hosted app with no sign-up, or start the reference host on your laptop with Node.js and call it with curl. The quickstart goes from a first run to approvals, replay and webhooks. Open the quickstart.
- When is OpenWOP not the right choice?
- If you are building a single agent application, a framework such as LangGraph or CrewAI is less overhead. For production durable execution today, Temporal is more mature, and for visual automation with many integrations, n8n fits better. OpenWOP is new, has one steward, and no independent organisation has implemented a host yet. See the comparisons.
What you can build with it.
Six multi-agent workflows the protocol is built for. They are scenarios, not customer stories, and each links to the part of the spec that makes it work.
- Finance approvals Four hundred invoices, paid overnight. A procurement agent clears the queue while you sleep, and stops at every payment over $10,000 until a person in finance says yes.
- Audit and compliance Rewind last Tuesday to step four. An auditor forks a finished run and watches it play out again, with recorded outcomes reused and every side effect suppressed.
- Long-running research A goal that outlives the deploy. A research agent works one objective across runs and restarts, until a separate judge agent calls it done or a safety bound stops it.
- Customer support From WhatsApp to another vendor’s agent. A customer messages a support workflow. It hands billing to an agent on a different host, and the conversation carries on.
- Voice ordering It listens, then draws the form. A voice agent takes the order, then returns a declarative form your app renders natively. No agent code executes on the client.
- Moving clouds You switch clouds. Your agents come with you. Agents, packs, schedules and workflows move to any compatible host. Secrets never leave; you reconnect them on arrival.
One workflow. Two hosts. The same history.
An agent checks a supplier invoice and has to pay it. The same workflow runs on a TypeScript host and a Python host. Both stop to ask a person before any money moves, and both record every step in the same event vocabulary.
The invoice
Acme Supply, INV-2291
$12,400 for 40 sensor kits, billed against purchase order 4471.
What the agent checked
- Matches purchase order 4471
- Amount within 2% of the order
- Acme Supply is an approved supplier
Not checked yet.
The outcome
Paid
A person in finance approved it. Receipt RC-8812 is attached to the run.
The event log, as each host recorded it
Step
TypeScript host
Python host
1
run.started invoice-review@3run.started invoice-review@32
node.started read-invoicenode.started read-invoice3
agent.decided Matches PO 4471, amount within 2%agent.decided Matches PO 4471, amount within 2%4
agent.handoff to the payments agentagent.handoff to the payments agent5
interrupt.requested Pay Acme Supply $12,400? Approver: financeinterrupt.requested Pay Acme Supply $12,400? Approver: finance6
interrupt.resolved Approved by a personinterrupt.resolved Approved by a person7
run.resumed from the saved staterun.resumed from the saved state8
node.started pay-suppliernode.started pay-supplier9
run.completed Paid. Receipt attached.run.completed Paid. Receipt attached.Pay Acme Supply $12,400?
The invoice matches purchase order 4471, the amount is within 2% of it, and Acme Supply is an approved supplier. Both runs are paused and saved. Nothing is paid until someone in finance decides.
9 of 9 events in the same order. Same final state on both hosts.
The illustration is scripted, but the result behind it is real: the OpenWOP paper reports that the same workflow definition, run on a TypeScript host and a Python host, produces identical final state and event-log structure for core workflows.
Now watch a real one.
The launch showcase in the OpenWOP app runs a real multi-agent workflow. One product brief becomes a strategy, a landing page, three emails and a social campaign; an editor agent reviews them; then the run stops for your approval. It uses your own model key, and nothing is published or sent.
Why a protocol, and not another framework?
Software used to do exactly what someone wrote. Agents decide while they run. That moves the important part of an AI system out of the model and into the run: the loop where an agent reasons, calls a tool, hands off to another agent, and waits for a person. It's where the decisions happen, where small errors compound, and where someone has to be able to say stop.
Today every platform builds that loop its own way. LangGraph, Temporal, Step Functions, vendor agent frameworks and in-house runtimes each have their own idea of what a run is, so none of them can read each other's runs. Pick one and you inherit its lifecycle, its debugger and its exit costs. The work your agents do belongs to whoever hosts them.
OpenWOP puts that loop on an open contract, the way HTTP did for pages and MCP did for tools, so the run belongs to you whichever host executes it.
Open protocols won when they standardized how systems talk, not just what they exchange.
- 1982SMTPAny mail server can hand a message to any other. Email becomes universal.
- 1991HTTPAny browser can ask any server for a page. The web happens.
- 2004BPMN, BPELWorkflows get standard definitions, and BPEL processes are executable. But lifecycle, events and human steps stay engine-specific, so processes rarely move between engines.
- 2024MCPAny model can reach any tool through one contract.
- 2025A2AAgents from different vendors can delegate to each other.
- NowOpenWOPThe run itself gets a contract: how it starts, streams, pauses for a person, resumes, and replays.
Four guarantees for agents that take real actions.
Each is pinned down by the protocol, so it holds on every compatible host, not just in one product. Under each is the part of the spec that makes it true.
02 · Replay
Rewind any run to see what happened.
Fork any run from any past step. In replay mode, recorded outcomes are reused and side effects are suppressed, so a replay never pays the invoice twice.
03 · Portability
Switch hosts without starting over.
Hosts advertise what they support, so clients negotiate instead of guessing. Move agents, packs, schedules and workflows to another compatible host. Secrets are never exported. You reconnect them at the destination.
04 · Accountability
See every decision. Cap every run.
Every decision, tool call and handoff is an event in one shared vocabulary, traced with OpenTelemetry, so a debugger written for one host can read another's runs. Runs carry caps on steps and time, and a budget that reserves spend up front. Whatever a tool or a search returns is marked untrusted, so poisoned input can't approve itself.
agent.decided, the run event log · security defaults · tool calling
Where it fits next to MCP, A2A and agent frameworks
OpenWOP doesn't replace MCP or A2A. It runs the workflow they take part in.
OpenWOP
The run: starts, streams, pauses for people, resumes, replays. Orchestrates everything below.
A2A
Agent to agent: discovery and delegation across vendors.
MCP
Agent to tool: one contract for tools, resources and prompts.
How OpenWOP compares with LangGraph, Temporal and Step Functions, property by property
| Property | OpenWOP | MCP | LangGraph | Temporal | Step Functions |
|---|---|---|---|---|---|
| Published API or wire specification | Yes: OpenAPI and AsyncAPI | Yes | No: a library (its hosted platform has its own API) | Yes: protobuf API, MIT-licensed | Workflow language is public (Amazon States Language); the service API is AWS's |
| Implementations of that specification | 7 hosts, none independent yet | Many | One library | One open-source server, plus Temporal Cloud | AWS only |
| Replay and fork of a past run | Replay and fork | Not its layer | Replay and fork | Replay and reset | Redrive, no fork |
| Multi-agent orchestration | Yes | Not its layer | Yes | General workflows | General workflows |
| Public conformance suite for other implementations | Yes | Inspector tool | No | No | No |
| Where a client can run its work | Any compliant host | Any MCP server | The LangGraph runtime | Any Temporal server | AWS |
A property check, not a verdict: Temporal and Step Functions are mature engines, and each project picks a different point in the design space. The difference OpenWOP is betting on is a contract many independent hosts implement and a suite that checks them. MCP’s Tasks extension gives it durable handles and resumption, but not replay or fork of a past execution. Sources: Temporal API, Amazon States Language, WS-BPEL 2.0. Last reviewed 2026-09-27. Compare OpenWOP with LangGraph, CrewAI, AutoGen, Temporal and n8n, or read how it fits with A2A and MCP.
You can use it today
The OpenWOP app is the reference host, running in production. Build agents and workflows on a visual canvas or in chat, run them against 44 published packs, and watch every event stream in. No sign-up needed to try it.
- BuildDrag steps onto a canvas, or describe the workflow in chat and let an agent draft it.
- WatchFollow the run live. Answer approval cards when it asks. The launch showcase turns one brief into a launch kit, with your own model key.
- Bring your own keysUse your own model provider. Keys you paste in a guest session are never stored.
- Host it yourselfRun the same app on your infrastructure, under your brand.
Build on it
No cloud account, vendor SDK or managed service required. Start the v2 reference host, create a run over HTTP, and read its events. The quickstart goes from there to approvals, forks and webhooks.
# Start the v2 reference host
$git clone https://github.com/openwop/openwop-examples.git
$cd openwop-examples/examples/hosts/v2-reference
$npm install --legacy-peer-deps && npm start
# Every v2 call sends the key and the version header
$export H1="Authorization: Bearer openwop-v2-dev-key" H2="OpenWOP-Version: 2"
# Create a run, then stream its events
$curl -s -X POST localhost:3838/runs -H "$H1" -H "$H2" \
-H 'Content-Type: application/json' \
-d '{"workflowId":"conformance-noop"}' > run.json
$curl -sN "localhost:3838/runs/$(jq -r '.runId|@uri' run.json)/events" \
-H "$H1" -H "$H2"
event: run.started
event: node.started
event: node.completed
event: run.completed
$git clone https://github.com/openwop/openwop-examples.git
$cd openwop-examples/examples/hosts/v2-reference
$npm install --legacy-peer-deps && npm start
# Every v2 call sends the key and the version header
$export H1="Authorization: Bearer openwop-v2-dev-key" H2="OpenWOP-Version: 2"
# Create a run, then stream its events
$curl -s -X POST localhost:3838/runs -H "$H1" -H "$H2" \
-H 'Content-Type: application/json' \
-d '{"workflowId":"conformance-noop"}' > run.json
$curl -sN "localhost:3838/runs/$(jq -r '.runId|@uri' run.json)/events" \
-H "$H1" -H "$H2"
event: run.started
event: node.started
event: node.completed
event: run.completed
- Add durable agent workflows to a productCall any compatible host over REST and SSE, with SDKs for TypeScript, Python and Go.
- Make your runtime a hostImplement the core floor of thirteen scenarios and prove it with the conformance suite.
- Publish packs and agentsSigned, reusable steps and agent definitions that run on any host that supports them.
- Evaluate it for productionSecurity posture, durability guarantees, and what is and isn't proven yet.
-
Drive any host from your terminal
npm install -g @openwop/cli, thenopenwop doctor.
More you can build, when you need it.
Optional features beyond the core, already in the spec. A host turns on the ones it supports, and apps that don’t use them keep working.
- Parallel fan-out. One step splits into many child runs and rejoins on a declared policy, and replays to the same result.
- Reviewable learning. What an agent learns is saved as a proposal that changes nothing until a person applies it.
- Standing goals. A durable objective works across runs until a separate judge agent calls it done or a safety bound stops it.
- External triggers. A webhook, an email or a form can start a run, with SSRF and redaction guards.
- Durable agent-to-agent tasks. Long cross-host work survives restarts and notifies you when it's done.
- Chat apps. Signal, iMessage, WhatsApp and Discord can each talk to a workflow, behind pairing and allow-lists.
- Voice. Streaming speech-to-text in, spoken replies out, advertised only where a host supports it.
- Agent-drawn UI. Agents return declarative forms and choices your client renders natively. No agent code executes.
- Multi-party conversations. Several agents in one thread, with a roster and a speaker on every turn.
- Credential egress. A resolved key can only reach the hosts you pin. Anything else fails closed.
- Approver routing. Approvals go to the named groups or roles, and that routing is fixed in history.
- Capability honesty. A host that doesn't claim a feature skips its tests cleanly instead of pretending.
What exists, and what doesn't yet
Every number links to its evidence.
7hosts measured against the conformance suite, including the production app
3first-party SDKs, TypeScript, Python and Go, with the same wire surface
42v2 spec documents: 25 core, 17 optional extension families
v2.45.14current release. 226 of 231 RFC extensions Accepted.
Versioning and stability
- Version
v2.45.x, the current release line
The current release line is v2.45.x. New capabilities arrive as optional, capability-gated extensions (226 of 231 RFCs Accepted to date), so an existing host keeps working.
- Transport
REST · SSE
OpenAPI 3.1 for requests, AsyncAPI 3.1 for event streams. In v2, REST and SSE are the whole wire.
- Discovery
/.well-known/openwop
Hosts advertise protocol version, profiles, limits and capabilities, so clients negotiate instead of guessing.
- Tracing
W3C trace context
Canonical OpenTelemetry names for runs, nodes, interrupts, provider calls and cost.
- Schemas
JSON Schema 2020-12
Machine-readable workflow, run, event, capability and pack shapes, served at their canonical
$id.- Compatibility
stable within a major
Wire shapes and package names stay stable through a major. A run in flight keeps the workflow revision it started with, so a deploy never changes its behavior.
- License
CC BY 4.0 spec · Apache 2.0 code
The specification, schemas and API definitions are CC BY 4.0: use and adapt them with attribution. The SDKs, conformance harness, CLI and tooling are Apache 2.0: patent-granting, with no field-of-use restrictions.
Let your agents do real work. Keep the final say.
Try it in your browser with no sign-up, or run the reference host on your laptop in a few minutes.