What a Page is

A Page is a spec— a tree of catalog components (sections, cards, headings, stats, tables, charts) bound to your workspace’s live data — that renders a designed UI: prose and headings next to charts, tables, and callouts. Think of it as a small, purpose-built view, “Q3 pipeline review” or “top accounts at risk”, that reads from the same normalized data Amdahl already has and presents it the way you want. When the catalog genuinely can’t express something, a Custom node is the admin-gated escape hatch into bespoke, sandbox-rendered code.

Pages are the successor to artifacts. Where an agent used to drop a block of markdown or JSON into the library, it can now author a real, interactive surface instead. Pages have their own store, the pages table, separate from the older platform_artifacts store, so the two evolve independently.

How a Page is different from an artifact

• It’s a composed view, not a stored document. An artifact is frozen content. A Page is a spec that renders, so it lays out data, and updates as your data changes.
• It’s a safe template by default. The catalog is a closed set of vetted components, so a catalog-only Page is safe to author without special privileges. The do-anything Custom node is fenced behind pages:admin and the sandbox.
• Data is live and per-viewer. A Page never bakes in a snapshot. It declares the queries it needs and the host runs them fresh for whoever is looking, scoped to what that person is allowed to see.
• It has a home in the workspace. Once stored, a Page is listed in the Pagessection of the workspace sidebar, so it’s a first-class part of the workspace rather than a file you go hunting for.

The end-to-end flow

Every Page travels the same path, whether a human editor or an agent creates it.

1. Author. A human composes the spec in the editor, or an agent emits it through the pages MCP tool. The fastest start is a template — an Amdahl-shipped spec you adapt with one click. Either way the spec follows a small contract, covered in Authoring.
2. Verify, validate, reject. Before anything is stored, the spec runs through a verification pipeline: it must be a valid spec of known catalog components, its data bindings must resolve to declared queries, and any Customnode’s code must pass the allowlist + forbidden-API checks (and the author must hold pages:admin). Anything that fails is rejected with the reason, so authors fix and resubmit rather than ship something broken. See Authoring for the full stage list.
3. Store. A Page that passes is written to the pages table, alongside the named queries it declared.
4. Appears in the Pages section.The Page is listed in the workspace’s Pages section in the sidebar, filtered by access, so only people allowed to open it see it listed. (The sidebar entry is the Pages section itself; you open it to find and launch a Page.) See Access.
5. Renders in a sandbox. Clicking the entry renders the spec. Catalog components render natively; any Custom node mounts inside a hardened, cross-origin sandbox iframe, isolated from the host console, so a Page can never reach your session, cookies, or the rest of the app.
6. Host feeds it data.The host, not the page, runs the page’s declared queries and resolves each $query / $value binding, scoped per viewer. The spec names the data by query; the host decides what that viewer is allowed to receive. See Data model.

Why the sandbox matters

Catalog components are vetted, so a catalog-only Page is safe by construction. The Customnode is the exception — bespoke code an agent may have written — so it runs in a cross-origin iframe with no access to the host’s origin. A Custom node cannot read your login, call arbitrary network endpoints, or touch the surrounding console. The only data any Page sees is what the host hands it, in response to the named queries it declared up front. That boundary, plus the pages:admin gate on Custom nodes, is what makes it safe to let agents build interactive surfaces you then open with one click.

Where to go next

• Templates— the Amdahl-shipped starting points behind “New page”, and the Build-with-AI handoff that adapts one to your data.
• Authoring — the component contract, the import allowlist, and what the verifier rejects.
• Data model — how a Page declares named queries and how the host runs them per viewer.
• Access — who sees which Page, and how page-level grants reuse your roles.
• Embedding — drop a live Page into an external site with a signed, audience-scoped iframe.
• Authoring via MCP — building a Page from an agent with the pages tool.