experimental-ash 0.59.0 → 0.61.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # experimental-ash
 
+## 0.61.0
+
+### Minor Changes
+
+- 2e3746f: Add WebSocket channel routes via `WS()`, including compiler manifest support, Nitro websocket mounting, and runtime dispatch for custom channel integrations.
+
+## 0.60.0
+
+### Minor Changes
+
+- 72d63f2: Make runtime action tools (built-in `agent`, declared subagents, remote agents) callable from code mode. When the agent writes `await agent({ message: "..." })` in sandbox code, the QuickJS sandbox interrupts via the existing code mode interrupt mechanism, the harness parks with a `PendingRuntimeActionBatch` for child dispatch, and the sandbox replays with the child's result on resume.
+
 ## 0.59.0
 
 ### Minor Changes

package/dist/docs/public/advanced/auth-and-route-protection.mdx

@@ -4,7 +4,9 @@ description: "Protect agent routes with HTTP Basic, JWT, OIDC, and Vercel OIDC."
 url: /auth-and-route-protection
 ---
 
-Ash protects its own HTTP routes through the channel layer.
+Ash protects its own HTTP routes through the channel layer. The [Ash channel](/docs/channels/ash)
+is enabled by default and exposes the session API used by local tooling, frontend clients, and other
+HTTP API callers.
 
 Route auth and IP policy are not configured in `agent.ts` anymore. They live on the HTTP channel
 factories and helper functions instead.
@@ -30,8 +32,8 @@ These settings apply to:
 ## Generated Web Chat Auth
 
 `pnpm create experimental-ash-agent` scaffolds `agent/channels/ash.ts` from the Web Chat example.
-It permits Vercel OIDC and localhost requests and leaves end-user production auth as an explicit
-placeholder:
+Creating this file overrides the default Ash channel settings. The generated version permits Vercel
+OIDC and localhost requests and leaves end-user production auth as an explicit placeholder:
 
 ```ts
 // agent/channels/ash.ts
@@ -250,6 +252,6 @@ export default ashChannel({
 
 ## What To Read Next
 
-- [`agent.ts`](./agent-ts.md)
-- [Session Context](./session-context.md)
-- [Vercel Deployment](./vercel-deployment.md)
+- [`agent.ts`](/docs/agent-ts)
+- [Session Context](/docs/session-context)
+- [Vercel Deployment](/docs/vercel-deployment)

package/dist/docs/public/agent-ts.md

@@ -3,11 +3,11 @@ title: "agent.ts"
 description: "Configure your agent with agent.ts: model, metadata, and runtime options."
 ---
 
-`agent.ts` is the additive runtime config entrypoint for an Ash agent.
+`agent.ts` configures the runtime for an Ash agent: model, metadata, build options, and compaction.
+For the agent's behavior and surfaces, see [instructions](./advanced/context-control.md),
+[skills](./skills.md), [tools](./tools.mdx), and [channels](./channels/README.md).
 
-Put instructions in `instructions.md`. Put runtime settings in `agent.ts`.
-
-## The Main API
+## Define An Agent
 
 ```ts
 import { defineAgent } from "experimental-ash";
