Skip to main content
gavAI has four surfaces: a web Builder where you compose pages, a public REST API that everything talks to, a per-tenant runtime that serves your published app, and the end-user subdomain your visitors land on. By the end of this page you will have a picture of what each surface owns, how they connect, and where data lives — enough to integrate gavAI from the outside or reason about an issue that crosses layers.

​
The four surfaces, end to end

A change to your app travels through all four surfaces between the moment you drag a block and the moment a visitor sees the page. The shape: Each box is one surface. They are wired in one direction (Builder writes through the API; the API writes through to the runtime; the runtime serves visitors), but every surface talks to the same REST API — the Builder is just one client of it.

​
Walk through a request

​
Where data lives

Every surface owns specific data. Knowing which store holds what makes it easier to reason about backups, exports, and what a breach in any one store would expose.

​
Where AI fits

The same operations the Builder UI performs are exposed to AI hosts over MCP. The MCP server (gavai mcp via the CLI, or @gavai/mcp-server as an npm package) connects Claude Desktop, Cursor, and other MCP hosts to the public API. An AI connected over MCP can read your page document, compute a patch, and publish the result — same artifacts, same endpoints, different driver. In addition to the read-and-patch flow, the runtime exposes a separate authenticated agent surface. This is a long-lived session a remote agent — yours or one of the platform-provided automations — holds open to read context, dispatch capability calls, and observe results without re-authenticating on every request. The agent surface is rate-limited per session, replayable (so an agent that gets disconnected mid-run can resume from the last acknowledged event), and audited end-to-end so a workspace owner can review what an agent did after the fact.

​
Audit and replay

Every state-changing operation across the four surfaces — a page patch in the Builder, a publish through the API, a capability dispatch in the runtime, a domain attach — emits an audit record. The records form a hash-linked chain so tampering with a single entry breaks verification of every entry after it. Reads: Most users will never read the audit log directly — the console surfaces a filtered view per resource. Programmatic access is through the Logs API, which exposes the same records alongside runtime traces.