Agentic Pages
Agentic pages turn a published 10x page into a visitor-facing assistant surface. The page still has normal HTML content and CTAs, but it can also answer questions from public page context and approved handle knowledge.
This is the 10x integration pattern for teams that want a TryArchitect-like experience: train the page assistant on rules, knowledge, proof, and templates, then let visitors ask questions live. Architect describes this class of product as an agent trained on rules, knowledge, and templates that can adapt pages and answer visitor questions; 10x supports the public page, embedded assistant, and KB/RAG-backed Q&A parts of that pattern. 10x does not imply Architect's marketplace, leaderboard, or payout model.
Current capabilities
Agentic Pages now support:
- Public page Q&A from the page body, related published pages, and tagged public-agent KB.
- A streaming
agentic-chatroute for the embedded widget. - Bedrock primary/fallback generation for the streaming widget, with
openai.gpt-oss-20b-1:0as the default fallback model. - Inline chat mounts or a floating
Asklauncher from the same page shell asset. - Generated lead qualification UI rendered through native React plus a sandboxed form iframe.
- Native lead submission through
POST /v2/public/handles/{handle}/leadswith disclosed answer context. - Structured KB-driven rich cards such as
productivity_lesson_card, rendered by the widget through native tools likerenderProductivityLessonCards. - Non-leaky disabled-handle behavior and paid-page leak safety for anonymous visitors.
What you build
An agentic page has four parts:
- A published public page created through the 10x page APIs.
- An embedded assistant widget. Add an inline mount when the chat should be part of the page body, or omit the mount to use the floating launcher.
- Public page context. The assistant reads the visible public page content. For paid pages, it reads only the public teaser.
- Handle knowledge documents tagged for public-agent retrieval with
containerTags: ["public-page-agent"]. - A generated lead qualification section. The section is streamed as AI SDK UI message parts, rendered inside a sandboxed iframe, and submitted through the native public lead endpoint.
Anonymous visitor routes:
POST /v2/public/pages/{handle}/{pageSlug}/agentic-question
POST /v2/public/pages/{handle}/{pageSlug}/agentic-chat
Use agentic-question for the legacy JSON answer contract. Use agentic-chat for the embedded generative UI widget. Page and knowledge management still use authenticated handle APIs.
When the primary streaming model fails, agentic-chat retries once with the configured fallback model. If all configured models fail, the widget receives a non-leaky SSE chat_unavailable event and the environment emits CloudWatch metrics from public_page_agent_chat_primary_failed or public_page_agent_chat_failed log events.
Prerequisites
- A 10x handle with page publishing access.
- A creator/operator JWT for setup calls. The JWT is used to create pages and seed KB documents; public visitors do not need a JWT.
- Public-agent availability enabled for the handle by your 10x environment or operator.
- Public knowledge prepared as short, approved documents. Do not include secrets, private paid content, customer PII, or internal-only runbooks.
Set local variables:
export API_BASE="https://ai.10x.in"
export HANDLE="acme"
export PAGE_SLUG="launch-agent"
export JWT_TOKEN="<jwt-token>"
Public URLs follow the handle host:
https://{handle}.10x.in/{pageSlug}
Stage and custom-domain deployments use the same path shape, for example:
https://{handle}.arjun.tv/{pageSlug}
https://pages.example.com/{pageSlug}
Setup model: JWT first, anonymous runtime second
Agentic Pages use two different access models:
| Phase | Auth | What it can do |
|---|---|---|
| Setup | Creator/operator JWT | Create or update the page, publish the page, and upload public-agent KB documents. |
| Runtime | No visitor auth | Load the published page shell, stream public Q&A, render generated UI, and submit native public leads. |
Do not put the streaming visitor route behind JWT. The browser widget runs for anonymous visitors and calls same-origin public routes. JWT is still required for the setup APIs because those mutate handle-owned content.
Operator enablement is separate from JWT setup. A handle must be enabled by either the environment-wide public-agent switch, an explicit public-agent allowlist entry, or the tenant entitlement used by the target environment. If the handle is not enabled, anonymous routes return a non-leaky 404.
API reference summary
Setup routes:
POST /v2/handles/{handle}/pages
PUT /v2/handles/{handle}/pages/{pageSlug}
POST /v2/handles/{handle}/pages/{pageSlug}/publish
POST /v2/handles/{handle}/knowledge/documents
POST /v2/handles/{handle}/knowledge/query
Anonymous visitor route:
POST /v2/public/pages/{handle}/{pageSlug}/agentic-question
POST /v2/public/pages/{handle}/{pageSlug}/agentic-chat
Agent-assisted group-buy routes:
GET /v2/public/handles/{handle}/agent-skill.md
PUT /v2/public/group-buys/{handle}/{groupBuySlug}/my-instructions
GET /v2/public/group-buys/{handle}/{groupBuySlug}/coordination
1. Create the public page
Use the page API to create the base page. Include the inline mount when you want the chat box to appear inside the page content.
curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/pages" \
-H "authorization: Bearer ${JWT_TOKEN}" \
-H "content-type: application/json" \
-d '{
"pageSlug": "'"${PAGE_SLUG}"'",
"title": "Launch Agent",
"description": "A public page with agentic Q&A.",
"template": "html_render",
"accessMode": "PUBLIC",
"status": "DRAFT",
"content": "<main><h1>Launch Agent</h1><p>This page includes onboarding checklists, launch templates, implementation support, pricing guidance, and proof points.</p><div id=\"tenx-public-page-agent-inline\"></div></main>"
}'
The content value for template: "html_render" is an HTML fragment inserted into the standard 10x page shell. Send the page body, not a full document. In practice, use <main>, <section>, <article>, headings, lists, tables, forms, and inline links. Do not include duplicate <html>, <head>, or <body> tags.
Publish it:
curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/pages/${PAGE_SLUG}/publish" \
-H "authorization: Bearer ${JWT_TOKEN}"
To update later, use:
curl -sS -X PUT "${API_BASE}/v2/handles/${HANDLE}/pages/${PAGE_SLUG}" \
-H "authorization: Bearer ${JWT_TOKEN}" \
-H "content-type: application/json" \
-d '{
"title": "Launch Agent",
"description": "Updated agentic page.",
"template": "html_render",
"accessMode": "PUBLIC",
"status": "PUBLISHED",
"content": "<main><h1>Launch Agent</h1><p>Updated public content.</p><div id=\"tenx-public-page-agent-inline\"></div></main>"
}'
2. Choose inline or floating chat
Inline chat:
<div id="tenx-public-page-agent-inline"></div>
Alternative inline selector:
<div data-tenx-public-page-agent-inline></div>
When either mount exists, the widget renders as the page's chat surface and hides the floating launcher. When no inline mount exists, the same assistant loads as a floating Ask launcher.
You do not need to manually add the widget script for normal 10x-rendered public pages. Eligible pages receive the public-agent config and script from the page shell.
Public page agent widget customization
Agentic pages can customize the public assistant without changing the anonymous chat or lead endpoints.
Configuration resolves in this order:
built-in variant defaults -> handle defaults -> page overrides -> embed safe overrides
Built-in variants:
minimalcoachsalescoursesupport
Authenticated owners can configure safe theme tokens, copy, starter chips, behavior flags, and four rich slots:
headeremptyStateleadIntrosuccess
Rich slot HTML is sanitized and rendered inside the widget Shadow DOM. Generated lead form HTML remains sandboxed in the lead iframe and submits through the native public lead endpoint.
Public embeds can use simple safe overrides:
<div
id="tenx-public-page-agent-inline"
data-tenx-agent-variant="course"
data-tenx-agent-accent-color="#0b6b3a"
data-tenx-agent-launcher-label="Ask the guide"
data-tenx-agent-default-open="true"></div>
Public embeds cannot provide rich HTML, custom CSS, endpoint paths, sandbox flags, model settings, or prompt settings.
3. Build rich HTML page content
Rich HTML is the best way to make the page itself useful before the visitor asks a question. The assistant reads visible page content, so structure the HTML as public context, not only as decoration.
Recommended page structure:
<main class="agentic-page">
<section class="hero">
<p class="eyebrow">Implementation support</p>
<h1>Launch Agent</h1>
<p>
Get onboarding checklists, launch templates, implementation support,
pricing guidance, and proof points in one public assistant.
</p>
<a href="#agent" class="primary-cta">Ask a launch question</a>
</section>
<section aria-labelledby="proof-title">
<h2 id="proof-title">What the assistant can answer</h2>
<ul>
<li>What is included in launch support.</li>
<li>Which proof points are public and approved.</li>
<li>What information the team needs for a useful follow-up.</li>
</ul>
</section>
<section aria-labelledby="agent-title" id="agent">
<h2 id="agent-title">Ask the launch guide</h2>
<div id="tenx-public-page-agent-inline"></div>
</section>
</main>
Guidelines:
- Put the inline mount near the workflow where the visitor naturally asks a question.
- Keep public facts in visible text, not only in images. The assistant retrieves text more reliably than visual copy.
- Use public links only. Do not embed private dashboards, signed URLs, customer data, or credentials.
- Keep critical claims mirrored in KB documents when they should be reusable across pages.
- Treat page HTML as creator-authored public content. Do not place untrusted visitor-generated HTML into the page body.
- For paid pages, put only teaser-safe content in
teaser; anonymous agent answers must not use the paid body.
For richer styling, prefer classes and semantic containers inside the fragment. The 10x page shell supplies the outer document, meta tags, default typography, and the public-agent script injection when the handle is eligible.
4. Add public-agent knowledge
Create short knowledge documents that the public assistant is allowed to use. The public agent only queries documents with this container tag:
["public-page-agent"]
Example:
curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/knowledge/documents" \
-H "authorization: Bearer ${JWT_TOKEN}" \
-H "content-type: application/json" \
-d '{
"title": "Launch support policy",
"topic": "agentic-pages",
"source": "public-agent-setup",
"contentType": "text/plain",
"containerTags": ["public-page-agent"],
"content": "Launch support includes onboarding checklists, launch templates, implementation support, and a two-business-day handoff window."
}'
Validate retrieval before exposing the page:
curl -sS -X POST "${API_BASE}/v2/handles/${HANDLE}/knowledge/query" \
-H "authorization: Bearer ${JWT_TOKEN}" \
-H "content-type: application/json" \
-d '{
"query": "What launch support is included?",
"limit": 4,
"containerTags": ["public-page-agent"]
}'
5. Ask the public page
Call the anonymous visitor route:
curl -sS -X POST "${API_BASE}/v2/public/pages/${HANDLE}/${PAGE_SLUG}/agentic-question" \
-H "content-type: application/json" \
-d '{
"question": "What launch support is included?"
}'
Expected response shape:
{
"answerMarkdown": "Based on the public information available...",
"evidenceCards": [
{
"title": "Launch Agent",
"snippet": "This page includes onboarding checklists...",
"sourceType": "page",
"sourceUrl": "https://acme.10x.in/launch-agent"
},
{
"title": "Launch support policy",
"snippet": "Launch support includes onboarding checklists...",
"sourceType": "kb_doc",
"sourceUrl": null
}
],
"ctaCards": [
{
"label": "Open page",
"actionType": "link",
"href": "https://acme.10x.in/launch-agent"
}
],
"followUps": [
"What is included?",
"How do I get started?",
"What happens next?"
],
"degraded": false,
"retrievalMode": "page+related_pages+vector",
"modelId": "anthropic.claude-haiku-4-5-20251001-v1:0"
}
Fields:
answerMarkdown: safe Markdown answer rendered by the browser widget.evidenceCards: page and KB snippets used as public evidence.ctaCards: visitor actions, currently link CTAs.followUps: suggested next questions for the visitor.degraded: true when page or KB retrieval degraded but a safe fallback answer was returned.retrievalMode: page, related-page, and KB retrieval mode summary.modelId: configured generation target used by the backend.
6. Stream the generative lead UI
The embedded widget uses the streaming route:
POST /v2/public/pages/{handle}/{pageSlug}/agentic-chat
Request body:
{
"messages": [
{
"id": "visitor-1",
"role": "user",
"parts": [
{ "type": "text", "text": "What support is included?" }
]
}
]
}
The response is text/event-stream using AI SDK UI message parts. Text parts render as the answer. A tool-renderLeadQualificationSection part renders a collapsed lead card. When expanded, the generated HTML form is placed only inside:
<iframe sandbox="allow-forms allow-scripts"></iframe>
The generated form never injects HTML into the host page DOM. The iframe posts a validated payload to the parent widget, and the parent submits the lead through the existing native endpoint:
POST /v2/public/handles/{handle}/leads
The disclosed lead context includes the current page slug, visitor question, visible answer text, evidence titles, and retrieval mode. This disclosure is visible next to the form so visitors know the answer context is included with their request.
Use this curl smoke test to confirm the route streams:
curl -i -N -X POST "${API_BASE}/v2/public/pages/${HANDLE}/${PAGE_SLUG}/agentic-chat" \
-H "content-type: application/json" \
-d '{
"messages": [
{
"role": "user",
"parts": [
{ "type": "text", "text": "What support is included, and what should I share for follow-up?" }
]
}
]
}'
Expected headers include:
content-type: text/event-stream; charset=utf-8
Expected stream parts include text plus a lead UI tool part such as:
tool-renderLeadQualificationSection
7. Configure rich generated UI
The generated lead UI has two layers:
- Native React layer: the widget renders the collapsed card, dynamic workspace, field preview, evidence cards, CTA cards, and follow-up chips.
- Sandboxed HTML layer: only the generated form HTML is placed into the iframe.
The model can generate the form copy, labels, and up to 3 custom qualification fields, but the server validates the output before it reaches the browser:
| Limit | Rule |
|---|---|
| HTML size | Maximum 12 KB. |
| Required field | email is always required. |
| Native optional fields | name, company, phone, and message. |
| Generated fields | Up to 3 additional qualification fields, with a maximum of 8 total fields. |
| Blocked HTML | No script, style, iframe, object, embed, link, or img tags. |
| Blocked attributes | No inline on* handlers, inline style, or external src, href, or action values. |
| Submission | The parent widget posts to POST /v2/public/handles/{handle}/leads with credentials: "omit". |
This means rich generated UI should be expressed as structured fields, labels, disclosure text, and the native dynamicView, not as arbitrary scripts or external widgets.
Example steering note to add as a public-agent KB document:
When the visitor asks for implementation help, generate a lead section that asks
for work email, name, company, launch timeline, current blocker, and desired
handoff outcome. The disclosure must say the current page, question, answer,
evidence titles, and retrieval mode are included with the lead.
Specialized rich cards can also be driven from structured KB. For example, productivity guides can include a fenced productivity_lesson_card block. When retrieved, the streaming route can expose a renderProductivityLessonCards tool and the widget renders native lesson cards instead of injecting HTML into the page.
Agent-assisted group buying and calendar coordination
Agentic pages can expose a handle-level skill file:
GET /v2/public/handles/{handle}/agent-skill.md
Visitors with a visitor session can store buying and calendar instructions:
PUT /v2/public/group-buys/{handle}/{groupBuySlug}/my-instructions
The request body is:
{
"skillMarkdown": "# Buying instructions\n\n```json 10x.group_buy_constraints\n{\"groupBuy\":{\"autoCommitInterest\":true,\"quantity\":2,\"maxUnitPriceCents\":6000,\"currency\":\"usd\"},\"calendar\":{\"autoBook\":true,\"eventSlug\":\"group-buy-call\",\"attendeeEmail\":\"buyer@example.com\",\"attendeeName\":\"Buyer\",\"timeZone\":\"UTC\",\"availableWindows\":[{\"start\":\"2026-06-20T13:00:00.000Z\",\"end\":\"2026-06-25T18:00:00.000Z\"}],\"notifyByEmail\":true,\"allowGroupNotification\":true}}\n```"
}
Visitors do not connect calendars. They provide declared availability, email, and explicit auto-booking consent. The handle-owned scheduling calendar remains the source of truth for organizer availability.
The public coordination state is available at:
GET /v2/public/group-buys/{handle}/{groupBuySlug}/coordination
When all matched participants authorize a shared slot, the coordinator can create a handle-owned scheduling booking and report CALENDAR_BOOKED. No payment or vendor action is executed autonomously.
The embedded page assistant can render this state with renderCommunityAgentRoom.
For a visual walkthrough of the public visitor instructions, consensus state, and handle-owned booking boundary, open:
/samples/group-buy-coordination/
KB steering patterns
Write KB articles as public steering cards. Keep them short and explicit.
| Pattern | What to put in KB | Example |
|---|---|---|
| Public facts | Approved product facts and proof | "Launch support includes onboarding checklists and implementation templates." |
| Pricing boundary | What the assistant may say about pricing | "Do not quote custom enterprise pricing. Ask visitors to book a call." |
| Competitor answer | Approved comparison language | "When asked about alternatives, explain fit by use case and avoid unsupported claims." |
| Escalation policy | When to route to a human | "For blocked launches, direct visitors to the implementation support form." |
| Refusal rule | Topics to abstain from | "Do not answer questions about internal credentials, private customer data, or paid-only material." |
Do not seed private page bodies, unpublished plans, secrets, or customer-specific terms into public-agent KB documents. If a page is paid, the assistant must answer only from teaser-safe public content.
Validation checklist
Before sharing the page:
- Public page loads at
https://acme.10x.in/launch-agentor the matching custom-domain URL. - Inline mount renders the chat box, or the floating launcher appears when no inline mount exists.
POST /v2/public/pages/{handle}/{pageSlug}/agentic-questionreturns200.POST /v2/public/pages/{handle}/{pageSlug}/agentic-chatreturns200withtext/event-stream.- The answer includes a page evidence card for page-context questions.
- A KB-backed question returns a
kb_docevidence card. - Streaming responses include a generated lead section rendered in a sandboxed iframe.
- Generated lead submissions post to
POST /v2/public/handles/{handle}/leadsand disclose the full answer context sent with the lead. - Unsupported secret/private questions abstain.
- A 501-character question returns
400 question_too_long. - A disabled handle returns a non-leaky
404. - Paid-page questions never expose private markers or paid-only content.
Related docs
Updated Jun 19, 2026
