Roadmap

Status: Living document. Updated as milestones land.

This roadmap covers the current v2 major, the gated candidates for later v2 minors, and the ecosystem work around the protocol (infrastructure, SDKs, governance).

Current: v2 (released 2026-09-05)

v2.0.0 was tagged on 2026-09-05. Every v2 minor since is additive under COMPATIBILITY.md §2.4; removals inside the major follow §3a.

• Contract: the documents in spec/v2/core/, with optional extensions in spec/v2/ext/. Schemas are in schemas/v2/, and the HTTP and event APIs are api/v2/openapi.yaml and api/v2/asyncapi.yaml.
• Conformance: @openwop/openwop-conformance 2.x. openwop-core-standard is the floor listed in spec/v2/profiles.json.
• SDKs: @openwop/openwop (TypeScript), openwop-client (Python) and github.com/openwop/openwop-sdks/go/v2 (Go), at 2.x in openwop/openwop-sdks.
• Hosts: INTEROP-MATRIX.md lists each host's newest certified bundle.

See CHANGELOG.md for the release record and docs/PROTOCOL-STATUS.md for the live tally.

v1. v1 reached end of support on 2026-10-04 (RFC 0234). spec/v1/ and the v1 wire are a frozen tree, kept as history and no longer edited. A host may retire v1 from that date but is not required to.

Candidates (gated)

Each candidate ships only when its gate condition is met. The list is descriptive, not a commitment. A candidate is not an RFC and has no comment window running. The list is re-read at each corpus minor. A candidate with no adoption signal across two consecutive corpus minors is reviewed for withdrawal at the next one, and a maintainer removes any candidate whose gate no longer makes sense, noting the removal in the CHANGELOG.

Notes on the candidates:

