# Frequently asked questions

> Source: https://openwop.dev/faq/ · OpenWOP, the open-source protocol for multi-agent workflow orchestration.

OpenWOP is a wire-level protocol, not a library or runtime. These are the questions people ask first when deciding whether it fits their work. Each answer links to the document that has the full rule.

Last reviewed: 2026-09-27.

## Why not just use LangGraph or LangChain?

LangGraph is a library; OpenWOP is a wire contract. LangGraph workflows depend on the Python runtime they were authored in — the engine, the checkpointer, and the serialization format are all internal to the library. OpenWOP defines what goes over the wire — REST endpoints, SSE event shapes, signed webhook payloads, BYOK secret resolution — so a workflow authored for one host can move to a different host without rewriting application code.

If you only ever run on a single runtime, a library is the simpler choice. If you want your workflows portable across hosts (your own, your customers', a future managed service), the wire contract is the point. See [Where it sits, and what it isn't](https://openwop.dev/#context) for the longer comparison and the [comparison table](https://openwop.dev/#context) at a glance.

## Why not Temporal or AWS Step Functions?

Both are excellent durable workflow engines, but each is the contract of one product. Temporal's API is the API of the Temporal server; Step Functions workflows run only on AWS.

OpenWOP aims for one contract that many independent hosts implement, with a public conformance suite that checks them. To be clear about where that stands: every host on the [leaderboard](https://openwop.dev/conformance/) today is run by the steward or a steward-affiliated organization. No independent host exists yet.

OpenWOP is also built for multi-agent execution (supervisor and worker agents, conversations, BYOK provider routing, replay-safe agent memory). With Temporal or Step Functions you would build those on top yourself.

## What does it actually cost a host to implement OpenWOP?

Start small. The `openwop-discovery-core` profile only asks for a valid discovery document and correct version handling. The [v2 reference host](https://github.com/openwop/openwop-examples/tree/main/examples/hosts/v2-reference) shows a complete implementation to copy from.

Each capability you add brings its own surface and its own conformance scenarios: webhooks (HMAC signing), interrupts, BYOK (provider routing and redaction), audit-log signing, `production` (backpressure and retention). You can run those scenarios against your host with no wrapper code. v2 has three named profiles; their requirements are on [`/profiles/`](https://openwop.dev/profiles/).

## Why publish packs to `packs.openwop.dev` instead of npm or PyPI?

Packs need a signature scoped to a namespace: an Ed25519 signature over the canonical `pack.json`, checked against a registry key that is allowed to sign that namespace. npm and PyPI don't provide that for arbitrary payloads.

The OpenWOP registry serves the signed tarball, the detached signature and the publisher's public key. The [pack-consumer reference implementation](https://github.com/openwop/openwop-examples/blob/main/examples/hosts/postgres/src/pack-consumer.ts) shows a host verifying the signature at install time.

You can also publish to a private registry or a tenant-scoped mirror. The [Packs](https://openwop.dev/spec/v2/core/packs.html) spec defines the discovery shape, so clients can point at any registry that serves `.well-known/openwop-registry.json`.

## How does BYOK work?

A client picks the provider for each run in `RunOptions.configurable.ai`: a `provider`, a `model`, and a `credentialRef` naming a credential the host holds. The reference never carries key material ([Runs](https://openwop.dev/spec/v2/core/runs.html) §"Run options"). A node can also choose per call with `ctx.callAI({provider, ...})`.

The host resolves the secret. It never logs it and never echoes it in events or debug bundles ([secret-leakage threat model](https://github.com/openwop/openwop/blob/main/SECURITY/threat-model-secret-leakage.md)). The SR-1 invariant on [`/security/`](https://openwop.dev/security/) is the public test that this holds.

Hosts advertise their BYOK policy (`disabled`, `optional`, `required` or `restricted`) under `aiProviders`, so a client can check before it submits a run.

## Is OpenWOP suitable for non-AI workflows?

Yes. The AI surfaces (provider routing, model capabilities, agent memory, reasoning events) are optional capabilities. A host can meet the `openwop-core-standard` profile (runs, events, interrupts and the rest of the core) without exposing any AI provider. The vocabulary leans toward agents because that is the main use today, but the wire format doesn't require it.

## How do I get notified about security advisories?

Watch the [openwop/openwop repository on GitHub](https://github.com/openwop/openwop) for releases — that's the canonical channel. Every advisory is published as a tagged release with a `### Security` heading in CHANGELOG.md citing the advisory ID, the affected versions, and the migration path. Pre-disclosure embargo follows [`SECURITY.md`](https://openwop.dev/security/) §4 "Coordinated disclosure."

[CHANGELOG.md](https://github.com/openwop/openwop/blob/main/CHANGELOG.md) is in the repository. RSS feed and email notification aren't on the roadmap; the GitHub release watch is the supported subscription path.