eve 0.68.0 → 0.70.0

package/dist/src/vue/use-eve-agent.d.ts

@@ -3,7 +3,7 @@ import type { UserContent } from "ai";
 import { type EveAgentStoreCallbacks, type EveAgentStoreSnapshot, type EveAgentStoreStatus, type PrepareSend } from "#client/eve-agent-store.js";
 import type { EveAgentReducer } from "#client/reducer.js";
 import type { ClientSession } from "#client/session.js";
-import { type EveMessageData } from "#client/message-reducer.js";
+import type { ConversationState } from "#client/conversation-state.js";
 import type { MessageStreamEvent } from "#protocol/message.js";
 import type { CancelSessionResult, ClientAuth, HeadersValue, RespondTurnOptions, SendTurnOptions, ClientSessionState } from "#client/types.js";
 export type { PrepareSend };
@@ -29,6 +29,8 @@ export interface UseEveAgentReturn<TData> {
     readonly cancel: () => Promise<CancelSessionResult>;
     /** Projected state: the reducer folds every stream event into this value. */
     readonly data: ComputedRef<TData>;
+    /** Canonical session state, regardless of the chosen data reducer. */
+    readonly conversation: ComputedRef<ConversationState>;
     /** Last transport-level error, or `undefined` when healthy. */
     readonly error: ComputedRef<Error | undefined>;
     /** Raw server events from this session (authoritative stream). */
@@ -100,12 +102,14 @@ export interface UseEveAgentOptions<TData> extends EveAgentStoreCallbacks<TData>
      * @default true
      */
     readonly optimistic?: boolean;
+    /** Follow each subagent call's session into `conversation.agents` while mounted. @default false */
+    readonly followSubagents?: boolean;
     /** Prewarm an owned session on mount and after reset. @default false */
     readonly prewarm?: boolean;
     /**
      * Projects stream events into `TData`.
      *
-     * @default defaultMessageReducer()
+     * @default conversationReducer
      */
     readonly reducer?: EveAgentReducer<TData>;
     /** Replay the attached durable session after mount. Requires `initialSession` or `session`. */
@@ -117,7 +121,7 @@ export interface UseEveAgentOptions<TData> extends EveAgentStoreCallbacks<TData>
      */
     readonly session?: ClientSession;
 }
-export declare function useEveAgent(options?: UseEveAgentOptions<EveMessageData>): UseEveAgentReturn<EveMessageData>;
+export declare function useEveAgent(options?: UseEveAgentOptions<ConversationState>): UseEveAgentReturn<ConversationState>;
 export declare function useEveAgent<TData>(options: UseEveAgentOptions<TData> & {
     readonly reducer: EveAgentReducer<TData>;
 }): UseEveAgentReturn<TData>;

package/dist/src/vue/use-eve-agent.js

@@ -1,3 +1,3 @@
-import { t as useEveAgent } from "../chunks/use-eve-agent-D4HVZBjn.js";
+import { t as useEveAgent } from "../chunks/use-eve-agent-CJQeE7-t.js";
 
 export { useEveAgent };

package/docs/agent-config.md

@@ -21,7 +21,7 @@ For a static AI Gateway model ID, you can make the same source change from the
 project root with `eve set model anthropic/claude-opus-5.5` or from the local
 dev TUI with `/model anthropic/claude-opus-5.5`.
 
