@agent-native/core 0.122.3 → 0.123.0

package/docs/content/template-dispatch.mdx

@@ -5,14 +5,14 @@ description: "Dispatch is the workspace control plane — central inbox, cross-a
 
 # Dispatch
 
+Dispatch is the app you run alongside your other Agent Native apps to keep a multi-app workspace coordinated: one inbox for every channel, one secrets vault, and one agent that routes each request to the right specialist app instead of trying to do everything itself. It's for whoever runs the workspace — not for someone building a single standalone app.
+
 <Callout tone="info">
 
 **See also:** for the conceptual overview of what Dispatch does and when you want it, see [Dispatch](/docs/dispatch). This page is the template-specific reference.
 
 </Callout>
 
-Dispatch is the **workspace control plane**. Where other templates are domain apps (Mail, Calendar, Analytics, Brain), Dispatch is the app you run _alongside_ them to coordinate everything: a central inbox, a secrets vault, scheduled jobs, Slack/Telegram integration, and an orchestrator agent that delegates domain work to the right specialist app over [A2A](/docs/a2a-protocol).
-
 <WireframeBlock id="doc-block-iw1glr">
   <Screen
     surface="desktop"
@@ -22,7 +22,7 @@ Dispatch is the **workspace control plane**. Where other templates are domain ap
   />
 </WireframeBlock>
 
-If you're running an [multi-app workspace](/docs/multi-app-workspace) with many apps, Dispatch is the glue.
+If you're running a [multi-app workspace](/docs/multi-app-workspace) with many apps, Dispatch is the glue.
 
 <Diagram id="doc-block-12njifj" title={"Orchestrate, don't specialize"} summary={"Messages from every channel land in one inbox; the orchestrator triages and delegates domain work to the right specialist app over A2A — secrets, resources, and approvals stay central."}>
 
@@ -86,18 +86,13 @@ If you're running an [multi-app workspace](/docs/multi-app-workspace) with many
 
 ## What it does {#what-it-does}
 
-- **Central inbox.** Slack DMs, Telegram messages, email notifications, A2A requests from other agents — all land in one place. The Dispatch agent triages and either handles them itself or delegates. See [Messaging](/docs/messaging) for how to wire Slack, email, and Telegram into your workspace.
-- **Orchestrator, not specialist.** Dispatch does _not_ try to be the email app or the analytics app. When someone asks "summarize last week's signups," Dispatch calls the analytics agent over A2A and returns the answer. When someone asks "draft a reply to Alice," Dispatch calls the mail agent.
+- **Central inbox.** Slack, Microsoft Teams, Discord, Telegram, WhatsApp, and email all land in one place. Dispatch triages and either handles a request itself or delegates it. See [Messaging, routing, and approvals](/docs/template-dispatch-messaging-routing).
 - **Control-plane shell.** Chats, projects, runs, workspace apps, agents, and automations live in one operational shell, with status-first lists and drill-downs instead of one-off dashboards.
