Pages
A Page is a designed, interactive view that lives in your workspace, weaving narrative, layout, and your own live data together.
A Page is a designed, interactive view that lives in your workspace, narrative, layout, and your own live data, woven together. A person or an agent authors it once; everyone with access opens it from the sidebar like any other section.
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
Customnode is fenced behindpages:adminand 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 Pages section 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.
Author
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 Custom node'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.
Store
A Page that passes is written to the pages table, alongside the named queries it declared.
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.
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.
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 Custom node 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
pagestool.