-The root `agent.ts` can be omitted when no runtime config is needed. eve then selects its default `agent.ts` source at the same slot, configured with `spacexai/grok-4.7`; authoring the file replaces that source.
+The root `agent.ts` can be omitted when no runtime config is needed. eve then selects its default `agent.ts` source at the same slot, configured with `openai/gpt-6-luna-fast` and `reasoning: "high"`; authoring the file replaces that source.
 When `agent.ts` is present, `model` is required.
 
 A config that selects a static Gateway model is compile-only. A config that contains a dynamic model or a direct-provider `LanguageModel` remains a runtime entry because eve must resolve that authored value while the agent runs. See [Authored module lifecycle](./reference/typescript-api#authored-module-lifecycle).
@@ -122,6 +122,8 @@ selected for that model call.
 
 ## Reasoning effort
 
+In an authored `agent.ts` with a static model, omitting `reasoning` uses the provider's default.
+
 Set `reasoning` to control the model's reasoning effort through AI SDK's
 provider-agnostic option:
 
@@ -213,16 +215,37 @@ not tool or infrastructure spend. It uses the cost reported with each model
 step; AI Gateway supplies this value, while model steps without reported cost
 do not add to the limit. Set any usage limit to `false` to uncap that axis.
 
-Delegated subagent sessions have no fixed default. Each child receives a
-share of the delegating parent's remaining quota at dispatch time — the
-remainder in the current budget window split evenly across the batch's local
-subagent calls — and a completed child's usage counts against the parent's
-quota. Token-cost budgets follow the same rules, including splitting the
-remaining US-dollar budget across a batch and adding completed child cost back
-to the parent. Approving a continuation opens a fresh parent window for later
-child grants without erasing lifetime usage. An authored child limit applies
-only when it is tighter than the parent's grant; an uncapped parent delegates
-uncapped children.
+Delegated subagent sessions have no fixed default. Each child receives a share
+of the delegating parent's remaining quota when it starts: the remainder in
+the current budget window split evenly across the agent tasks that one model
+step starts. A session that a workflow tool opens with `ctx.agent` receives
+the share of the model step that called the tool, or the whole remainder when
+that step starts no agent tasks; eve does not divide that share among several
+sessions one call opens. A child keeps its grant for its whole session,
+including turns that later calls with `taskId` start. Remote agent tasks count
+toward the split but receive no grant: they run under their own deployment's
+limits.
+
+A child's usage, including what the child's own subagents spent, counts
+against the parent's quota. An agent task's usage counts with each reply it
+sends. A turn it doesn't reply to, such as one a cancel stopped, counts with
+the next reply, or when the turn ends if no call waits for a reply. Sessions
+that any other `serve` workflow tool opens with `ctx.agent` count the same
+way; those of an `execute` or `task` tool count when the tool finishes. Remote
+agents' reported usage counts the same way. Later children draw from what
+remains, and the parent's own limit and continuation prompt include delegated
+spend. Token-cost budgets follow the same rules, including splitting the
+remaining US-dollar budget and adding child cost back to the parent. Approving
+a continuation opens a fresh parent window for later child grants without
+erasing lifetime usage. An authored child limit applies only when it is
+tighter than the parent's grant; an uncapped parent delegates uncapped
+children.
+
+Some delegated usage doesn't count against the parent: a `ctx.agent` turn
+still running when its workflow tool finishes or is cancelled; the `ctx.agent`
+usage of an `execute` tool whose parent turn is cancelled while it waits; and
+what a cancelled agent task's own subagents spend after the task reports its
+cancelled turn, until the task's next reply.
 
 ## Workflow world
 
@@ -288,7 +311,7 @@ calls and inline tool executions can run again. That can repeat provider costs,
 events, and side effects. Use stable idempotency keys for non-idempotent tools.
 
 eve ends a batch before it waits for input, authorization, or blocking
-coordination, and before it acknowledges a background task. A batch can also
+coordination. A batch can also
 end below the configured ceiling when the turn completes or steering arrives.
 Before assistant output begins, steering can interrupt pending model generation.
 Executing tools finish safely before the batch yields and applies the correction.
@@ -321,7 +344,7 @@ export default defineAgent({
 This applies to every run that owns the session, including successor owners
 started after a deployment handoff, and to the run that collects session
 activity. Runs eve starts for other purposes keep the world's default: session
-timeouts, background tasks, and [workflow tools](./tools/workflows).
+timeouts and [workflow tools](./tools/workflows).
 
 The value applies per agent. A [subagent](./subagents) that runs its own session
 uses its own value, unlike `experimental.workflow.world`, which is root-only.

package/docs/channels/chat-sdk.mdx

@@ -51,7 +51,7 @@ bot.onSubscribedMessage(async (thread: Thread, message: Message) => {
 export default channel;
 ```
 
-`adapters` is a map of adapter name to adapter instance; each entry mounts its own webhook (see below). `state` takes any Chat SDK state adapter: `createMemoryState()` is fine for local development, but use a durable adapter (Redis, Upstash, etc.) in production so thread subscriptions and inbound deduplication survive restarts. `send` accepts a plain string, an AI SDK `UserContent` array, or a `SendPayload`, and must be called from inside a Chat SDK handler — it dispatches the turn on the webhook that is currently running.
+`adapters` is a map of adapter name to adapter instance; each entry mounts its own webhook (see below). `state` takes any Chat SDK state adapter: `createMemoryState()` is fine for local development, but use a durable adapter (Redis, Upstash, etc.) in production so thread subscriptions and inbound deduplication survive restarts. `send` accepts a plain string or an AI SDK `UserContent` array, and must be called from inside a Chat SDK handler — it dispatches the turn on the webhook that is currently running.
 
 Deploy once the channel file is in place:
 
@@ -96,7 +96,7 @@ You choose which Chat SDK events start a turn by registering handlers on `bot` a
 - `bot.onSubscribedMessage(thread, message)` fires on subsequent messages in a subscribed thread.
 - `bot.onAction`, `bot.onReaction`, and `bot.onSlashCommand` are available for adapters that emit them.
 
-`send(input, options)` starts or resumes the eve session. The `thread` you pass determines the continuation token and the persisted channel state, so replies land back on the originating thread:
+`send(message, options)` starts or resumes the eve session. The `thread` you pass determines the continuation token and the persisted channel state, so replies land back on the originating thread:
 
 ```ts
 bot.onNewMention(async (thread, message) => {
@@ -104,7 +104,18 @@ bot.onNewMention(async (thread, message) => {
 });
 ```
 
-`options` accepts `{ thread, auth?, title?, callback?, adapterName?, turnPolicy? }`. `title` sets the eve session's display title without changing the model message; `auth` attaches an authenticated principal to the turn.
+`options` accepts `thread` and `adapterName`, plus the channel send options `auth`, `context`, `outputSchema`, `title`, `callback`, and `turnPolicy`. `title` sets the eve session's display title without changing the model message; `auth` attaches an authenticated principal to the turn. `auth` defaults to `null`.
+
+To answer pending input requests from a handler you render yourself, call `respond(inputResponses, { thread, auth?, context? })`. Like a channel's `respond()`, it never creates a session. This example answers a custom button whose `value` carries the eve request id:
+
+```ts
+export const { bot, channel, send, respond } = chatSdkChannel({/* ... */});
+
+bot.onAction("approve_deploy", async (event) => {
+  if (!event.thread || !event.value) return;
+  await respond([{ requestId: event.value, optionId: "approve" }], { thread: event.thread });
+});
+```
 
 ### Steering
 
@@ -168,7 +179,7 @@ chatSdkChannel({
 
 ### Human-in-the-loop (HITL)
 
-HITL prompts render as a Chat SDK `Card` with buttons. Button clicks resume the parked session automatically — the channel wires `bot.onAction` for you. Change the action-id prefix with `inputActionPrefix` (default `eve_input:`) if your app already uses it, and provide `resolveInputAuth` to carry user or tenant auth across the resume:
+HITL prompts render as a Chat SDK `Card` with buttons. Button clicks resume the parked session automatically — the channel wires `bot.onAction` to `respond` for you. Change the action-id prefix with `inputActionPrefix` (default `eve_input:`) if your app already uses it, and provide `resolveInputAuth` to carry user or tenant auth across the resume:
 
 ```ts
 chatSdkChannel({

package/docs/channels/custom.mdx

@@ -3,7 +3,7 @@ title: "Custom Channels"
 description: "Author custom HTTP and WebSocket channels with routes, events, metadata, continuation tokens, and file uploads."
 ---
 
-When eve doesn't ship a channel for your surface, you build one. Custom channels expose HTTP or WebSocket endpoints, parse incoming requests, start or resume sessions, observe runtime events, and own delivery back to your platform.
+Build a custom channel to connect an HTTP or WebSocket endpoint to your agent. It can host a conversation or pass incoming events to another channel.
 
 ## File location and identity
 
@@ -74,6 +74,15 @@ the exact session, while `channel.continuation` exposes the current address and
 receives only `(eventData, channel)` because it runs outside session context;
 its event data contains `sessionId` directly.
 
+A channel that renders questions and approvals from `input.requested` can handle
+`input.resolved` to learn when each request ends, however it ended: answered from
+the channel, answered by a plain-text reply, or withdrawn. A request that a
+workflow tool run relays, from its own `ctx.ask()` or from a session it opened
+with `ctx.agent`, also resolves as `cancelled` when that run ends before anyone
+answers. Every request relayed from a task, workflow tool call, or subagent does
+the same when the turn is cancelled. Each resolution carries the `requestId` and
+an `outcome` such as `answered`, `approved`, or `cancelled`.
+
 `channel.continuation.token` is always the channel-local address accepted by
 `from()`, `resolveSession()`, and `alias()`. Framework namespace prefixes are not
 part of the authored channel API.
@@ -131,6 +140,8 @@ Message sends use the channel's `turnPolicy`, which defaults to `"steer"`. Befor
 
 A sent delivery can interrupt generation before your `deliver` hook runs. If the hook ignores the correction, eve resumes the original request with its original auth, delivery provenance, and channel state. Filter events before `send(...)` when they should never interrupt generation.
 
+Every `send()` and `respond()` delivery passes its `state` option to your channel's `deliver(payload, channel)` hook as `payload.state`, including deliveries to an existing session. Use it for values that belong to one delivery, such as the author of a message. The hook decides what to merge into `channel.state`; eve seeds `channel.state` from `state` only when `send()` creates the session.
+
 Configure `turnPolicy: "queue"` on `defineChannel(...)` when messages should wait for the active turn to finish, or override one send:
 
 ```ts
@@ -155,6 +166,58 @@ Attaching does no lookup. The first operation reports whether the ID is active.
 Call `resolveSession(address)` only when you explicitly need to snapshot an
 address's current owner as a fixed handle.
 
+## Wrap an existing channel's routes
+
+A channel value can be spread into a new object with replaced `routes`. eve keeps the channel's adapter, events, and build metadata (such as the Slack app manifest) on the spread copy, so `{ ...channel, routes }` compiles and runs like the original.
+
+The built-in Slack, Teams, and Telegram channels, and the Chat SDK bridge's `send`, hand every inbound message to `from(address).send(message, options)`. A route wrapper that replaces `send` on the source returned by `from(address)` therefore sees each inbound message, and a rejected delivery reaches the wrapper as an error:
+
+```ts title="agent/channels/slack.ts"
+import type { RouteHandlerArgs } from "eve/channels";
+import { slackChannel, type SlackChannelState } from "eve/channels/slack";
+
+const slack = slackChannel();
+
+function reportFailedDeliveries(
+  args: RouteHandlerArgs<SlackChannelState>,
+): RouteHandlerArgs<SlackChannelState> {
+  return {
+    ...args,
+    from(address) {
+      const source = args.from(address);
+      return {
+        ...source,
+        async send(message, options) {
+          try {
+            return await source.send(message, options);
+          } catch (error) {
+            console.error("Slack delivery failed", { address, error });
+            throw error;
+          }
+        },
+      };
+    },
+  };
+}
+
+const channel: typeof slack = {
+  ...slack,
+  routes: slack.routes.map((route) =>
+    route.transport === "websocket"
+      ? route
+      : {
+          ...route,
+          handler: (request: Request, args: RouteHandlerArgs<SlackChannelState>) =>
+            route.handler(request, reportFailedDeliveries(args)),
+        },
+  ),
+};
+
+export default channel;
+```
+
+Keep each route's `method` and `path` unless you mean to move the endpoint.
+
 ## Operation semantics
 
 - `cancel` cooperatively stops the active turn. Confirm it with `turn.cancelled`
@@ -232,45 +295,54 @@ The bridge server does not listen on its own port. It receives only upgrade even
 
 ## Cross-channel hand-off
 
-Route handlers can start or resume an agent session on a different channel via `ctx.to(channel, target).send(message, options)`. This is an agent hand-off: the message becomes turn input and invokes the model on the destination channel. Use it when an inbound request should pivot the conversation, such as an incident webhook that opens an investigation thread in Slack.
+Use `ctx.to(channel, target).send(message, { auth })` in a route handler to start or resume a conversation on another channel. The agent runs and replies on the destination channel. The hand-off doesn't start a session on the source channel, which returns only its HTTP response.
 
-To post a provider notification without starting an agent turn, call the destination provider's API instead. If that notification must survive process failures, use an application-owned outbox; see [Durable cross-channel notifications](../patterns/durable-cross-channel-notifications).
+This webhook filters incoming events and asks the agent to investigate in Slack. Import the destination channel's default export; `verifyAndParseEvent` is a helper you implement in your application.
 
-```ts
+```ts title="agent/channels/intake.ts"
 import { defineChannel, POST } from "eve/channels";
+
+import { verifyAndParseEvent } from "../lib/inbound-events";
 import slack from "./slack";
 
 export default defineChannel({
   routes: [
-    POST("/incident", async (req, ctx) => {
-      const incident = await req.json();
+    POST("/intake/events", async (req, ctx) => {
+      const event = await verifyAndParseEvent(req);
+      if (!event) return new Response("unauthorized", { status: 401 });
+      if (event.kind !== "actionable") return new Response("ok");
 
       ctx.waitUntil(
         ctx
           .to(slack, { channelId: "C0123ABC" })
-          .send(`Investigate ${incident.reference}: ${incident.title}`, {
+          .send(`Investigate ${event.reference}: ${event.summary}`, {
             auth: {
-              authenticator: "incidentio",
+              authenticator: "intake",
               principalType: "service",
-              principalId: incident.actor.id,
-              attributes: { reference: incident.reference, severity: incident.severity },
+              principalId: event.source,
+              attributes: {},
             },
           }),
       );
-
       return new Response("ok");
     }),
   ],
 });
 ```
 
-Semantics:
+Before sending:
+
+- Verify the provider's signature and validate the payload, including size limits. Derive `event.source` from the verified sender, not an untrusted payload field.
+- Filter out events that should not reach the agent.
+- Deduplicate retried events in your application if duplicates would cause unwanted sessions or posts. `send(...)` does not deduplicate them.
+
+The supplied `auth` identifies who started the session, available to tools and event handlers as `session.auth.initiator`.
+
+The destination's `receive` hook defines the target fields and how they map to a session. See [Slack proactive sessions](./slack#proactive-sessions) for its target options. To let people continue the conversation, configure the destination's inbound handlers to accept follow-ups.
+
+`ctx.to(...)` is a route-handler API, not a method on every platform callback. [Handler-form schedules](../schedules#handler-form-run) provide the same operation as `to(...)`.
 
-- The target channel's authored `receive(input, { from })` hook owns the continuation-token format and initial state. Callers supply the target to `to(...)`, then the message and auth to `send(...)`.
-- `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 `ctx.to(...).send(...)` does not also start a session on the current channel. The inbound channel's response is whatever the route handler returns explicitly.
-- `send(...)` is not a direct provider-message API. It supplies input to the agent on the destination channel.
-- The first argument is the target channel module's default export. Import it directly from `agent/channels/<name>.ts`. Identity is matched by reference.
+For notifications that don't need an agent turn, use the platform's API instead. See [Durable cross-channel notifications](../patterns/durable-cross-channel-notifications) when those posts also need retries.
 
 ## Channel metadata
 

package/docs/channels/eve.mdx

@@ -103,7 +103,7 @@ Stream a session as newline-delimited JSON from `GET /eve/v1/session/:sessionId/
 
 ### Cancel a turn
 
-Post to `/eve/v1/session/:sessionId/cancel` to request cancellation of the active turn. You can include the observed `turnId` to keep a late request from cancelling a newer turn. Include `tasks: true` to also cancel every background task owned by the session, including while the session is parked. Cancellation is asynchronous; confirm the turn boundary on the stream as `turn.cancelled` followed by `session.waiting`, and inspect task state in a later turn to confirm task cancellation.
+Post to `/eve/v1/session/:sessionId/cancel` to request cancellation of the active turn. You can include the observed `turnId` to keep a late request from cancelling a newer turn. Cancellation is asynchronous; confirm the turn boundary on the stream as `turn.cancelled` followed by `session.waiting`.
 
 See [Cancel the in-flight turn](../concepts/sessions-runs-and-streaming#cancel-the-in-flight-turn) for response statuses, HTTP status codes, subagent cancellation, and race behavior.
 

package/docs/channels/mcp.mdx

@@ -187,7 +187,7 @@ The invocation response is discriminated by `status`:
 - `working`: work is active; continue polling according to `pollAfterMs`.
 - `input_required`: present `inputRequests`, then send the complete answer batch through `agent_update`. A successful update returns the current invocation state.
 - `authorization_required`: present the returned sign-in URL, user code, or instructions. The connection callback resumes the invocation automatically; continue polling.
-- `completed`: the agent's turn settled. Consume the optional `result`: the final assistant message.
+- `completed`: the agent's turn settled, after any [tasks](/docs/tools/workflows#run-calls-as-tasks-task) it started finished. Consume the optional `result`: the final assistant message.
 - `failed`: inspect the structured `error`.
 - `cancelled`: cancellation reached a terminal state.
 

package/docs/channels/overview.mdx

@@ -3,15 +3,23 @@ title: "Overview"
 description: "How users reach your agent: the channel contract, the base eve HTTP channel, and authoring custom channels."
 ---
 
-A channel is the edge adapter between a platform and your agent. It does three things:
+A channel connects a platform to your agent. For conversations, it:
 
-- Normalizes platform input into a user message.
-- Owns the channel-local address that maps a platform conversation to its current durable session.
-- Decides delivery, meaning how, where, and whether a response goes back.
+- Converts incoming messages into agent input.
+- Maps each platform conversation to an eve session.
+- Decides how, where, and whether to deliver replies.
+
+A channel can also receive events and pass them to another channel, without starting a conversation of its own.
 
 eve ships a base HTTP channel plus first-class platform channels, and you can author your own. Browse the full set in the [Integrations](/integrations) gallery and choose the Channels filter.
 
-After a channel normalizes input, eve runs the same agent runtime regardless of where the message came from. Tools and instructions do not need channel-specific logic.
+After a channel dispatches a message, eve runs the same agent runtime regardless of where the event came from. Tools and instructions do not need channel-specific logic.
+
+## Choose where the conversation lives
+
+The agent doesn't have to reply where an event arrived. A webhook, for example, can start a conversation in a team chat without sending an agent reply to the webhook's source.
+
+Use a [cross-channel hand-off](./custom#cross-channel-hand-off) when the conversation belongs elsewhere. The destination channel handles the session, replies, and follow-up messages. To post a notification without running the agent, use the platform's API instead.
 
 ## Audience
 
@@ -72,57 +80,7 @@ The eve channel is the framework's default HTTP session API, the routes the term
 
 ## Custom channels
 
-When eve doesn't ship a channel for your surface, build one with `defineChannel` from `eve/channels`. A custom channel declares route handlers (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `WS`), an `events` map, and uses `send(address, input)` to start or resume a session. See [Custom channels](./custom) for the full walkthrough, including WebSocket routes, cross-channel agent hand-off, channel metadata, address tokens, and file uploads.
-
-A cross-channel `send(...)` supplies input to the agent and invokes the model on the destination channel. eve does not currently provide a direct cross-channel provider-message queue. To post without starting a turn, use the provider API. See [Durable cross-channel notifications](../patterns/durable-cross-channel-notifications) when delivery also needs application-managed retries and deduplication.
-
-## Background task results
-
-Pass `taskDeliveryPolicy` to `send(...)` to choose how the session reports background results:
-
-- `"auto"` (default for new channel sessions): ready results can invoke the parent while other tasks continue. The parent reports results that are useful independently and stays silent when a useful answer needs unfinished work.
-- `"cohort"`: wait for overlapping tasks to settle, then deliver their terminal outcomes together.
-
-```ts title="agent/channels/reports.ts"
-import { defineChannel, POST } from "eve/channels";
-import { localDev, routeAuth } from "eve/channels/auth";
-
-export default defineChannel({
-  routes: [
-    POST("/reports", async (request, { from }) => {
-      const auth = await routeAuth(request, localDev());
-      if (auth instanceof Response) return auth;
-      const session = await from("daily-report").send("Prepare the daily reports.", {
-        auth,
-        taskDeliveryPolicy: "cohort",
-      });
-      return Response.json({ sessionId: session.id });
-    }),
-  ],
-});
-```
-
-The option is available on channel-local `from(...).send(...)`, cross-channel
-`to(...).send(...)`, fixed-session `send(...)`, Chat SDK `bridge.send(...)`, and client
-sends. An explicit value
-updates the session's policy, including pending background tasks; later sends that
-omit it preserve that policy. A cross-channel send carries its setting through the
-receiver's `from(...).send(...)` unless that call supplies an explicit value.
-
-[Schedules](../schedules#background-task-results) default new sessions to `"cohort"`.
-A schedule handler can pass `taskDeliveryPolicy: "auto"` to `send(...)` to override
-that default. Child sessions use their own policy.
-
-With `"auto"`, a model call may finish without a user-visible message. Results
-already queued from the same cohort may share a turn. Each reporting turn receives
-the whole cohort, including pending tasks and available outputs, so previously
-withheld results remain available for a later combined report.
-
-Input requests and explicit task messages remain eligible for delivery under
-either policy. Failure and cancellation update task state immediately; their
-automatic reports follow the selected policy. User messages follow `turnPolicy`.
-See [Completion batching](../subagents#completion-batching) for cohort membership
-and result ordering.
+Build a channel with `defineChannel` from `eve/channels` when you need your own HTTP or WebSocket endpoint. Its routes can start conversations on that channel or hand work to another one. See [Custom channels](./custom) for examples and the authoring API.
 
 ## Relationship to the Chat SDK