We hold ourselves to a real verdict, not a launch slogan. The mesh comm-layer is production-grade, and svamp now runs on it end-to-end — auth, sessions, agent output, durable cron and the LLM proxy, all verified live on Cloudflare. The verdict is GO for svamp-over-mesh, with a flagged/parallel rollout recommended for the first cutover window. Below: our genuine strengths, and the limitations we will not paper over.
Read the full assessmentThe hard, risky part — the distributed comm-layer — is done, tested on real Cloudflare with no mocks, and survived three rounds of independent adversarial review and live attack probing.
Passcode (dev) or HS256 agent-JWT only — typed scope, explicit workspace claim, required expiry, signature, and cross-workspace isolation enforced before any object is touched. Nine token-forgery classes rejected live.
A service is live iff its host connection is open — derived from the object lifecycle, never self-reported. Reconnect replays missed deltas gap-free; a stopped daemon shows no phantom-online.
Register / discover / call, ordered server→client streams with backpressure, R2-backed artifacts, and cross-workspace federation — each with real end-to-end tests.
Server-side cron survives daemon downtime: schedules sync into a per-workspace object that arms an alarm and journals due runs — proven live on prod, including an alarm firing with no daemon attached.
The full app runs on the mesh: sessions, messages, live agent output, file serving, channels — and an authenticated multi-tenant admin dashboard that auto-discovers every workspace.
An Anthropic-compatible serverless proxy with mesh-auth, per-user quota/rate-limit, multi-account OAuth rotation and automatic token refresh — serving the mesh daemons directly.
What we are deliberately not, and the honest caveats an operator should plan around — none of them new distributed-systems risk.
The mesh is a new, deliberately-minimal protocol (client→server unary + server→client streams). It does not speak hypha-rpc on the wire — long-lived bidirectional callbacks, _rintf object proxies and generators are non-goals. Other apps migrate via a documented porting guide, not a drop-in shim.
svamp-over-mesh is GO, but the first production cut should run flagged / parallel with the previous stack as fallback — not an instant hard switch.
The DoS guard is in-memory per worker isolate (by design): it caps a single-isolate burst, but a geo-distributed flood gets a looser aggregate ceiling. Sized for the self-DoS threat model.
Mostly yes — for the intended shape (one workspace per tenant, mostly-idle objects, sharded load). With three honest caveats.
One workspace ≈ 200+ concurrent sockets and ~980 calls/s. Scale lives in the number of workspaces — never a single global mega-workspace.
"Scale to zero" assumes objects idle. A daemon connected 24/7 keeps its object warm — budget one resident object per active daemon, not zero.
Per-request subrequest caps and account-level rates — not the object count — are what to monitor. Operational ceilings, not architectural walls.
Verdict and evidence from docs/PRODUCTION-READINESS.md (incl. the §7–§9 adversarial-review addenda) and the benchmark. Test counts from the server/ suite on real workerd.
See the benchmarks