Future Exploration: Ecosystem & Interoperability

Document ID: FUT-005 File Path: docs/18-roadmap/future/B5-ecosystem-interop.md Version: 1.2.0 Status: Exploratory — research bet, not committed (narrowed 2026-07-15: the inbound MCP-connection slice graduated out to PRD-006, see scope note below) Owner: Ecosystem Team Last Updated: 2026-07-15

1. Purpose

Flesh out the “Ecosystem & Interop” research bet (future.md §2.5, PRD-002 §6.5): an MCP gateway and broader protocol interop, prompt/model registries, and federated cross-organization plugin/memory sharing — riding existing abstractions, with federation fail-closed across trust boundaries.

Exploratory — graduates only via an ADR.

Scope note. Marketplace monetization and abuse handling are Tier A (near-term GA completion, PRD-002 §5.4), not part of this exploratory doc. This doc covers the interop and federation frontier only.

Scope note (2026-07-15). The inbound half of “MCP gateway” below — Wovyr consuming external MCP servers, made usable without writing code — is no longer exploratory: it graduated to a committed, scoped milestone, PRD-006 / v1.3 roadmap. What remains exploratory here is narrower than before: the outbound direction (Wovyr’s own tools/agents reachable over MCP by external clients) and cross-org federation. Read “MCP gateway” below as that narrower remainder, not the inbound connection-management PRD-006 already covers.

2. Problem & Opportunity

The platform is provider- and tool-neutral internally (the AIProvider trait, the ToolRegistry) but does not yet interoperate outward with the broader agent/tool ecosystem, nor federate across organizations:

MCP gateway / protocol interop — speak the Model Context Protocol (and peers) so external tools/agents interoperate with Wovyr. Also covers gRPC, named as a supported protocol in the Day-1 architecture docs (docs/01-product/prd.md, docs/02-architecture/c4-container.md) but never built — the shipping API is REST/JSON + SSE only. If a client segment genuinely needs gRPC (e.g. high-throughput internal service callers), it’s a protocol adapter at this same interop boundary, not a rewrite of the REST surface.
Prompt/model registries — versioned, shareable prompt and model catalogues.
Federated sharing — cross-organization plugin and memory sharing.

3. Current Baseline (what this would build on)

Vendor-neutral provider abstraction — the AIProvider trait (chat + streaming + embeddings) and the Gateway already decouple the platform from any one provider; an MCP gateway is another adapter at that boundary.
Tool registry + MCP-shaped tools — wovyr-tools’ ToolRegistry and the plugin tool host already model external capabilities as tools.
Marketplace supply chain — signing, SBOM/provenance, trust store, and the human-review workflow (wovyr-plugin / wovyr-marketplace) are the trust substrate any federation must extend, not bypass.
Hard tenant/org isolation — wovyr-tenancy’s default-deny RBAC/ABAC and the server’s cross-tenant isolation are the boundary federation must cross explicitly and revocably.

4. Direction (design sketch, non-committal)

MCP gateway: an adapter that exposes Wovyr tools/agents over MCP and consumes external MCP servers as tools — built at the existing provider/tool boundary, so the core is unaware of the wire protocol.
Registries: prompt/model registries modeled like the plugin marketplace (versioned, signed artifacts) rather than a new bespoke store.
Federation: cross-org sharing as an explicit, scoped, revocable grant between orgs — never a default, never implicit. Reuses the marketplace trust substrate for provenance across the boundary.

5. Requirements

5.1 Functional

Wovyr tools/agents are reachable over MCP; external MCP tools are usable inside Wovyr runs.
Cross-org sharing requires an explicit grant and is fully revocable.
Shared artifacts carry provenance across the boundary (signed, verifiable).

5.2 Invariants to preserve

Federation is fail-closed. Cross-org access defaults to denied; sharing is opt-in, scoped, and auditable — the isolation model is not relaxed for convenience.
Interop rides existing abstractions — no protocol leaks into the deterministic core; adapters live at the edge.
Supply-chain trust holds across federation (no unsigned/unverified artifacts crossing an org boundary).

6. Key Risks & Open Questions

Federation as a cross-tenant leak vector — the central risk; a sharing path that under-scopes becomes a data-exfiltration channel.
Protocol churn — MCP and peers are evolving; the adapter must absorb change.
Trust transitivity — does trusting org A’s plugin imply trusting its dependencies/publishers? Needs an explicit model.
Revocation semantics — what happens to in-flight/derived state when a share is revoked?

7. Graduation Gate

Per-slice; federation specifically becomes an ADR + roadmap slot only with:

A threat model + ADR for the cross-org trust boundary demonstrating fail-closed, scoped, revocable sharing with provenance preserved — before any cross-org path ships. (The MCP-gateway slice can graduate independently on an adapter design that keeps the protocol out of the core.)

8. Dependencies

Tier A marketplace economics/safety (PRD-002 §5.4) — a healthy first-party ecosystem should precede federation.
The existing supply-chain trust model (wovyr-plugin / wovyr-marketplace, ADR-0009).

10. Revision History

Version	Date	Description
1.2.0	2026-07-15	Narrowed scope: the inbound MCP-connection-management slice (consuming external MCP servers, made usable without code) graduated to a committed milestone — PRD-006 / v1.3 roadmap. This doc now covers only the outbound gateway + federation remainder
1.1.0	2026-07-07	Added gRPC explicitly under the MCP/protocol-interop direction — named in the Day-1 architecture docs but never built; this is now where that gap is tracked. Found during a project-wide doc review
1.0.0	2026-07-05	Initial exploration doc for the ecosystem/interop research bet