@agent-native/core 0.7.12 → 0.7.14

package/docs/content/messaging.md

@@ -0,0 +1,284 @@
+---
+title: "Messaging"
+description: "Talk to your agent from Slack, email, Telegram, or WhatsApp — same agent, same memory, same tools."
+---
+
+# Messaging
+
+Talk to your agent from the platforms you already use. Send a Slack DM, reply to an email, message a Telegram bot, or ping over WhatsApp — same agent, same memory, same tools, same thread history as the web chat.
+
+## Overview {#overview}
+
+Messaging integrations let users reach their agent from external messaging platforms instead of opening the web UI. Whichever platform a message comes in on, the agent processes it with the same system prompt, the same actions, and the same database — and replies in the same thread.
+
+Each integration works through webhooks. The platform delivers incoming messages over HTTP, the agent processes them in the background, and the response is posted back. No polling, no long-lived connections.
+
+> Note: this doc is specifically about platforms you can _message_ your agent over. Other kinds of integrations — Google Docs, OAuth providers, SQL databases, MCP servers, etc. — are covered in their own docs.
+
+## How it works {#how-it-works}
+
+The flow is the same for every platform:
+
+1. A user sends a message on the external platform (Slack, email, Telegram, WhatsApp)
+2. The platform delivers the message to your app via a webhook at `/_agent-native/integrations/<platform>/webhook`
+3. The integrations plugin validates the request, extracts the message text and thread context, and maps it to an internal conversation thread
+4. The agent processes the message in the background using the same pipeline as the web chat
+5. The response is posted back to the external platform in the same thread
+
+`User (Slack/Email/Telegram/WhatsApp)` → `Webhook` → `Agent Processing` → `Response posted back`
+
+## Setup {#setup}
+
+The integrations plugin auto-mounts when no custom version exists in your template. To customize it, create a plugin file:
+
+```ts
+// server/plugins/integrations.ts
+import { createIntegrationsPlugin } from "@agent-native/core/server";
+import { scriptRegistry } from "../../agent.config";
+
+export default createIntegrationsPlugin({
+  actions: scriptRegistry,
+  systemPrompt: "You are a helpful assistant...",
+});
+```
+
+The plugin registers webhook routes for each enabled platform under `/_agent-native/integrations/`. Which platforms are active depends on which environment variables are configured.
+
+## Dispatch as the orchestrator {#dispatch}
+
+Messaging integrations are most powerful when set up in the **Dispatch template** (`templates/dispatch/`). Dispatch is a central control plane that:
+
+- Receives inbound messages from every configured platform (Slack, email, Telegram, WhatsApp) in one place
+- Delegates domain-specific work to specialist agents over the [A2A protocol](/docs/a2a-protocol) via the `call-agent` action
+- Sends the result back to the original platform in the same thread
+
+The pattern is one inbox, many specialist agents. A user emails the Dispatch agent "make me a slide deck about Q3" → Dispatch delegates to the slides agent → the slides agent returns a URL → Dispatch emails the user back with the link. Same flow for analytics queries, calendar invites, content drafts, anything else you have a specialist agent for.
+
+You don't have to use Dispatch — any template that mounts the integrations plugin can receive messages — but Dispatch is the recommended home for messaging because it can route across your whole agent fleet.
+
+See [Dispatch template](/docs/template-dispatch) and [A2A protocol](/docs/a2a-protocol) for details.
+
+## Slack {#slack}
+
+### 1. Create a Slack app
+
+Go to [api.slack.com/apps](https://api.slack.com/apps) and create a new app. Under **OAuth & Permissions**, add the following bot token scopes:
+
+- `chat:write` — send messages
+- `app_mentions:read` — receive @-mentions (optional)
+
+### 2. Enable Event Subscriptions
+
+Under **Event Subscriptions**, set the Request URL to:
+
+```text
+https://your-app.example.com/_agent-native/integrations/slack/webhook
+```
+
+Subscribe to the `message.im` bot event (and optionally `app_mention` for channel mentions).
+
+### 3. Set environment variables
+
+```bash
+SLACK_BOT_TOKEN=xoxb-your-bot-token
+SLACK_SIGNING_SECRET=your-signing-secret
+```
+
+The bot token is found under **OAuth & Permissions** after installing the app to your workspace. The signing secret is under **Basic Information**.
+
+## Email {#email}
+
+The email adapter receives inbound mail via Resend or SendGrid webhooks and replies in-thread using standard `Message-ID` / `In-Reply-To` / `References` headers. Sender email addresses are treated as identities — if a user emails the agent from `alice@acme.com`, that maps directly to the workspace user with that email.
+
+Adapter file: `packages/core/src/integrations/adapters/email.ts`
+
+### 1. Set environment variables
+
+```bash
+EMAIL_AGENT_ADDRESS=agent@your-domain.com
+# Configure ONE of these (Resend or SendGrid):
+RESEND_API_KEY=re_...
+SENDGRID_API_KEY=SG...
+# Optional — recommended for production:
+EMAIL_INBOUND_WEBHOOK_SECRET=your-shared-secret
+```
+
+`EMAIL_AGENT_ADDRESS` is the address users send mail to. Set either `RESEND_API_KEY` _or_ `SENDGRID_API_KEY` — whichever provider you use. `EMAIL_INBOUND_WEBHOOK_SECRET` enables Svix signature verification (Resend) or basic-auth / `x-webhook-secret` header verification (SendGrid).
+
+### 2. Configure the webhook URL
+
+```text
+https://your-app.example.com/_agent-native/integrations/email/webhook
+```
+
+### 3. Provider setup — Resend
+
+Two options for the agent address:
+
+- **Free `<slug>.resend.app` address** — no DNS setup required. Pick a slug in the Resend dashboard and your agent gets `agent@<slug>.resend.app`.
+- **Custom domain** — add MX records pointing to Resend per the dashboard's instructions.
+
+Then in the Resend dashboard:
+
+1. Go to **Webhooks** → **Add Endpoint**
+2. Set the URL to `https://your-app.example.com/_agent-native/integrations/email/webhook`
+3. Subscribe to the `email.received` event
+4. Copy the signing secret into `EMAIL_INBOUND_WEBHOOK_SECRET`
+
+### 3. Provider setup — SendGrid
+
+1. In your DNS, add an MX record for the agent's domain pointing to `mx.sendgrid.net` (priority 10)
+2. In the SendGrid dashboard, go to **Settings** → **Inbound Parse** → **Add Host & URL**
+3. Set the host to your domain and the destination URL to `https://your-app.example.com/_agent-native/integrations/email/webhook`
+4. (Recommended) Set basic auth or a custom `x-webhook-secret` header matching `EMAIL_INBOUND_WEBHOOK_SECRET`
+
+### Threading and CC behavior
+
+- **Threading** uses the standard email headers: the agent's reply sets `In-Reply-To` to the inbound `Message-ID` and accumulates the `References` chain. Most clients (Gmail, Outlook, Apple Mail) thread the conversation automatically.
+- **Direct vs CC'd** — the adapter detects whether the agent was in `To` (directly addressed) or `Cc` (overheard). When CC'd, the agent's reply goes to all original recipients (reply-all). The Dispatch system prompt also instructs the agent to only respond when input is clearly being requested, so it stays out of the way on threads it's only copied on.
+- **Identity** — the sender's email address is the identity. It maps directly to a workspace user with that email; the agent acts on behalf of that user.
+
+### Rich responses
+
+Agent replies render as HTML email. The adapter converts markdown to HTML (headings, lists, links, bold, inline code, paragraphs) and wraps it in a minimal styled template, with a plain-text fallback. So tables, bullet lists, and links from the agent come through as proper rich email — not raw markdown.
+
+### Rate limiting and allowed domains
+
+- **Rate limit** — 20 inbound messages per sender per hour, enforced in-memory per process. Excess messages are dropped.
+- **Allowed domains** — the `integration_configs` row for `email` accepts an optional `allowedDomains: string[]`. When set, only senders whose domain is in the list are accepted. Use this to restrict the agent to a specific company or tenant.
+
+### Proactive sends
+
+The agent can email users on its own (not just reply) by calling the `send-platform-message` action with `platform: "email"`. Useful for digest emails, alerts, or follow-ups from automations and recurring jobs.
+
+## Telegram {#telegram}
+
+### 1. Create a bot
+
+Message [@BotFather](https://t.me/BotFather) on Telegram and use the `/newbot` command. You will receive a bot token.
+
+### 2. Set environment variables
+
+```bash
+TELEGRAM_BOT_TOKEN=your-bot-token
+```
+
+### 3. Register the webhook
+
+After deploying your app, call the setup endpoint to register the webhook with Telegram:
+
+```text
+// The integrations plugin exposes a setup endpoint
+POST /_agent-native/integrations/telegram/setup
+
+// This calls Telegram's setWebhook API pointing to:
+// https://your-app.example.com/_agent-native/integrations/telegram/webhook
+```
+
+You can also register the webhook manually using the Telegram Bot API if you prefer.
+
+## WhatsApp {#whatsapp}
+
+### 1. Set up the WhatsApp Cloud API
+
+Go to the [Meta Developer Portal](https://developers.facebook.com/), create an app, and enable the WhatsApp product. Configure a phone number for your business.
+
+### 2. Set environment variables
+
+```bash
+WHATSAPP_ACCESS_TOKEN=your-access-token
+WHATSAPP_VERIFY_TOKEN=your-verify-token
+WHATSAPP_PHONE_NUMBER_ID=your-phone-number-id
+```
+
+The verify token is a string you choose — Meta uses it during webhook verification. The access token and phone number ID come from the Meta Developer Portal.
+
+### 3. Configure the webhook
+
+In the Meta Developer Portal, set the webhook URL to:
+
+```text
+https://your-app.example.com/_agent-native/integrations/whatsapp/webhook
+```
+
+Subscribe to the `messages` webhook field.
+
+## Configuration {#configuration}
+
+Integrations can be managed from the settings UI in the sidebar. Each platform shows its connection status and webhook URL. You can enable/disable individual integrations without removing environment variables.
+
+The webhook URLs follow a consistent pattern:
+
+```text
+/_agent-native/integrations/<platform>/webhook
+
+# Examples:
+/_agent-native/integrations/slack/webhook
+/_agent-native/integrations/email/webhook
+/_agent-native/integrations/telegram/webhook
+/_agent-native/integrations/whatsapp/webhook
+```
+
+## Thread continuity {#thread-continuity}
+
+Conversations from external platforms are mapped to internal threads. Each Slack DM, email thread, Telegram chat, or WhatsApp conversation becomes a persistent thread in the agent-native database. This means:
+
+- The agent retains context across messages in the same external conversation
+- External conversations appear in the web UI alongside web-originated threads, tagged with their source platform
+- You can continue a conversation that started in Slack from the web UI, or vice versa
+
+For email specifically, threading uses the `Message-ID`, `In-Reply-To`, and `References` headers — the oldest Message-ID in the References chain is treated as the thread root, matching Gmail's behavior.
+
+## Custom adapters {#custom-adapters}
+
+To add support for a new messaging platform, implement the `PlatformAdapter` interface:
+
+```ts
+import type { PlatformAdapter } from "@agent-native/core/server";
+
+const myAdapter: PlatformAdapter = {
+  platform: "discord",
+
+  // Verify the incoming webhook request is authentic
+  verifyRequest(request: Request): Promise<boolean> {
+    // Validate signature headers
+  },
+
+  // Extract the message text and thread context from the webhook payload
+  parseMessage(body: unknown): Promise<{
+    text: string;
+    threadId: string;
+    senderId: string;
+    metadata?: Record<string, unknown>;
+  }> {
+    // Parse platform-specific payload
+  },
+
+  // Send the agent's response back to the platform
+  sendResponse(threadId: string, text: string): Promise<void> {
+    // Call the platform's API to post the message
+  },
+};
+```
+
+Register your adapter in the integrations plugin config:
+
+```ts
+export default createIntegrationsPlugin({
+  actions: scriptRegistry,
+  systemPrompt: "You are a helpful assistant...",
+  adapters: [myAdapter],
+});
+```
+
+## Security {#security}
+
+Every incoming webhook is verified before processing:
+
+- **Slack** — HMAC-SHA256 signature verification using `SLACK_SIGNING_SECRET`. The `X-Slack-Signature` header is checked against the request body.
+- **Email (Resend)** — Svix signature verification using `EMAIL_INBOUND_WEBHOOK_SECRET`, with a 5-minute replay window.
+- **Email (SendGrid)** — basic auth or `x-webhook-secret` header matching `EMAIL_INBOUND_WEBHOOK_SECRET`. Plus optional `allowedDomains` filtering on the sender.
+- **Telegram** — requests are validated by checking the secret token set during webhook registration via the Telegram Bot API.
+- **WhatsApp** — Meta's webhook verification challenge (using `WHATSAPP_VERIFY_TOKEN`) and payload signature validation.
+
+All platform credentials (tokens, secrets, API keys) are stored as environment variables and never persisted in the database or source code. Use the settings UI or your deployment platform's env var management to configure them.

package/docs/content/{enterprise-workspace.md → multi-app-workspace.md}

@@ -1,15 +1,15 @@
 ---
-title: "Enterprise Workspace"
+title: "Multi-App Workspace"
 description: "Host many agent-native apps in one monorepo with shared auth, RBAC, skills, instructions, components, and credentials."
 ---
 
-# Enterprise Workspace
+# Multi-App Workspace
 
 When vibe-coding an internal tool takes an afternoon, you don't stop at one. A team ends up with a CRM, a support inbox, a dashboard, a recruiting tracker, an ops console — ten small apps, each scaffolded independently. That's great until you need to change something in all of them.
 
 At that point every app has its own `AGENTS.md`, its own auth plugin, its own copy-pasted layout component, its own hard-coded Slack token, its own idea of what an "organization" is. A compliance rule change means ten PRs. Rotating an API key means ten redeployments. A brand refresh means ten different headers drifting out of sync. The thing that made it easy to build them is now making it hard to manage them.
 
-The **enterprise workspace** pattern is how agent-native solves this. You host all your apps in one monorepo alongside a private **workspace core** package. The core owns everything cross-cutting — auth, RBAC, agent skills, `AGENTS.md`, React components, design tokens, shared credentials, shared actions. Each app shrinks down to the handful of screens that make it unique. Change the core once; every app inherits the change on the next dev reload.
+The **multi-app workspace** pattern is how agent-native solves this. You host all your apps in one monorepo alongside a private **workspace core** package. The core owns everything cross-cutting — auth, RBAC, agent skills, `AGENTS.md`, React components, design tokens, shared credentials, shared actions. Each app shrinks down to the handful of screens that make it unique. Change the core once; every app inherits the change on the next dev reload.
 
 ## What gets shared {#what-gets-shared}
 

package/docs/content/multi-tenancy.md

@@ -85,4 +85,4 @@ If you're evaluating agent-native for a product like a CRM, project tracker, sup
 
 - [Authentication](/docs/authentication) — auth modes, social providers, session API
 - [Security & Data Scoping](/docs/security) — SQL-level isolation, input validation, access guards
-- [Enterprise Workspace](/docs/enterprise-workspace) — hosting multiple agent-native apps in one monorepo with shared auth and RBAC
+- [Multi-App Workspace](/docs/multi-app-workspace) — hosting multiple agent-native apps in one monorepo with shared auth and RBAC

package/docs/content/progress.md

@@ -41,7 +41,7 @@ Separate concern from [notifications](/docs/notifications): notifications fire o
 | `failed`    | Error terminal              |
 | `cancelled` | User interrupted            |
 
-Terminal statuses set `completed_at`. The UI tray shows only `running` rows; completed rows stay in the database for `list-runs` queries.
+Terminal statuses set `completed_at`. The UI tray shows only `running` rows; completed rows stay in the database for `manage-progress --action=list` queries.
 
 ## API {#api}
 
@@ -123,22 +123,22 @@ export function HeaderBar() {
 
 Inline header widget — mount it next to the notifications bell. Shows a spinner icon + count badge when runs are active; click opens a dropdown with one live percent bar per run. Hides the trigger entirely when no active runs. Polls `/_agent-native/runs?active=true` every `pollMs` (default 3 s). Uses shadcn semantic tokens, adapts to light and dark themes.
 
-## Agent tools {#agent-tools}
+## Agent tool {#agent-tool}
 
-Four native tools are registered in every template:
+A single `manage-progress` tool is registered in every template. The `action` parameter selects the operation:
 
-| Tool                  | Purpose                                                         |
-| --------------------- | --------------------------------------------------------------- |
-| `start-run`           | Call at the top of a long task. Returns a runId.                |
-| `update-run-progress` | Call periodically during the task with `percent` and/or `step`. |
-| `complete-run`        | Terminal — one of `succeeded`, `failed`, `cancelled`.           |
-| `list-runs`           | Inspect recent runs (filter by `active=true`).                  |
+| Action     | Purpose                                                         |
+| ---------- | --------------------------------------------------------------- |
+| `start`    | Call at the top of a long task. Returns a runId.                |
+| `update`   | Call periodically during the task with `percent` and/or `step`. |
+| `complete` | Terminal — one of `succeeded`, `failed`, `cancelled`.           |
+| `list`     | Inspect recent runs (filter by `active=true`).                  |
 
 ### When to start a run {#when-to-start}
 
 - Use for anything > ~5 seconds. A spinner with no context feels frozen.
 - Update at natural checkpoints, not every iteration. Every 5–10% is plenty.
-- **Always** call `complete-run`, including in error paths. An orphan `running` row is worse than no row.
+- **Always** call `manage-progress --action=complete`, including in error paths. An orphan `running` row is worse than no row.
 - Pair with `notify` on completion so the user sees the outcome when they're not actively watching the tray.
 
 ## Event bus {#event-bus}
@@ -171,6 +171,6 @@ Notify me that run {{runId}} has been running for a long time.
 
 ## What's next
 
-- [**Notifications**](/docs/notifications) — pair with `complete-run` to tell the user when work finishes
+- [**Notifications**](/docs/notifications) — pair with `manage-progress --action=complete` to tell the user when work finishes
 - [**Automations**](/docs/automations) — watchdog slow runs via `run.progress.updated`
 - [**Client**](/docs/client) — `useDbSync` for real-time cache invalidation

package/docs/content/pure-agent-apps.md

@@ -1,69 +1,96 @@
 ---
 title: "Pure-Agent Apps"
-description: "Build an agent without a heavy UI — just the agent plus a minimal observability/management surface. All the framework benefits, none of the dashboard work."
+description: "Apps where the agent is the whole product — open it, ask for what you want, and the agent does the rest."
 ---
 
 # Pure-Agent Apps
 
-Not every agent-native app needs a full SaaS-style interface. Sometimes the agent _is_ the product. A support triage agent. A daily report generator. A research bot. An email auto-responder. An ops runbook executor.
+Imagine opening an app and seeing… just a chat. No dashboard. No sidebar full of menus. No forms. You ask for what you want — "summarize my unread emails," "post the daily metrics to Slack," "find the candidates who replied last week" — and the agent goes off and does it. The output shows up in chat, in Slack, in your inbox, wherever it belongs.
 
-For these, the "app" is mostly just the agent doing work in the background. You still want a UI — but a minimal one, focused on **observability, management, and steering** rather than hand-crafted dashboards and forms.
+That's a pure-agent app. The agent _is_ the product.
 
-This is the "agents benefit from a UI even when there's no rich app around them" pattern. The hot take is "agents will replace apps." The reality is "every agent eventually needs a UI for humans to supervise, configure, and debug it." Agent-native gives you that UI for free.
+## What it feels like to use one {#user-experience}
 
-## The minimum viable UI {#minimum-ui}
+Most apps are built around a UI: a database table you browse, a form you fill, a chart you read. The agent is a sidekick.
 
-A pure-agent app ships with five surfaces, all provided by the framework — you don't build them:
+In a pure-agent app, that's flipped. The chat is the front door. You type a request; the agent takes action; you see the result. Everything else — settings, history, what's currently running — is one click away, but most of the time you don't need it.
 
-1. **Chat** — the main input. Users talk to the agent, steer it, queue tasks. (`<AgentSidebar>` or `<AgentPanel>`)
-2. **Workspace** — skills, memory (`learnings.md`), `AGENTS.md`, custom sub-agents, connected MCP servers, scheduled jobs. Customize the agent's behavior without shipping code. (Workspace tab in the sidebar)
-3. **Job history** — which scheduled jobs ran, when, whether they succeeded, what they did. (Workspace tab → `jobs/`)
-4. **Thread history** — every past conversation, each preserved with its tool calls and final output. (Chat tab)
-5. **Settings** — API keys, connected accounts, onboarding status. (Sidebar settings)
+Examples of where this works really well:
 
-Those five together are enough UI for most pure-agent use cases. No analytics dashboard. No Kanban. No forms. Just: talk to it, see what it's done, configure how it behaves.
+- **Background workers** — a triage agent that watches your inbox and labels things, a daily-report agent that posts to Slack each morning, an on-call agent that responds to alerts.
+- **One-shot helpers** — "research this company and write a one-pager," "scan my GitHub issues and tell me which ones look stale."
+- **Channel-driven assistants** — agents you mostly talk to from Slack, Telegram, email, or another agent (via [A2A](/docs/a2a-protocol)). The "app" itself is mostly a control panel.
+- **Internal tools** — an agent that knows your runbooks, your APIs, your conventions, and can act on them.
 
-## When to pick this pattern {#when-to-pick}
+The hot take is "agents will replace apps." The honest version is "agents still need a UI — for humans to supervise, configure, and steer them." Pure-agent apps give you that UI without the dashboard sprawl.
 
-Pure-agent makes sense when:
+## When this beats a traditional app {#when}
 
-- **The work happens in the background.** Scheduled jobs, webhook-triggered handlers, Slack/Telegram responders. Users rarely sit in the app.
-- **The output leaves the app.** The agent posts to Slack, sends email, writes to a third-party system. There's nothing to view in-app; the value is elsewhere.
-- **The domain is one-shot.** A research bot that returns a report. No persistent object to dashboard.
-- **You're prototyping.** Ship the agent now; add a rich UI only when you've proven users need it.
+Pick the pure-agent pattern when:
 
-Pick a full [cloneable SaaS](/docs/cloneable-saas) template instead when the app has real persistent objects (emails, events, documents, charts) users need to browse, pivot, and share.
+- **The work happens in the background.** Most of the value is created while the user isn't looking.
+- **The output leaves the app.** The agent posts to Slack, sends email, updates a third-party system. There's nothing to browse in-app — the value is elsewhere.
+- **The domain is one-shot.** Research bot, summary generator, report writer. There's no persistent object that needs a list view.
+- **You're prototyping.** Ship the agent now; add a richer UI later if it turns out users actually want one.
 
-## The minimal scaffold {#scaffold}
+If your product is built around persistent objects users browse, pivot, and share — emails, events, documents, charts — pick a [cloneable SaaS](/docs/cloneable-saas) template instead. Those have full UIs _plus_ the agent.
 
-Start from the **Starter** template:
+## What ships in the box {#minimum-ui}
+
+Every pure-agent app gets five built-in surfaces, all provided by the framework — you don't build them:
+
+1. **Chat** — the main input. Users talk to the agent, steer it, queue tasks.
+2. **Workspace** — skills, memory, instructions, custom sub-agents, connected MCP servers, scheduled jobs. Customize the agent's behavior without shipping code.
+3. **Job history** — which scheduled jobs ran, when, whether they succeeded, what they did.
+4. **Thread history** — every past conversation, each preserved with its tool calls and final output.
+5. **Settings** — API keys, connected accounts, onboarding status.
+
+Those five are usually enough. No analytics dashboard. No Kanban. No forms. Just: talk to it, see what it's done, configure how it behaves.
+
+## Why you'd pick this over "an app with an AI sidebar" {#vs-traditional}
+
+Two reasons:
+
+1. **You don't have to build the UI.** A pure-agent app skips weeks of dashboard work. The chat handles input; the framework handles supervision and history; the agent handles output.
+2. **It's channel-agnostic from day one.** The same agent that runs in your web UI also runs from Slack, Telegram, email, and other agents — because everything goes through the agent, not the UI. See [Messaging the agent](/docs/messaging) for how that works.
+
+The trade-off: pure-agent apps don't give users a "browse-everything-at-a-glance" view. If your users need that, mix patterns: start pure-agent, add a small status page or list view if you discover users want one.
+
+## Building one {#building}
+
+If you're not a developer, you can usually start with the [Dispatch template](/docs/template-dispatch) — it's a workspace-style pure-agent app with Slack/Telegram, scheduled jobs, and shared secrets out of the box.
+
+For developers who want the absolute minimum, start from the **Starter** template:
 
 ```bash
 pnpm dlx @agent-native/core create my-agent --template starter
 ```
 
-Starter gives you the six-rules architecture, the agent panel, the workspace, auth, polling, and one example action — and nothing else. Add your own actions in `actions/`, connect any MCP servers you need, write the relevant skills into the workspace, and you're done. The "UI" is the agent sidebar — which is already complete.
+Starter gives you the architecture, the agent panel, the workspace, auth, polling, and one example action — and nothing else. Add your own actions in `actions/`, connect any MCP servers you need, write the relevant skills into the workspace, and you're done.
 
-If you really want _zero_ UI except the agent, `app/routes/index.tsx` can just render `<AgentPanel defaultMode="chat" />` fullscreen. The only thing the user sees is the chat. Everything else — job history, workspace, settings — is one click away in the panel's tabs.
+If you really want _zero_ UI except the agent, `app/routes/index.tsx` can render `<AgentPanel defaultMode="chat" />` fullscreen. The only thing the user sees is the chat. Everything else — job history, workspace, settings — is one click away in the panel's tabs.
 
-## What you still get for free {#still-free}
+### What you still get for free {#still-free}
 
 Even with no custom UI, you still inherit every framework benefit:
 
-- **Actions** as agent tools + HTTP endpoints + MCP tools + A2A tools. External agents, Claude Desktop, and your own HTTP clients can drive the agent without going through the chat UI.
-- **Recurring jobs** for scheduled work — "every morning at 7 summarize my unread emails and post to Slack."
+- **Actions** as agent tools, HTTP endpoints, MCP tools, and A2A tools. External agents, Claude Desktop, and your own HTTP clients can drive the agent without going through the chat UI.
+- **Recurring jobs** for scheduled work — "every morning at 7, summarize my unread emails and post to Slack."
 - **The workspace** for per-user customization, skills, memory, MCP connections.
 - **Sub-agent delegation** via [agent teams](/docs/agent-teams).
 - **Portability** — deploys to any serverless host, any SQL database.
 - **Multi-tenant by default** — each user gets their own workspace without a dev-box.
 
-## Adding a tiny bit of UI {#tiny-ui}
+### Adding a tiny bit of UI {#tiny-ui}
 
-Most "pure-agent" apps eventually want a little bit of custom UI — not a dashboard, but maybe a status page, a job history, or a config screen. The [drop-in agent](/docs/drop-in-agent) components coexist with anything else you render. Add a single `/status` route that lists recent runs; keep everything else in the chat. That's usually enough.
+Most pure-agent apps eventually want a little custom UI — not a dashboard, but maybe a status page, a job history, or a config screen. The [drop-in agent](/docs/drop-in-agent) components coexist with anything else you render. Add a single `/status` route that lists recent runs; keep everything else in the chat. That's usually enough.
 
 ## What's next
 
+- [**Getting Started**](/docs/getting-started) — clone the Starter template
+- [**Messaging the agent**](/docs/messaging) — how users talk to the agent across web, Slack, Telegram, email
 - [**Recurring Jobs**](/docs/recurring-jobs) — scheduled prompts the agent runs on its own
+- [**Dispatch**](/docs/template-dispatch) — the workspace template that's a great starting point for pure-agent apps
 - [**Drop-in Agent**](/docs/drop-in-agent) — mounting `<AgentPanel>` fullscreen or in a sidebar
 - [**Actions**](/docs/actions) — the tools your pure-agent will call
 - [**Workspace**](/docs/workspace) — the customization surface for skills, memory, and MCP servers