Roadmap: hosted SaaS

The shipping product today is the self-hosted tool this site documents. If there’s demand for it, the plan is to grow that into a hosted, multi-tenant capability registry & router-as-a-service — same product, no infrastructure to run yourself.

The idea

One resident “router” skill is the only thing an agent loads. The platform’s MCP front door resolves any ask to the single best-matching capability (skill, MCP tool/server, subagent, or prompt template) — or an explicit no match — without loading every capability body into the agent’s context.

Ingestion works like the self-hosted collector seam: connect → scan → selectively persist with approval. The free tier is ingestion; the candidate paid tier is routing/serving plus governance, discovery, reversibility, residency, and seats.

Planned platform shape

The platform would be fully Cloudflare-hosted. Everything it serves runs on Cloudflare; the only thing that ever runs on a user’s machine is a thin collector, because no cloud runtime can crawl a local drive.

Workers + Durable Objects — the MCP front door (McpAgent, Streamable HTTP), auth, metering, and the dashboard/API.
D1 (SQLite + FTS5) — the registry of record; Vectorize holds the derived, rebuildable vector index; Workers AI does the embeddings (one model, one dimension, one canonical store — the vector index is derived, never authoritative).
Queues, KV, R2 — the ingest pipeline, device/rescan flags, and pack or large-body storage.
Per-machine collector — crawls, classifies, and redacts on-device, then pushes to the ingest endpoint; it is also the only place approved hydration plans ever execute.

This is the same shape as the self-hosted Cloudflare Worker deployment that ships today — the SaaS work is the multi-tenant layer on top, not a new architecture. Continuity is deliberate: the tool is TypeScript + SQLite locally, and Cloudflare D1 is SQLite.

Safety posture (familiar by design)

The hosted service would carry the self-hosted tool’s conservatism forward, hardened for multi-tenancy:

Dual-approval ingestion — cheap gates (dedup, byte caps, quotas) run before expensive gates (secret detection), and a trust gate for prompt-injection/poisoned capabilities is co-equal with secret detection and blocking at the promote stage. Fail-closed to pending review.
Redaction as the default — secret values are stripped on-device, before upload; the cloud side treats unredacted-looking payloads as a contract violation and rejects them.
Structural tenant isolation — per-tenant stores (a Durable Object or D1 database per tenant, a Vectorize namespace per tenant, per-tenant R2/KV prefixes), with the tenant always derived server-side from the validated token. Leaking across tenants requires a routing bug, not a missing WHERE clause.
Approval is a human action by construction — dangerous scopes (approving hydration, reading sensitive bodies) are never carried by long-lived tokens; they require a fresh interactive step-up.
Untrusted content stays data — served capability bodies are wrapped as data-not-instructions, and cross-tenant sharing requires a higher trust tier.

What’s left to build

The Cloudflare Worker deployment already covers the single-tenant core: collector → ingest → D1/Vectorize registry → MCP front door. What the hosted service adds on top:

OAuth 2.1 identity and account management
Per-tenant isolation (stores, namespaces, prefixes)
Quotas and metering
The dual-approval ingestion pipeline
Cross-tenant sharing with trust tiers

If a hosted registry is something you’d use, feedback and interest on GitHub genuinely shape whether and when this gets built.