-- **Secrets vault.** A central store for API keys, OAuth tokens, and shared credentials. Apps in the workspace resolve secrets from Dispatch instead of duplicating them in every `.env`. Requests + approvals for sensitive access.
-- **Workspace resources.** Global skills, guardrail instructions, custom agent profiles, reference resources, and HTTP MCP servers can be created once in Dispatch. All-app resources are inherited at runtime by every app with no copy or manual sync step; selected grants are for app-specific exceptions.
-- **Reusable integrations.** One place to connect provider accounts, track
-  credential refs, and grant apps access. Dispatch owns provider identity and
-  app grants; domain apps still own app-specific source choices such as Brain's
-  Slack channel allow-list or Analytics' metric/dashboard configuration.
-- **Scheduled jobs hub.** Cross-app [recurring jobs](/docs/recurring-jobs) live here: "every weekday at 7, pull yesterday's key metrics from analytics and draft a morning summary email."
-- **Dreams.** Dispatch can review recent agent runs, failures, feedback, and successful patterns to propose memory, skill, job, and instruction improvements before anything durable is applied.
-- **Approval flow.** Destructive or external actions (sending money, shipping an outbound email, posting to Slack at scale) can require an admin OK before they fire. Dispatch owns the queue.
+- **Orchestrator, not specialist.** Dispatch does _not_ try to be the email app or the analytics app. When someone asks "summarize last week's signups," Dispatch calls the analytics agent over A2A and returns the answer.
+- **Secrets vault and reusable integrations.** API keys, OAuth tokens, and provider accounts are saved once and granted to whichever apps need them, with a request/approve flow and an audit trail. See [Secrets, integrations, and workspace connections](/docs/template-dispatch-vault-integrations).
+- **Workspace resources.** Global skills, guardrail instructions, custom agent profiles, reference resources, and HTTP MCP servers can be created once in Dispatch. All-app resources are inherited at runtime by every app with no copy step; selected grants cover app-specific exceptions.
+- **Scheduled jobs and Dreams.** Cross-app recurring jobs live here, alongside a review loop that inspects recent runs and proposes memory, skill, and instruction improvements. See [Operating the workspace](/docs/template-dispatch-operations).
+- **Approval flow.** Durable changes — saved delivery destinations, All-app workspace resources, and shared or team-wide Dream memory proposals — can require a second admin's OK before they take effect.
 
 ## When to use it {#when-to-use}
 
@@ -105,290 +100,36 @@ Use Dispatch when:
 
 - You have **two or more** agent-native apps in a workspace and want one place to coordinate between them.
 - You need **centralized secrets** with per-app grants and an audit trail.