@@ -27,25 +27,6 @@ export default defineAgent({
 });
 ```
 
-## What Belongs Here
-
-Use `agent.ts` for:
-
-- model selection
-- metadata you want preserved in runtime traces
-- hosted-build packaging controls
-- compaction settings
-- provider-specific model options
-
-Per-tool approval (formerly "human-in-the-loop policy") lives on each tool via `needsApproval`,
-not in `agent.ts`. See [Human In The Loop](./human-in-the-loop.mdx).
-
-For OpenTelemetry configuration, use `instrumentation.ts` instead. See
-[`instrumentation.ts`](./instrumentation.md).
-
-Do not use `agent.ts` for long-form instructions. Put those in `instructions.md` (or `instructions.ts`) and
-`skills/`.
-
 ## `model`
 
 Ash accepts either:
@@ -130,27 +111,7 @@ server output instead of being bundled.
 - `model` optionally overrides the model used for compaction summaries
 
 The shared per-run workspace is configured on the sandbox, not on `agent.ts`. See
-[Workspace](./workspace.md) and [Sandboxes](./sandbox.md).
-
-## Human In The Loop
-
-Approval policy lives on individual tools via `needsApproval` in `defineTool({...})`, not on
-`agent.ts`. See [Human In The Loop](./human-in-the-loop.mdx) for the runtime flow, `input.requested`
-events, and HTTP response payloads.
-
-## Telemetry
-
-OpenTelemetry tracing is configured in `agent/instrumentation.ts`, not in `agent.ts`. See
-[`instrumentation.ts`](./instrumentation.md) for setup.
-
-## Route Auth And Network Policy
-
-`agent.ts` does not define inbound auth or IP policy anymore.
-
-Those concerns live on the HTTP channel layer instead. See:
-
-- [Auth And Route Protection](./auth-and-route-protection.mdx)
-- [Channels](./channels/README.md)
+[Workspace](./advanced/workspace.md) and [Sandboxes](./sandbox.md).
 
 ## A Good Default
 
@@ -166,9 +127,18 @@ export default defineAgent({
 
 That is enough to start. Add build and compaction settings only when you need them.
 
+## Where Other Settings Live
+
+A few adjacent concerns live in dedicated files:
+
+- Long-form instructions → [`instructions.md`](./advanced/context-control.md)
+- Per-tool approval → [Human In The Loop](./human-in-the-loop.mdx)
+- OpenTelemetry → [`instrumentation.ts`](./advanced/instrumentation.md)
+- Inbound auth → [Auth And Route Protection](./advanced/auth-and-route-protection.mdx)
+
 ## What To Read Next
 
-- [Context Control](./context-control.md)
+- [Context Control](./advanced/context-control.md)
 - [Human In The Loop](./human-in-the-loop.mdx)
-- [Workspace](./workspace.md)
-- [Auth And Route Protection](./auth-and-route-protection.mdx)
+- [Workspace](./advanced/workspace.md)
+- [Auth And Route Protection](./advanced/auth-and-route-protection.mdx)

package/dist/docs/public/channels/README.md

@@ -0,0 +1,60 @@
+---
+title: "Overview"
+description: "Deliver your agent over HTTP, Slack, Discord, GitHub, Twilio, Telegram, Microsoft Teams, and custom transports."
+url: /channels
+---
+
+Channels let Ash receive messages from external systems and deliver responses back to the same
+conversation surface. Each channel owns the platform-specific delivery details, while the runtime and
+harness still own model turns, tool execution, compaction, and session persistence.
+
+Most apps start with the Ash channel for web and local clients, then add platform channels when the
+agent should live inside a collaboration or messaging surface.
+
+## Define a channel
+
+Create a channel file under `agent/channels/` in the root agent:
+
+```text
+agent/
+  agent.ts
+  channels/
+    slack.ts
+    github.ts
+    internal-webhook.ts
+```
+
+The file stem becomes the channel id. For example, `agent/channels/internal-webhook.ts` is addressed
+as `internal-webhook`.
+
+## Built-in channels
+
+- [Ash](/docs/channels/ash) - the default HTTP session protocol used by the terminal UI, Ash client
+  integrations, and deployed web frontends.
+- [Discord](/docs/channels/discord) - Discord HTTP Interactions for slash commands, components, and modals.
+- [Slack](/docs/channels/slack) - Slack app mentions, direct messages, message delivery, typing indicators,
+  and HITL interactions.
+- [GitHub](/docs/channels/github) - GitHub App webhooks, PR context, issue and review comments,
+  and sandbox checkout.
+- [Microsoft Teams](/docs/channels/teams) - Bot Framework Activity webhooks, Adaptive Cards, and Teams
+  replies.
+- [Telegram](/docs/channels/telegram) - Telegram Bot API webhooks, replies, inline keyboards, and group
+  messages.
+- [Twilio](/docs/channels/twilio) - inbound SMS and speech-transcribed phone calls.
+
+## Need another surface?
+
+Use [Custom channels](/docs/channels/custom) when you need to expose your own HTTP or WebSocket
+endpoints, adapt an internal webhook, or connect a platform that does not have a first-class channel
+yet.
+
+## What to read next
+
+- [Ash channel](/docs/channels/ash)
+- [Slack channel](/docs/channels/slack)
+- [GitHub channel](/docs/channels/github)
+- [Telegram channel](/docs/channels/telegram)
+- [Custom channels](/docs/channels/custom)
+- [Project Layout](/docs/project-layout)
+- [TypeScript API](/docs/typescript-api)
+- [Auth And Route Protection](/docs/auth-and-route-protection)

package/dist/docs/public/channels/ash.mdx

@@ -0,0 +1,103 @@
+---
+title: "Ash"
+description: "Expose Ash's default HTTP API for local tools, frontends, and SDK clients."
+---
+
+The Ash channel exposes the framework's default HTTP API for an agent. Use it when something should
+talk to your agent over HTTP: local tooling, a [frontend client](/docs/frontend), or another
+API client that needs to start sessions, send user messages, and stream agent events.
+
+`ashChannel()` mounts Ash's canonical session routes under `/ash/v1/session*`. These routes are
+enabled by default, even when `agent/channels/ash.ts` does not exist.
+
+## When to use it
+
+- You want HTTP/API access to your agent.
+- You are using the terminal UI.
+- You are building a frontend that talks to the agent through [`useAshAgent()`](/docs/frontend/use-ash-agent)
+  or Ash's HTTP session API.
+- You want to choose the route authentication policy for the default session API.
+
+Most apps do not need much code here. Add `agent/channels/ash.ts` when you want to override the
+default Ash channel settings:
+
+```ts
+import { ashChannel } from "experimental-ash/channels/ash";
+import { localDev, vercelOidc } from "experimental-ash/channels/auth";
+
+export default ashChannel({
+  auth: [localDev(), vercelOidc()],
+});
+```
+
+## Exposed routes
+
+The Ash channel exposes the HTTP routes used to create sessions, send follow-up messages, and stream
+events from a running session:
+
+- `GET /ash/v1/health`
+- `POST /ash/v1/session`
+- `POST /ash/v1/session/:sessionId`
+- `GET /ash/v1/session/:sessionId/stream`
+
+See [Runs and Streaming](/docs/runs-and-streaming) for the route-level flow.
+
+## Authentication
+
+The `auth` option controls who can call the Ash HTTP routes. If a browser app, mobile app, or other
+client connects directly to the Ash API, add your own production authentication.
+
+The default helpers are meant for development and trusted infrastructure:
+
+- `localDev()` accepts requests during local development.
+- `vercelOidc()` lets the locally installed CLI talk to a deployed agent and lets other internal
+  Vercel deployments from your team call it.
+
+Those defaults do not give browser users or external clients protected production access. For that,
+wire the Ash channel to your app's auth system, such as Clerk, Auth.js, or your own OIDC/JWT
+verification.
+
+`pnpm create experimental-ash-agent` scaffolds an example `agent/channels/ash.ts` with a production
+auth placeholder so you can replace it before exposing the API to real users.
+
+For the full auth model and helper list, see
+[Auth and Route Protection](/docs/auth-and-route-protection).
+
+## Advanced customization
+
+Use `onMessage` to add request-specific context before the agent sees the user message, and `events`
+to observe stream events from sessions created through the Ash channel.
+
+```ts
+import { ashChannel, defaultAshAuth } from "experimental-ash/channels/ash";
+import { localDev, vercelOidc } from "experimental-ash/channels/auth";
+
+export default ashChannel({
+  auth: [localDev(), vercelOidc()],
+  onMessage(ctx, message) {
+    const callerId = ctx.ash.caller?.principalId ?? "anonymous";
+
+    return {
+      auth: defaultAshAuth(ctx),
+      context: [`HTTP caller ${callerId} sent: ${message}`],
+    };
+  },
+  events: {
+    "message.completed"(event, channel, ctx) {
+      console.log("Ash response completed", {
+        continuationToken: channel.continuationToken,
+        message: event.message,
+        sessionId: ctx.session.id,
+      });
+    },
+  },
+});
+```
+
+## Frontend clients
+
+Frontend docs cover the client side of this API:
+
+- [Frontend overview](/docs/frontend) explains the web integration options.
+- [`useAshAgent`](/docs/frontend/use-ash-agent) shows the React hook that calls the Ash channel from
+  browser UI.

package/dist/docs/public/channels/custom.mdx

@@ -0,0 +1,288 @@
+---
+title: "Custom channels"
+description: "Author custom HTTP and WebSocket channels with routes, events, metadata, continuation tokens, and file uploads."
+---
+
+Custom channels are for surfaces Ash does not ship as first-class integrations. They let you expose
+HTTP or WebSocket endpoints, parse incoming requests, start or resume sessions, observe runtime
+events, and own delivery back to your platform.
+
+## File location and identity
+
+Custom channels live in `agent/channels/` at the root agent level. Local subagents do not declare
+channels today.
+
+The channel file stem becomes the channel id, so `agent/channels/internal-webhook.ts` is addressed as
+`internal-webhook`. Channel files are module-backed; export the channel definition as the default
+export.
+
+## Main API
+
+```ts
+import { defineChannel, GET, POST } from "experimental-ash/channels";
+
+export default defineChannel({
+  routes: [
+    POST("/message", async (req, { send }) => {
+      const body = await req.json();
+      const session = await send(body.message, {
+        auth: null,
+        continuationToken: body.token,
+      });
+
+      return Response.json({ sessionId: session.id });
+    }),
+    GET("/sessions/:sessionId/stream", async (_req, { getSession, params }) => {
+      const session = getSession(params.sessionId);
+      const stream = await session.getEventStream();
+
+      return new Response(stream, {
+        headers: { "content-type": "text/event-stream" },
+      });
+    }),
+  ],
+  events: {
+    "message.completed"(event, channel, ctx) {
+      // deliver completed messages back to the surface that owns this channel
+    },
+  },
+});
+```
+
+`defineChannel({ routes, ... })` defines a channel. Routes are declared with `POST()` and `GET()`
+helpers. Each route handler receives the raw `Request` and a helpers object:
+
+- `send(message, { auth, continuationToken, state? })` - start or resume a session. Returns a
+  `Session`.
+- `getSession(sessionId)` - look up an existing session. The returned `Session` exposes
+  `getEventStream({ startIndex? })` for streaming.
+- `params` - route parameters extracted from the path pattern.
+- `waitUntil(promise)` - extend the request lifetime for background work.
+
+Event handlers like `"message.completed"` are declared under the `events` key on the config object.
+They receive `(eventData, channel, ctx)` where `channel` carries platform handles and session
+continuation operations, and `ctx` is the Ash `SessionContext`.
+
+## WebSocket routes
+
+Use `WS()` when a custom channel needs a WebSocket endpoint. The route handler runs once per upgrade
+request and returns lifecycle hooks for that connection:
+
+```ts
+import { defineChannel, WS } from "experimental-ash/channels";
+
+export default defineChannel({
+  routes: [
+    WS("/voice/ws", async (_req, { send }) => ({
+      async message(_peer, message) {
+        await send(message.text(), {
+          auth: null,
+          continuationToken: "voice-demo",
+        });
+      },
+    })),
+  ],
+});
+```
+
+`WS()` handlers receive the same helpers as HTTP route handlers: `send`, `getSession`, `receive`,
+`params`, `waitUntil`, and `requestIp`. The returned hooks are Ash-owned structural types compatible
+with Nitro/H3 websocket routing, including `upgrade`, `open`, `message`, `close`, and `error`.
+
+## Cross-channel hand-off
+
+Route handlers can start a session on a different channel via `args.receive(channel, ...)`. Use this
+when an inbound request on one channel should pivot the conversation onto another, such as an
+incident webhook that should open an investigation thread in Slack.
+
+```ts
+import { defineChannel, POST } from "experimental-ash/channels";
+import slack from "./slack.js";
+
+export default defineChannel({
+  routes: [
+    POST("/incident", async (req, args) => {
+      const incident = await req.json();
+
+      args.waitUntil(
+        args.receive(slack, {
+          message: `Investigate ${incident.reference}: ${incident.title}`,
+          target: { channelId: "C0123ABC" },
+          auth: {
+            authenticator: "incidentio",
+            principalType: "service",
+            principalId: incident.actor.id,
+            attributes: { reference: incident.reference, severity: incident.severity },
+          },
+        }),
+      );
+
+      return new Response("ok");
+    }),
+  ],
+});
+```
+
+Semantics:
+
+- The target channel's authored `receive(input, { send })` hook owns the continuation-token format
+  and initial state. Callers supply only `{ message, target, auth }`.
+- `auth` flows through to `session.auth.initiator` so the target's event handlers and the agent's
+  tools can read who started the session.
+- Calling `args.receive(...)` does not also start a session on the current channel. The inbound
+  channel's response is whatever the route handler returns explicitly.
+- The first argument is the target channel module's default export. Import it directly from
+  `agent/channels/<name>.ts`. Identity is matched by reference.
+
+## Channel metadata
+
+Channels can project a subset of their adapter state as metadata available to instrumentation
+resolvers, dynamic tool resolvers, and dynamic skill/instruction resolvers. Define a
+`metadata(state)` function on the channel config:
+
+```ts
+import { defineChannel, POST } from "experimental-ash/channels";
+
+export default defineChannel({
+  state: {
+    topic: null as string | null,
+    contextMessages: [] as string[],
+    internalCounter: 0,
+  },
+
+  metadata(state) {
+    return {
+      topic: state.topic,
+      contextMessages: state.contextMessages,
+    };
+  },
+
+  routes: [
+    POST("/start", async (req, { send }) => {
+      const body = await req.json();
+      await send(body.message, {
+        auth: null,
+        continuationToken: body.token,
+        state: { topic: body.topic, contextMessages: body.context, internalCounter: 0 },
+      });
+
+      return new Response("ok");
+    }),
+  ],
+  events: {
+    "turn.started"(_event, ctx) {
+      ctx.state.internalCounter += 1;
+    },
+  },
+});
+```
+
+The projection is re-evaluated whenever adapter state changes after channel event handlers run.
+Dynamic tool resolvers read it via `ctx.channel.metadata` and narrow it with `isChannel`. See
+[Dynamic Tools - Channel Metadata](/docs/tools#channel-metadata) for the full consumption pattern.
+
+When a parent agent dispatches a subagent, the framework forwards the parent's channel metadata
+projection to the child. The same `metadata(state)` projector also serves instrumentation metadata
+resolvers.
+
+## Continuation tokens
+
+Each call to `send(message, { auth, continuationToken, state? })` from a channel route addresses a
+session by its channel-local raw token. The framework prepends the channel name, derived from the
+file stem under `agent/channels/`, before handing the token to the runtime.
+
+```ts
+import { slackContinuationToken } from "experimental-ash/channels/slack";
+import { twilioContinuationToken } from "experimental-ash/channels/twilio";
+
+slackContinuationToken("C0123ABC", "1800000000.001234"); // "C0123ABC:1800000000.001234"
+twilioContinuationToken("+15551234567", "+15557654321"); // "+15551234567:+15557654321"
+```
+
+Custom channels write their own function that joins the identity fields. The framework does not
+derive anything for you; the channel owns its token format.
+
+When the identity that should address a session is not known until later, the channel can re-key the
+parked session by calling `ctx.session.setContinuationToken(...)` from a handler. Pass the
+channel-local raw token; the runtime preserves the current channel namespace.
+
+```ts
+import { defineChannel } from "experimental-ash/channels";
+
+defineChannel<{ ref: string | null }>({
+  state: { ref: null },
+  context(state, session) {
+    return {
+      state,
+      registerAnchor(ref: string) {
+        state.ref = ref;
+        session.setContinuationToken(ref);
+      },
+    };
+  },
+  events: {
+    "message.completed"(_event, ctx) {
+      if (!ctx.state.ref) ctx.registerAnchor(mintRef());
+    },
+  },
+  routes: [
+    /* ... */
+  ],
+});
+```
+
+The workflow runtime disposes the current park hook at the next step boundary and registers a new
+one at the new token. Inbound deliveries already addressed to the old token are dropped, so
+coordinate with your senders to use the new token.
+
+## File uploads
+
+`send()` accepts `string | UserContent`. To include file attachments, pass a `UserContent` array
+mixing text and file parts:
+
+```ts
+await send(
+  [
+    { type: "text", text: body.message },
+    { type: "file", data: imageBytes, mediaType: "image/png" },
+  ],
+  { auth, continuationToken },
+);
+```
+
+For platforms like Slack where files are behind authenticated URLs, put a `URL` object in
+`FilePart.data` and declare `fetchFile` on the channel config:
+
+```ts
+defineChannel({
+  fetchFile(url) {
+    if (!url.startsWith("https://files.slack.com/")) return null;
+    return fetch(url, { headers: { authorization: `Bearer ${token}` } })
+      .then((r) => r.arrayBuffer())
+      .then((b) => ({ bytes: Buffer.from(b) }));
+  },
+
+  routes: [
+    POST("/webhook", async (req, { send }) => {
+      await send(
+        [
+          { type: "text", text: message.text },
+          ...message.attachments.map((a) => ({
+            type: "file" as const,
+            data: new URL(a.url),
+            mediaType: a.mediaType,
+          })),
+        ],
+        { auth, continuationToken, state },
+      );
+    }),
+  ],
+});
+```
+
+The `URL` object survives the queue boundary as a string and is reconstituted inside the workflow
+step. The staging pipeline calls `fetchFile(url)`: return bytes to stage the file to the sandbox, or
+return `null` to let the URL pass through to the model provider.
+
+The framework handles staging bytes to the sandbox, enforcing upload policy, hydrating files for the
+model call, and reconstituting `URL` objects after queue serialization.

package/dist/docs/public/channels/discord.mdx

@@ -1,10 +1,8 @@
 ---
-title: "Discord channel setup"
+title: "Discord"
 description: "Create a Discord-backed Ash channel for HTTP Interactions."
 ---
 
-# Discord Channel Setup
-
 The Discord channel accepts HTTP Interactions: slash/application commands, message components, and
 modal submissions. It verifies Discord's Ed25519 signature headers before parsing the request,
 acknowledges commands immediately, and continues Ash work in the background.

package/dist/docs/public/channels/github.md

@@ -1,5 +1,5 @@
 ---
-title: "GitHub channel setup"
+title: "GitHub"
 description: "Create a GitHub App-backed Ash channel with automatic PR context and sandbox checkout."
 type: integration
 related:

package/dist/docs/public/channels/meta.json

@@ -0,0 +1,3 @@
+{
+  "pages": ["README", "ash", "discord", "slack", "github", "teams", "telegram", "twilio", "custom"]
+}

package/dist/docs/public/channels/slack.mdx

@@ -1,5 +1,5 @@
 ---
-title: "Slack channel setup"
+title: "Slack"
 description: "Create a Slack-backed Ash channel with Vercel Connect."
 type: integration
 related:
@@ -255,6 +255,34 @@ export default slackChannel({
 `context` strings are appended as user messages to `session.history` before the delivery message.
 They persist across the session and are visible to the model on all subsequent turns.
 
+### Thread Anchoring
+
+When a Slack session starts without a `threadTs`, such as from `args.receive(slack, ...)` or a
+schedule, the channel auto-anchors on the first agent post. That message becomes the thread root, and
+subsequent posts, typing indicators, and inbound mentions in that thread resume the same Ash session.
+
+Pass `initialMessage` when you want a structured anchor card to land before the agent runs:
+
+```ts
+import { Card, CardText } from "experimental-ash/channels/slack";
+
+await args.receive(slack, {
+  message: "Begin investigation",
+  target: {
+    channelId: "C0123ABC",
+    initialMessage: {
+      card: Card({ children: [CardText("Investigation Thread for INC-42")] }),
+      fallbackText: "Investigation Thread for INC-42",
+    },
+  },
+  auth,
+});
+```
+
+`threadTs` and `initialMessage` are mutually exclusive: pass `threadTs` to join an existing thread,
+or `initialMessage` to anchor a new one. With neither, the first agent post anchors the thread
+automatically.
+
 ### Direct Messages
 
 Add `onDirectMessage` alongside `onAppMention` to handle 1:1 DMs:

package/dist/docs/public/channels/teams.mdx

@@ -1,10 +1,8 @@
 ---
-title: "Microsoft Teams channel setup"
+title: "Microsoft Teams"
 description: "Create a Microsoft Teams-backed Ash channel with the Bot Framework Activity protocol."
 ---
 
-# Microsoft Teams Channel Setup
-
 The Teams channel accepts Bot Framework Activity POSTs from Microsoft Teams, verifies Bot
 Connector bearer JWTs, dispatches message activities to Ash, renders HITL prompts as Adaptive
 Cards, and delivers agent responses through the Bot Framework Connector REST API.

package/dist/docs/public/channels/telegram.mdx

@@ -1,10 +1,8 @@
 ---
-title: "Telegram channel setup"
+title: "Telegram"
 description: "Create a Telegram-backed Ash channel for bot webhooks, replies, HITL, and attachments."
 ---
 
-# Telegram Channel Setup
-
 The Telegram channel accepts Telegram Bot API webhooks. It verifies Telegram's
 `X-Telegram-Bot-Api-Secret-Token` header before parsing the update, dispatches private messages and
 addressed group messages, and sends default replies through `sendMessage`.