No. Not yet, and not anywhere — including here. WebHost.Systems is the runtime layer of ComputeDriven, and it has no runtime. What exists is a control plane: a database schema, 6 edge functions and a dashboard, all of which record that a deployment happened without one having happened. This page lists what is in the tree, what is not built, and the file and line number that settles each row.
Until 2026-08-16 this page sold a multi-runtime agent deployment platform over a control plane labelled with the name of a database this repository has never depended on. The claims were not softened or moved to a later quarter. They were removed, and they are quoted here so that removing them is checkable rather than a promise — the publication gate counts every one of these strings on the emitted page and refuses the build if a single occurrence appears outside this block.
The 8 strings below were on this page. The publication gate counts each one on the emitted artifact and refuses the build if any occurrence appears outside this paragraph — or inside a comment or an attribute, where a reader cannot see it and a search engine can. That is what makes this a retraction rather than an intention.
multi-runtime AI agent deployment platform— The meta description and the hero subtitle. Neither runtime was wired to anything.
deploy to Cloudflare Workers or AWS Bedrock AgentCore— The hero's second sentence. The deploy function writes a row and stops.
AgentCore for enterprise— Said twice, in the stack diagram and in the plane description.
from ampersand.json to production— Nothing in this repository or its edge functions reads an ampersand.json.
All systems operational— A footer badge with no status source behind it. It was a decoration shaped like an instrument.
Launch Dashboard— Pointed at app.webhost.systems, whose backend project had already stopped resolving.
Open Dashboard— The same target, in the hero.
Launch App— The same target, in the nav.
Two of them are worth naming again. The control-plane box was labelled Convex, and this repository has never depended on Convex — the only trace of it in any manifest is an extraneous lock-file record for a workspace that is not on disk — while the plane it labelled runs on Postgres. And the footer carried a live-looking status badge with no status source behind it at all: a decoration shaped like an instrument, which is the same defect as a number read out of an animation, and this page now carries a rule against both.
What replaced them is smaller and checkable. The claims that remain each cite a file and a line, the build re-opens every one of those files and refuses to emit the page if a cited line has stopped saying what it is quoted as saying, and the rung this surface holds is ? rather than a flattering guess.
A single status for this domain would be a lie in one direction or the other. Some of this is code with a test suite and no deployment; some of it is a set of documents, part of which is superseded. None of it is a running system, so the chip on each card says which kind of thing it is.
A webhost.* Postgres schema with row-level security, RPCs and cron, plus 6 edge functions: deploy, activate-deployment, invoke, delegated-invoke, telemetry and billing-webhook. Deployments are rows with a per-agent unique version, and rollback moves an active-deployment pointer rather than editing history.
Vite, React and TypeScript against a Supabase client. Agents, deployments, invocation and telemetry views, with the runtime provider chosen from a select element.
10 documents: the master spec, API contracts, the runtime provider interface, the data model, security, observability and billing, the testing plan, the [&] Protocol integration, an index and a realignment plan. Written to be implementation-ready.
Agents, deployments with a per-agent unique version, an active-deployment pointer that rollback moves rather than editing history, signed telemetry ingestion, usage aggregation and plan limits. Clients hold read access only; every write goes through a service-role function.
Nothing occupies this half. The deploy path stops at the version row and marks the provider reference with a marker meaning it did not happen; the invocation endpoint answers from a model provider, which is a different product from a deployed agent. What eventually fills this is an open question, not a shipped choice.
Each card names what is missing, what it would take, and how far along it is. The word simulated is not a euphemism here — it is the literal string the deploy function writes into the provider reference when it finishes, and the line that writes it is in the table below.
The deploy function inserts a deployment row and returns. Its own source says so on the line this page cites, and it writes a simulated marker into the provider reference. Nothing is handed to Cloudflare Workers, and there is no AWS or Bedrock dependency anywhere in the tree.
It is a string. It appears as a member of a TypeScript union, as the value of an option element in the dashboard, and as a member of a Postgres enum. That is the whole of it.
Capability manifests, MCP sidecars, agent-to-agent routing and governance enforcement are written down in the integration spec and implemented nowhere. No code in this repository or in its edge functions reads an ampersand.json.
The workspace declares packages/* and there is no packages directory on disk. This build recomputes that on every run, so the day one appears the page can no longer say this.
Everything above stands on the shared Supabase instance, and that route was abandoned by ruling on 2026-07-30 in favour of studbook. Studbook is a draft spec with no implementation, blocked on one unruled question about where confidentiality comes from. Nothing migrates until it can hold the same data with the same guarantees.
These are file probes, not prose. The build opens each file, checks that the cited line still says what this page says it says, and refuses to emit the page on any disagreement — so if somebody adds an AWS dependency or wires the deploy call up, this page stops building rather than going quietly out of date. The negative claims are the ones worth mechanising: a page can keep saying “there is none of this” only for as long as a build can prove it.
| What is being claimed | Where it is settled | What is there |
|---|---|---|
| Nothing is shipped to a runtime | ampersand-supabase/functions/webhost-deploy/index.ts:94 | // TODO: Actual Cloudflare Workers API call goes here. |
| The deploy writes a marker instead | ampersand-supabase/functions/webhost-deploy/index.ts:107 | : { simulated: true }), |
| invoke/v1 answers from a model provider | ampersand-supabase/functions/webhost-invoke/index.ts:11 | import { invokeOpenRouter, invokeOpenRouterStream } from "../_shared/openrouter.ts"; |
| AgentCore is an enum member | ampersand-supabase/migrations/020_webhost_schema.sql:16 | create type webhost.runtime_provider as enum ('cloudflare', 'agentcore'); |
| ...and an option in a select element | apps/web/src/components/AgentsPage/AgentsListPanel.tsx:209 | <option value="agentcore">agentcore</option> |
| The workspace declares packages/* and there is none | packages/ | no such directory |
| Nothing reads an ampersand.json | apps/ and the webhost edge functions | 0 source files mention it |
| No AWS or Bedrock package anywhere | 2 package.json files, node_modules excluded | 0 dependencies match /aws|bedrock|agentcore/ |
| No Convex dependency in any manifest | 2 package.json files, node_modules excluded | 0 dependencies match /convex/ |
| webhost edge functions | ampersand-supabase/functions/ | webhost-activate-deployment, webhost-billing-webhook, webhost-delegated-invoke, webhost-deploy, webhost-invoke, webhost-telemetry |
| webhost database migrations | ampersand-supabase/migrations/ | 020_webhost_schema.sql, 021_webhost_rls.sql, 022_webhost_cron.sql, 023_webhost_rpc.sql, 024_webhost_extra_tables.sql, 025_webhost_openrouter.sql |
| specification documents | docs/spec/ | 00_MASTER_SPEC.md, 10_API_CONTRACTS.md, 20_RUNTIME_PROVIDER_INTERFACE.md, 30_DATA_MODEL_SUPABASE.md, 40_SECURITY_SECRETS_COMPLIANCE.md, 50_OBSERVABILITY_BILLING_LIMITS.md, 60_TESTING_ACCEPTANCE.md, 70_AMPERSAND_PROTOCOL_INTEGRATION.md, README.md, REALIGNMENT_PLAN.md |
| tests passing | npm test — vitest, in this repository | 143 tests across 12 files, 0 failures |
Each row was produced by opening the named file during this build and searching it for the string the row is about — the line number is where it was found, and the third column is that line, trimmed. The absence rows are the same mechanism run backwards: every package.json in the repository is parsed and its dependency names searched, and a single match refuses the build. The test row is not quoted from anywhere: the build runs the repository's own test command, parses the summary it prints, and refuses if a single test fails or if the summary cannot be parsed. Frozen in records/evidence.json and compared on every run, so a value that moves has to be looked at by a person before it can be published.
There is no dashboard to open and nothing to launch. The rung a surface holds decides what it is allowed to ask a visitor for, and at these rungs the honest asks are to read the code, run its tests, read the specification and argue with it.
npm install && npm test. The count on this page is whatever that command printed when the page was last built; if your machine disagrees, that is worth telling us about.? for the first time. Nobody has written one, and that is the honest state of the runtime layer.This page is mostly a list of things we said and could not back. If you find another one — a claim above that does not hold, a file that no longer says what it is quoted as saying, an arithmetic error in the counts — that is the most useful thing anyone can send.
It posts to Formspree, which is a third party and the only one this page hands anything to; nothing is sent until you press the button. If you would rather not use it, open an issue instead — both reach the same person.