# Overview — build static AI apps around Spaces Witbitz is a trusted runtime for collaborative AI applications. You build the app as a static website; Witbitz provides the shared room, identity, permissions, agents, storage, payments, and execution underneath it. The important primitive is a **Space**: a persistent room where people, an application, and one or more AI agents work together under explicit permissions. A Space can be a product by itself, or it can sit inside another app as the place where users ask, approve, and inspect what the app does. > Start here if you are new. For the complete architecture argument, see [the platform](./platform.md). For the current > shipped/preview/designed map, see [status](./status.md). --- ## The short version Your app does not need its own private backend for the collaborative surface. It can be a static page that talks only to Witbitz: 1. The page creates or opens a Space. 2. Members join by link, sign-in, invite, or owner policy. 3. The Space stores conversation, documents, artifacts, and shared widget state. 4. An AI agent runs when a member posts a turn. 5. High-stakes tool calls become proposals; an authorized human approves before anything executes. 6. The data footprint is declared and checkable: sealed storage, locked egress, signed build metadata, and a reproducible render. That is the trade: replace many app-specific backends with one constrained runtime whose behavior can be inspected.
Static appLoads in the browser with a locked egress footprint.
SpaceHolds members, admission policy, sealed config, and shared state.
Agent turnRuns only when a member acts, then re-seals and goes cold.
EvidenceDocs, OpenAPI, CSP, build certificate, and raw sealed bytes stay inspectable.
## What a Space gives you | Primitive | What it means | |---|---| | **Room identity** | A Space carries its own identity, members, keys, and admission policy. | | **Shared state** | Everyone sees the same thread and the same live widget state. | | **Agent turns** | The AI is invoked as part of the room, not as an external chatbot bolted onto the side. | | **Tools and widgets** | App functions become tools; tool results can render as maps, charts, files, or custom widgets. | | **Delegated authority** | The agent can propose an effectful action, but the runtime requires human approval before execution. | | **Content-blind storage** | The store holds ciphertext sealed to the room, not to the platform operator. | | **Verifiable footprint** | The app is static and egress-locked, so the hosts it can reach are visible and enforced. | ## The first app: Spaces The first product built on the runtime is **Witbitz Spaces**: a multiplayer ChatGPT-style room where several people and an AI collaborate over time. It can read shared documents, search, build maps, render charts, generate artifacts, and keep the room alive between visits. Spaces matters because it is not a special internal product. It is the reference app for the platform surface: collections, artifacts, agent tools, widgets, identity, and the content-blind render. ## The two guarantees Witbitz docs are organized around two guarantees: 1. **Humans keep authority.** Agents do not own credentials. They propose; people approve; the runtime executes only approved actions. 2. **Privacy is verifiable.** The app has no private backend of its own, storage is sealed to a key we never hold, egress is locked, and the render's deployed build can be checked against published source. The second guarantee has important status boundaries. The production tier is content-blind at rest, with plaintext opening briefly in the server-side render while a member is active. The attested server tier — a Space whose turns run inside a measured Nitro enclave, with your key sealed to that image — is now **in production**; it launches on demand and scales to zero when idle. Enabling it is the app builder's per-room choice — the platform can run any room in the enclave — and the model call leaves the measured image only through an attested no-log gateway into confidential-compute inference on an open-weights model — the frontier-vendor residual applies only to rooms that choose the frontier trade. Those distinctions are deliberate and should stay visible in every security conversation. ## The three layers | Layer | Role | |---|---| | **Interaction** | How people and AI meet: async Spaces today, live calls through the real-time engine, and future modes. | | **Platform** | The runtime services: identity, permissions, agents, sealed storage, payments, secure execution, API. | | **App** | A static page with no backend of its own, connecting only to Witbitz. | The app is not "backendless" in the absolute sense. Witbitz is the backend. The point is that the backend is shared, constrained, and inspectable instead of being an opaque server unique to every app. ## Where to go next - Build something: [Platform API](./api-reference.md) - Understand Spaces: [Async Spaces](./async-spaces.md) - Check the claims: [Verify it yourself](./verify.md) - Review the privacy boundary: [The double blind](./trust-model.md#the-double-blind) - Compare privacy tiers: [Privacy tiers](./privacy-tiers.md) - Understand admission: [The Verified Room](./identity-and-admission.md) - Run it yourself: [Enterprise and on-prem](./deployment-options.md#your-boundary)