-- You want a **messaging hub** that routes Slack or Telegram into the right domain agent.
+- You want a **messaging hub** that routes Slack, Teams, Discord, Telegram, WhatsApp, or email into the right domain agent.
 - You want **scheduled jobs** that pull data from several apps.
 
 Skip it for a single-app scaffold — use the [Chat template](/docs/template-chat) or any of the domain templates directly.
 
 Live demo: [dispatch.agent-native.com](https://dispatch.agent-native.com).
 
-## What you'll do with it {#what-youll-do}
-
-Day-to-day, Dispatch is the place admins and ops folks open to keep the workspace running:
-
-- **Connect Slack, email, and Telegram** so people can message your agent from wherever they already work. See [Messaging](/docs/messaging) for the wiring steps.
-- **Save shared secrets once.** API keys, OAuth tokens, and service credentials live in the vault and the other apps in your workspace pull from there instead of every team member juggling their own `.env`.
-- **Connect providers once.** Reusable integrations store safe account metadata
-  and credential references, then grant apps such as Brain, Analytics, Mail, or
-  Dispatch access without copying raw secrets. App-specific source
-  configuration stays in the app that uses the provider.
-- **Expose one MCP connector.** Add
-  `https://dispatch.agent-native.com/mcp` in Claude, ChatGPT,
-  Codex, Cursor, or another MCP host, then choose which workspace apps the
-  connector can reach from Dispatch's **Agents** page. Use a direct app URL
-  only when that host should be isolated to one app.
-- **Manage automations.** The Automations view shows enabled state, last run,
-  next run, and last error from the underlying `jobs/*.md` schedules, and lets
-  you enable or disable a job without editing files by hand.
-- **Keep company context global.** Put personas, positioning, messaging, company facts, brand guidelines, and guardrails in Dispatch Resources once, then preview the effective workspace -> app/org -> personal stack for any app/user or inspect the stack from an app card's Context view.
-- **Set up recurring jobs.** "Every Monday at 7am, ask the analytics agent for last week's signups and email me a summary." See [Recurring Jobs](/docs/recurring-jobs).
-- **Review dream proposals.** Dispatch Dreams inspect prior agent runs and create source-backed proposals for what the workspace should remember, which stale notes should be cleaned up, and which repeated lessons should become skills or jobs.
-- **Approve outbound actions before they fire.** Sending money, mass-emailing customers, or posting to a public Slack channel can be gated behind an admin OK.
-- **See who has access to what.** Per-app grants, request queue, and an audit log of who used which secret when.
-- **Route messages to the right specialist.** A Slack DM about analytics goes to the analytics agent; one about email goes to the mail agent — Dispatch picks.
-
-## Architecture at a glance {#architecture}
-
-_How it works under the hood (for developers)._
-
-- **Orchestrator agent.** The chat is set up as a router: it reads `AGENTS.md`, `LEARNINGS.md`, and routes to specialist sub-agents or remote A2A agents.
-- **Remote agent registry.** A2A agent manifests are workspace-runtime entries (not a checked-in template source folder): in a multi-app workspace, sibling apps under `apps/` are auto-discovered as A2A peers — no manual registration needed. Dispatch calls them using the `call-agent` action.
-- **Vault schema.** Drizzle tables for secrets, grants, requests, approvals, and audit logs. These live in the `@agent-native/dispatch` package (`packages/dispatch/src/db/schema.ts`) and are re-exported into the template via `templates/dispatch/server/db/index.ts` — there is no template-local `server/db/schema.ts`. Dispatch's runtime ships in the package, not in template source (consistent with the note below that `@agent-native/dispatch` owns the shell, sidebar, and built-in pages).
-- **Slack / Telegram plugins.** Server plugins that register webhooks and forward incoming messages to the orchestrator agent.
-- **Workspace MCP resources.** Add HTTP MCP server definitions under `mcp-servers/*.json` in Resources, then scope them to All apps or selected app grants just like skills and context.
-
-<DataModel
-  id="doc-block-1pitn7l"
-  title="Secrets vault schema"
-  summary={
-    "Secrets are stored once; grants give a named app access; requests + reviews gate sensitive access; the audit log records who used which secret when. Defined in @agent-native/dispatch (packages/dispatch/src/db/schema.ts)."
-  }
-  entities={[
-    {
-      id: "secrets",
-      name: "vault_secrets",
-      note: "Stored credential values",
-      fields: [
-        {
-          name: "id",
-          type: "text",
-          pk: true,
-        },
-        {
-          name: "owner_email",
-          type: "text",
-        },
-        {
-          name: "org_id",
-          type: "text",
-          nullable: true,
-        },
-        {
-          name: "name",
-          type: "text",
-        },
-        {
-          name: "credential_key",
-          type: "text",
-        },
-        {
-          name: "value",
-          type: "text",
-          note: "secret value",
-        },
-        {
-          name: "provider",
-          type: "text",
-          nullable: true,
-        },
-      ],
-    },
-    {
-      id: "grants",
-      name: "vault_grants",
-      note: "Per-app access grant",
-      fields: [
-        {
-          name: "id",
-          type: "text",
-          pk: true,
-        },
-        {
-          name: "secret_id",
-          type: "text",
-          fk: "vault_secrets.id",
-        },
-        {
-          name: "app_id",
-          type: "text",
-        },
-        {
-          name: "granted_by",
-          type: "text",
-        },
-        {
-          name: "status",
-          type: "text",
-        },
-      ],
-    },
-    {
-      id: "requests",
-      name: "vault_requests",
-      note: "Access request + review",
-      fields: [
-        {
-          name: "id",
-          type: "text",
-          pk: true,
-        },
-        {
-          name: "credential_key",
-          type: "text",
-        },
-        {
-          name: "app_id",
-          type: "text",
-        },
-        {
-          name: "reason",
-          type: "text",
-          nullable: true,
-        },
-        {
-          name: "status",
-          type: "text",
-        },
-        {
-          name: "reviewed_by",
-          type: "text",
-          nullable: true,
-        },
-      ],
-    },
-    {
-      id: "audit",
-      name: "vault_audit_log",
-      note: "Who used which secret when",
-      fields: [
-        {
-          name: "id",
-          type: "text",
-          pk: true,
-        },
-        {
-          name: "secret_id",
-          type: "text",
-          fk: "vault_secrets.id",
-          nullable: true,
-        },
-        {
-          name: "app_id",
-          type: "text",
-          nullable: true,
-        },
-        {
-          name: "action",
-          type: "text",
-        },
-        {
-          name: "actor",
-          type: "text",
-        },
-      ],
-    },
-  ]}
-  relations={[
-    {
-      from: "secrets",
-      to: "grants",
-      kind: "1-n",
-      label: "granted via",
-    },
-    {
-      from: "secrets",
-      to: "audit",
-      kind: "1-n",
-      label: "use recorded by",
-    },
-  ]}
-/>
-
-- **MCP hub mode.** Dispatch can still act as the workspace's [MCP hub](/docs/mcp-clients#hub) so every other app in the workspace pulls the same org-scope MCP server list. Separately, Dispatch's own `/mcp` endpoint is the recommended external MCP connector for Claude, ChatGPT, and other hosts that should reach multiple workspace apps.
-
-## Dreams {#dreams}
-
-Dreams are Dispatch's review loop for agent memory. A dream pass looks over existing agent runs, thread debug data, feedback, evals, and repeated tool failures, then writes a report with proposed changes. The proposals can target personal memory, shared `LEARNINGS.md`, workspace instructions, workspace skills, workspace knowledge, workspace agents, or recurring jobs, but shared and workspace-level changes stay reviewable rather than being applied silently.
-
-Dream proposals are checked against the personal memory index, existing `memory/*.md` files, and shared `LEARNINGS.md` before they are saved. Duplicate lessons are skipped in the report, while likely stale personal memories are updated in place instead of producing parallel notes. Within a report, Dreams also deduplicate repeated evidence by thread, signal type, and normalized quote, strip injected context from user-correction detection, and summarize raw eval/tool rows into human-readable bullets before they appear in proposal text. When a pass finds signals but intentionally creates no proposals, the report includes guardrail notes explaining which evidence was suppressed.
-
-When Dispatch approval policy is enabled, applying a shared or team-wide dream proposal creates a pending approval request instead of writing immediately. Creating, updating, or deleting an All-app workspace resource also queues an approval request. Personal memory proposals and selected-only resource edits can still be applied directly after review.
-
-Use Dreams when you want to answer questions like "what did agents keep getting wrong this week?", "what should we remember?", or "which repeated lesson deserves a skill?" Inbound Slack, email, Telegram, WhatsApp, and web-derived evidence is treated as untrusted input, so proposals from those sources require review and provenance before they affect shared memory. Workspace-instruction proposals require durable evidence spanning at least two threads or two source apps; eval-only noise, account setup issues, quota limits, and single-app UI wording corrections stay out of global instructions.
-
-### Dream input validation boundaries
-
-Because evidence is collected from external, untrusted sources (such as chat transcripts, webhooks, and third-party integrations), the Dream processor enforces strict input validation boundaries to prevent prompt injection and payload-size attacks:
-
-- **Byte Size Limits:** Individual thread payloads are capped at a maximum of 10KB of text content per message, and candidate scans are truncated if they exceed 100KB in total to prevent context exhaustion.
-- **Sanitization:** All text inputs are sanitized to strip control characters, binary payloads, and non-printable Unicode ranges.
-- **Schema Validation:** Inbound debug data and thread history are parsed against strict Zod schemas before being compiled into LLM prompts. Any candidate structure that fails schema validation is immediately discarded from the processing batch.
-- **Escaping:** All user-provided text chunks are dynamically escaped when formatted into the prompt templates to prevent prompt injections (e.g., trying to hijack the Dream loop to write arbitrary instructions).
-
-In the Dispatch UI, open **Dreams** to run a manual pass, review candidate threads, inspect the report, and open each proposal's review sheet before applying or rejecting it. Use **Settings** to edit the recurring cron schedule, source scope, timeout/concurrency limits, candidate limit, and minimum candidate threshold; use **Ensure schedule** after saving when you want the `jobs/dispatch-dream.md` recurring job materialized from those settings. The review sheet shows approval behavior, the current target content, proposed content, and source evidence. Agents use the same workflow through actions:
-
-- `list-dream-candidates` finds recent threads with grounded signals such as explicit user corrections, failed runs, tool errors, feedback, eval failures, and successful checkpointed workflows. Pass `sourceId: "all"` or `sourceIds` to scan multiple thread-debug sources; `sourceTimeoutMs`, `sourceConcurrency`, `sourceStartStaggerMs`, `threadConcurrency`, and `threadTimeoutMs` keep production scans partial and bounded, and the response includes per-source health.
-- `create-dream-report` creates the report and pending proposals. Multi-source reports include a Source Health section so partial scans are visible during review. Repeated corrections and recurring failures can become workspace-resource proposals such as `workspace-instruction`; repeated successful checkpointed workflows can become `workspace-skill` proposals.
-- `get-dream-settings` and `set-dream-settings` read and update the recurring dream schedule, source scope, timeout/concurrency controls, limit, and minimum candidate threshold.
-- `get-dream`, `preview-dream-proposal`, `apply-dream-proposal`, and `reject-dream-proposal` handle review.
-- `ensure-dream-job` creates the safe recurring dream job once manual reports are useful.
+## What you'll do with it day-to-day {#what-youll-do}
 
-The Dispatch template's local action runner also exposes packaged Dispatch actions, so in development you can run the same workflow from `apps/dispatch`:
+- **Connect your channels.** Slack, Microsoft Teams, Discord, Telegram, WhatsApp, or email — see [Messaging, routing, and approvals](/docs/template-dispatch-messaging-routing) for wiring steps.
+- **Save secrets and connect providers once.** Every other app in the workspace pulls from the vault or a shared connection instead of holding its own copy. See [Secrets, integrations, and workspace connections](/docs/template-dispatch-vault-integrations).
+- **Keep company context global.** Put personas, positioning, company facts, and guardrails in Dispatch Resources once, then preview the effective workspace → app/org → personal stack for any app or user.
+- **Set up recurring jobs.** "Every Monday at 7am, ask the analytics agent for last week's signups and email me a summary." See [Operating the workspace](/docs/template-dispatch-operations).
+- **Review Dream proposals.** Dispatch's memory review loop inspects prior runs and proposes source-backed changes to what the workspace remembers.
+- **Gate durable changes.** Saved destinations, All-app workspace resources, and shared Dream proposals can require a second admin's OK before they apply — see the approval flow on [Messaging, routing, and approvals](/docs/template-dispatch-messaging-routing).
+- **Watch the operator console.** Monitoring, database admin, thread debugging, audit history, and usage metrics all live under one roof — see [Operating the workspace](/docs/template-dispatch-operations).
 
-```bash
-pnpm action get-dream-settings
-pnpm action set-dream-settings --enabled true --schedule "0 9 * * 1" --allSources true --limit 8
-pnpm action create-dream-report --allSources true --sourceTimeoutMs 30000 --limit 8
-```
-
-## Scaffolding {#scaffolding}
+## Get started {#get-started}
 
 ```bash
 npx @agent-native/core@latest create my-platform
 # pick "Dispatch" in the multi-select picker, plus whichever domain apps you want
 ```
 
-If you prefer to name the template directly instead of using the picker:
-
-```bash
-npx @agent-native/core@latest create my-platform --template dispatch
-# add more apps in the same workspace as you go
-```
-
-Dispatch is usually scaffolded into a workspace alongside the apps it coordinates. For a workspace, Dispatch's shared auth, database, and brand are inherited from the workspace core — see [Multi-App Workspace](/docs/multi-app-workspace).
-
-There is no meaningful `--standalone` Dispatch: a control plane with nothing to coordinate is just an empty inbox. Scaffold it into a workspace with at least one domain app so it has agents to route to over A2A. (The flag still works and produces a runnable app, but the orchestrator has no specialists to delegate to until you add sibling apps.)
-
-## First local run {#first-local-run}
-
-From the workspace root:
-
-```bash
-pnpm install
-pnpm dev
-```
-
-Open the Dispatch URL printed by the dev server. Local development uses the same Better Auth sign-in flow as production. Create a local account with email + password; email verification is skipped in development, and the password is stored only in your local app database. There is no supported auth bypass in the default scaffold, because the agent, workspace resources, vault, and sharing model all rely on a real user session.
-
-You can click through the Dispatch UI after signing in. To use the chat composer or run agent tasks, connect an LLM provider first:
-
-1. Open **Settings**.
-2. In **LLM**, either connect Builder.io or add your own provider key such as `ANTHROPIC_API_KEY`.
-3. Return to **Overview** and try the composer.
-
-## Customizing it {#customize}
-
-Dispatch is a full template like any other — see [Templates](/docs/cloneable-saas). Ask the agent to "add a new integration for Datadog" or "route Slack DMs from channel X to the analytics agent" and it'll edit the routing config, add the webhook handler, and wire it up.
-
-For workspace-specific management screens, add local React Router pages and
-register them in `app/dispatch-extensions.tsx`. The generated workspace owns
-only the extra tab and route; `@agent-native/dispatch` keeps owning the shell,
-sidebar, built-in pages, and future package updates.
+Dispatch is almost always scaffolded into a workspace alongside the apps it coordinates — a control plane with nothing to coordinate is just an empty inbox. See [Getting started](/docs/getting-started) for installing dependencies, running the dev server, and creating your first account.
 
 ## What's next
 
-- [**Messaging**](/docs/messaging) — connecting Slack, email, and Telegram so you can talk to your agent from anywhere
+- [**Secrets, integrations, and workspace connections**](/docs/template-dispatch-vault-integrations) — the vault, reusable provider integrations, and ad hoc/staged provider data access
+- [**Messaging, routing, and approvals**](/docs/template-dispatch-messaging-routing) — connecting channels, the orchestrator, and the approval queue
+- [**Operating the workspace: jobs, Dreams, and the operator console**](/docs/template-dispatch-operations) — recurring jobs, Dreams, monitoring, and the admin surfaces
+- [**Dispatch — architecture for developers**](/docs/template-dispatch-developers) — the package/app split, scaffolding, and customizing it
 - [**Multi-App Workspace**](/docs/multi-app-workspace) — running Dispatch alongside multiple apps
-- [**A2A Protocol**](/docs/a2a-protocol) — how Dispatch delegates to specialist agents
-- [**MCP Clients — Hub Mode**](/docs/mcp-clients#hub) — sharing MCP servers across the workspace
-- [**Recurring Jobs**](/docs/recurring-jobs) — scheduled tasks Dispatch runs

package/docs/content/template-forms-building-publishing.mdx

@@ -0,0 +1,135 @@
+---
+title: "Building and publishing a form"
+description: "The field types Forms ships with, conditional show/hide logic, fine-tuning fields in the visual editor, and publishing a protected, branded public form."
+---
+
+# Building and publishing a form
+
+This page covers designing a form's fields and getting it in front of respondents — through chat, the visual editor, or both. It's written for whoever is putting the form together, with a JSON reference partway through for anyone scripting form creation directly.
+
+## Field types {#field-types}
+
+Forms ships with 11 field types out of the box. Ask the agent for any of them by name, or describe the question and let it pick:
+
+<Table
+  id="doc-block-forms3"
+  title="Shipped field types"
+  columns={["Type", "Needs options", "Example use"]}
+  rows={[
+    ["text", "No", "Name, company"],
+    ["email", "No", "Contact email"],
+    ["number", "No", "Age, quantity"],
+    ["textarea", "No", "Message, comments"],
+    ["select", "Yes", "Country, department"],
+    ["multiselect", "Yes", "Skills, interests"],
+    ["checkbox", "No", "Consent, opt-in"],
+    ["radio", "Yes", "Gender, preference"],
+    ["date", "No", "Birthday, deadline"],
+    ["rating", "No", "Satisfaction, quality (1-5 stars)"],
+    ["scale", "No", "NPS, likelihood (numeric range)"],
+  ]}
+/>
+
+Each field is a JSON object under the hood, whether the agent writes it or you script `create-form` directly:
+
+```json
+{
+  "id": "team_size",
+  "type": "select",
+  "label": "Team size",
+  "placeholder": "Select...",
+  "description": "Roughly how many people are on your team?",
+  "required": true,
+  "options": ["1-5", "6-20", "21-100", "100+"],
+  "validation": {
+    "min": 1,
+    "max": 100,
+    "pattern": "^[0-9]+$",
+    "message": "Enter a number"
+  },
+  "width": "half"
+}
+```
+
+`id`, `type`, `label`, and `required` are the only required properties. `options` is required for `select`, `multiselect`, and `radio`; `validation` (`min`/`max`/`pattern`/`message`) is optional and type-appropriate; `width` is `"full"` (default) or `"half"` for a side-by-side layout.
+
+## Conditional fields
+
+A field can stay hidden until an earlier answer matches a rule:
+
+```json
+{
+  "id": "other_use_case",
+  "type": "text",
+  "label": "Tell us more",
+  "required": false,
+  "conditional": {
+    "fieldId": "use_case",
+    "operator": "equals",
+    "value": "Other"
+  }
+}
+```
+
+`fieldId` must reference a field that appears **earlier** in the form — a forward or missing reference is rejected before it can be saved. The supported operators are `equals`, `not_equals`, and `contains` (the last one matches against multi-select arrays too). When a field is hidden by its condition, its value is stripped before the response is stored or delivered to any integration — a hidden field never leaks a stale or default value into your data.
+
+## Fine-tuning visually
+
+Once a form exists, open its builder to edit labels, placeholders, required state, options, and field order directly — useful when you want pixel-level control rather than describing the change in chat. The builder has four tabs: Edit, Responses, Settings, and Integrations.
+
+<WireframeBlock id="doc-block-forms4">
+  <Screen
+    surface="desktop"
+    html={
+      "<div style='display:flex;flex-direction:column;min-height:520px;box-sizing:border-box'><div style='display:flex;align-items:center;gap:10px;padding:14px 16px;border-bottom:1.4px solid var(--wf-line)'><strong>Beta signup</strong><span class='wf-pill accent'>published</span><div style='flex:1'></div><button>Share</button><button class='primary'>Unpublish</button></div><div style='display:flex;gap:8px;padding:12px 16px;border-bottom:1.4px solid var(--wf-line)'><span class='wf-pill accent'>Edit</span><span class='wf-pill'>Responses 187</span><span class='wf-pill'>Settings</span><span class='wf-pill'>Integrations</span></div><div style='display:flex;flex-direction:column;gap:12px;padding:30px 78px;overflow:hidden'><h2 style='margin:0'>Beta signup</h2><p class='wf-muted' style='margin:0'>Reserve a spot in the upcoming private beta cohort.</p><div class='wf-card'><strong>Full name</strong><input value='Ada Lovelace'/></div><div class='wf-card'><strong>Work email</strong><input value='you@company.com'/></div><div class='wf-card'><strong>Your role</strong><input value='Select...'/></div><div class='wf-card'><strong>Team size</strong><input value='Select...'/></div></div></div>"
+    }
+  />
+</WireframeBlock>
+
+## Publishing
+
+A form moves through three statuses:
+
+| Status      | Meaning                                  | Public access          |
+| ----------- | ---------------------------------------- | ---------------------- |
+| `draft`     | Work in progress, not publicly available | No                     |
+| `published` | Live and accepting responses             | Yes                    |
+| `closed`    | No longer accepting responses            | Shows a closed message |
+
+A form can't be published if it has no fields, any field is missing a label, or a `select`/`multiselect`/`radio` field has no options — publishing is rejected with the specific reason so it's easy to fix.
+
+The public URL is `/f/<slug>`, where the slug is generated from the title plus a short unique suffix (`beta-signup-a1b2c3`) and regenerates automatically whenever the title changes, unless you set a custom slug. For a form meant to be genuinely anonymous, create it with `status: "published"` from the start and use the exact public URL the create step returns, rather than assuming a later publish step.
+
+## Protecting and branding a public form
+
+**Captcha.** Public submissions can require [Cloudflare Turnstile](https://www.cloudflare.com/products/turnstile/) verification — opt-in by setting a site key and secret key in Settings. Turnstile is on top of two always-on defenses: a hidden honeypot field that silently discards bot submissions, and a minimum fill-time check that rejects anything submitted faster than a human plausibly could.
+
+<Callout tone="warning">
+  Both Turnstile keys need to be set together. The public form page only renders
+  the captcha widget (and produces a token) when the site key is configured, and
+  the server only verifies that token when it exists — so setting just the
+  secret key verifies nothing, and setting just the site key shows a widget the
+  server never checks.
+</Callout>
+
+**Branding.** Every standalone public form shows a small "Built with Agent Native" badge in the bottom corner. It isn't a per-form setting — it's hidden automatically only when the form is embedded inside another page, such as an embedded feedback popover, since that context already carries its host app's own branding.
+
+**Anonymous mode.** Set `anonymous: true` on a form's settings for genuine anonymity: submissions on that form skip capturing the request IP, the submitter's session or claimed email, the page URL, the client surface, and any chat/run ids — none of it is ever written, not just hidden later. This is different from an ordinary published form, which is publicly reachable but still records who and where a response came from when that information is available.
+
+<WireframeBlock id="doc-block-forms5">
+  <Screen
+    surface="desktop"
+    html={
+      "<div style='display:flex;flex-direction:column;min-height:520px;box-sizing:border-box;padding:40px 60px;gap:20px;position:relative'><div><h2 style='margin:0'>Customer feedback</h2><p class='wf-muted' style='margin:6px 0 0'>Tell us what is and isn't working.</p></div><div class='wf-card'><strong>Overall satisfaction</strong><span style='font-size:20px;letter-spacing:2px'>★★★★☆</span></div><div class='wf-card'><strong>What could be better?</strong><input value='Type your answer...'/></div><div class='wf-card' style='align-items:center;text-align:center;gap:6px'><span class='wf-pill'>Verify you're human</span><span class='wf-muted' style='font-size:12px'>Cloudflare Turnstile widget</span></div><button class='primary' style='align-self:flex-start'>Submit</button><span class='wf-pill' style='position:absolute;right:24px;bottom:20px'>Built with Agent Native</span></div>"
+    }
+  />
+</WireframeBlock>
+
+One more setting worth knowing: `allowedOrigins` restricts which origins may submit to the form cross-origin — handy when embedding a form's submit endpoint in another site's widget. Leaving it unset allows any origin, matching how a plain public form link behaves today.
+
+## What's next
+
+- [**Forms**](/docs/template-forms) — the product overview
+- [**Responses, insights, and destinations**](/docs/template-forms-responses) — what happens after a submission arrives
+- [**Forms — data model and actions**](/docs/template-forms-developers) — the `FormField`/`FormSettings` schema and every action
+- [**Messaging**](/docs/messaging) — connecting Slack for submission notifications