What a template is

A template is a vetted spec — a tree of catalog components bound to a set of declared queries— shipped by Amdahl as a ready-to-adapt starting point. Templates live in code, not as Pages in your workspace: the same gallery shows for every tenant, and a template only becomes a real Page when someone authors one from it. It’s the same model as blueprint starters — read from code, never seeded into your data.

Eight templates ship today, across all three page layouts:

• Dashboards — Pipeline Health (open pipeline by stage + most-engaged accounts), Voice of Customer (what customers say, clustered into themes), and Competitive Battlecard (where a competitor shows up in your deals). Pipeline Health and Competitive Battlecard now open with a Markdown intro, mixing prose and live data on one page.
• Single-visualization — Win Rate (a gauge), Pipeline Funnel (a funnel of accounts by stage), and Deal Size Distribution (a treemap). One chart, presented full-bleed.
• Documents — Competitive Brief (a written battlecard: mostly Markdown with one live competitive-mention stat) and Account One-Pager (a pure-markdown account brief, no queries at all). Long-form report pages presented as a readable prose column.

The “New page” gallery

In the console, New page opens a dialog with the template gallery. Each card offers two paths, plus a blank-page escape hatch:

• Build with AI — the headline path. Hands the template to your LLM of choice (Claude, ChatGPT, Perplexity) with a recipe to adapt it to your real data and author the Page. Covered below.
• Use template— opens the page editor pre-filled with the template’s spec + queries for hands-on editing.
• Blank page — start from an empty spec and build it up in the editor.

Build with AI

A template’s declared queries are tenant-agnostic starting points; the table and column names won’t match every workspace verbatim. Build with AI closes that gap. It opens your LLM seeded with a prompt that, when the Amdahl MCP server is connected, tells the model to:

1. Fetch the canonical template by reading the page_template://<slug> resource — the source of truth, not a snapshot.
2. Inspect your real data with the data tool (explore / query) and rewrite the declared queries to match what this workspace actually has.
3. Keep the catalog spec structure, then validate the adapted spec via the pages tool and fix whatever the verdict flags.
4. create the Page once it validates.

If MCP isn’t connected, the same prompt falls back to a paste flow, and “Use template” always opens the template directly in the editor — so the no-MCP path is never a dead end.

Reading templates over the API + MCP

Templates are reads, so they surface as resources (over MCP) and as REST endpoints, scoped by pages:read. The list is lean (slug, name, intent); the detail read carries the full spec + declared queries.

# REST
GET /api/platform/v1/pages/templates
GET /api/platform/v1/pages/templates/:slug

# MCP resources
page_template://list
page_template://<slug>

Each template also has a stable, deterministic UUID derived from its slug, so a caller can address one by either shape. Because templates are code-defined, these reads return the same result for every workspace.

How Amdahl ships templates

Templates are authored by Amdahl as code — each one a validated spec + declared queries that must pass the same verifier a human or agent hits. New templates appear in the gallery (and on page_template://list) automatically; there’s no per-tenant install step. To customize one for your workspace, author a Page from it and edit the result — your Page is yours, fully decoupled from the template it started from.