• WASM Component Model. The manifest enum is reserved in node-pack-manifest.schema.json, and capabilities.schema.json declares nodePackRuntimes.wasmComponent. WIT-defined interfaces would replace the hand-rolled imports and exports of RFC 0008 §C. The loader needs Wasmtime ≥ 14 (Component Model GA).
• Rust SDK. The conformance suite is language-agnostic, so a Rust client tests against the same wire contract. It is demand-gated.
• Post-audit obligations. core.openwop.{ai,http,mcp,triggers} are already published on packs.openwop.dev (1.1.0, see docs/PACK-CATALOG.md). The steward published them before the external review completed, a decision recorded on 2026-05-17 in SECURITY/external-audit-engagement.md §2.1.1. The audit requirement still stands: when the review completes, its findings bind every pack published early, and the steward team still needs a namespace-scoped signing key.
• mTLS. openwop-auth-mtls is verified end-to-end when configured. What remains is operator documentation (CA, server and client certificates, reverse-proxy deployment) and broader certificate-matrix coverage.
• Multi-region idempotency. The rule is in the idempotency spec's multi-region annex. multi-region-idempotency.test.ts covers the capability shape only; the candidate adds behavior assertions for "best-effort" and "strict".
• Structured handoff context. Today agent.handoff carries fromAgentId, toAgentId and a free-text reason. RFC 0002 sketched an open context field that v2 does not carry. The candidate is an optional, typed handoff context with five parts: the intent, the decisions made (each with who decided), open questions, what was tried, and a confidence value. It would also cover agent-to-human escalation, where the same record would ride the clarification or approval interrupt. It is additive: a receiver that ignores it loses nothing it has today. openwop-app prototypes it first under the openwop- extension prefix the event schema already admits (see the app's ROADMAP, "Collaborative orchestration program").
• Shared intent record. A run can already be paused for a human decision, and the decision is attributed. Nothing on the wire says what the work is for: the current intent, the decisions that shaped it, and what changed. openwop-app is building a team intent ledger as a host extension, with drift detection and decision capture from chat on top. Only the record itself is a protocol candidate, and only if it needs to cross hosts: a stable reference a run can stamp ("acted on ledger version N") and a way for a host to read it. Drift detection and decision capture stay host behavior.

Ecosystem

These initiatives expand the openwop ecosystem without changing the wire contract.

Optional capability profiles

A capability profile is a cluster of optional behaviors a host advertises at /.well-known/openwop. Each profile has its own conformance scenarios in @openwop/openwop-conformance, which run only when the host advertises the profile. spec/v2/profiles.json lists the v2 profiles and their floors. docs/IMPLEMENT-CORE.md covers the openwop-core-standard floor, and docs/IMPLEMENTER-PATH.md walks a host from first build to a certified bundle.

Hosted infrastructure

• Registry. It serves the registry rules in spec/v2/core/packs.md. The pack inventory is docs/PACK-CATALOG.md. Publishing, yanking, deprecation and key rotation go through pull requests on GitHub. conformance/src/scenarios/registry-public.test.ts is its public healthcheck.
• Site. It renders this corpus at a pinned commit and tracks main through a daily pin bump.
• CI. The workflows are in .github/workflows/.

SDK expansion

Additional SDKs ship only when there is concrete demand. The current set (TS, Python, Go) covers the most common host implementation languages. Candidates if requested: Rust, Java/Kotlin, Ruby, .NET.

Implementation ecosystem

• Certification. INTEROP-MATRIX.md records each host's certified profiles and signed bundle. Every bundle is steward-cut (self).
• Independent host. GOVERNANCE.md requires a maintainer from a genuinely independent organization before the project moves to working-group governance. MyndHyve is a steward-affiliated sibling host (tier-2 evidence per GOVERNANCE.md §"Acceptance evidence tiers"), so it does not count.
• Independent certification. All three certified hosts today (the v2 reference host, openwop-app and MyndHyve) are run by or affiliated with the steward, and every bundle is evidence tier self. "Open by design" becomes demonstrated, not just claimed, when a host we do not run publishes a certified bundle it cut itself against a released suite and it appears in INTEROP-MATRIX.md. Until then, public writing should say the protocol is open to any host and that independent implementations are wanted. It should not say they exist.

Canonical Domain

Forward-looking domain references in the spec corpus and roadmap use openwop.dev.

Three rules for domain usage:

1. All forward-looking public URLs (packs.openwop.dev, openwop.dev/openwop-conformance, etc.) use openwop.dev.
2. Published package names stay verbatim (@openwop/openwop on npm, openwop-client on PyPI) and are guaranteed stable within a major per PUBLISHING.md. The SDK source lives in openwop/openwop-sdks, so the Go module path is github.com/openwop/openwop-sdks/go/v2 for v2 and github.com/openwop/openwop-sdks/go for v1, never the frozen pre-split github.com/openwop/openwop/sdk/go.
3. Internal references in steward-private docs are not normative and may use any name; this convention applies only to the public spec corpus, this ROADMAP, and the conformance suite.

Vendor-neutral org migration

The repository is at github.com/openwop/openwop. Migration to a vendor-neutral org (target name: openwop-spec/openwop) is planned but not on a calendar schedule. The migration has a single tripwire:

Migration to openwop-spec/openwop is initiated when MAINTAINERS.md lists at least one maintainer not affiliated with the original steward (OpenWOP).

When the tripwire fires, the migration plan is:

1. Open an RFC per RFCS/0001-rfc-process.md proposing the new org name and the mechanics (redirect, DNS, package owner transfer, CHANGELOG entry).
2. Ratify by maintainer lazy consensus (per GOVERNANCE.md).
3. Move the repository; configure github.com/openwop/openwop as a permanent redirect.
4. Transfer ownership of npm scopes and PyPI/Go module names; old names continue resolving via metadata redirects where the package registry supports it.
5. Update all in-spec links to the new canonical URL in the next minor release.

Until the tripwire fires, the canonical URL remains github.com/openwop/openwop. The migration will be announced in the CHANGELOG, the README banner, and directly to known third-party implementers.

Recruiting external maintainers is out of band. MAINTAINERS.md documents the criteria and process; this roadmap does not commit to a recruitment timeline.

Research & publications

• OpenWOP: A Vendor-Neutral Protocol for Durable, Portable Agentic Workflow Orchestration — published on Zenodo, DOI 10.5281/zenodo.20576239 (CC BY 4.0). A protocol-level position paper with a reproducible cross-language portability result: the same workflow definition yields identical terminal state and RunEvent type-sequence across an independent TypeScript and a Python reference host. Source and evidence are in openwop/openwop-paper.

- The paper is steward-authored and says so. Independent external review and a non-steward host remain the decisive validation steps.

What this roadmap does not commit to

• A specific date for any v2 minor or for v3.
• Any breaking change inside the v2 major.
• Adoption by any specific vendor or platform.
• Staying on any specific cloud. Forward-looking spec, registry and leaderboard URLs use openwop.dev, so the services behind them can move without changing a public URL.
• Migration of the repository to a different organization on a specific timeline (planned but not scheduled — gated on the tripwire described above and in MAINTAINERS.md).

How to influence the roadmap

• File an issue with the roadmap label. Include the use case, not just the feature request.
• Open a conformance report if your implementation needs a scenario that doesn't exist yet.
• Author an RFC for a new capability profile. Profile RFCs follow the spec change process in GOVERNANCE.md.