agents 0.22.0 → 0.23.0

package/dist/workflows.d.ts

@@ -1,26 +1,26 @@
 import {
-  At as WorkflowRejectedError,
-  Ct as WorkflowErrorCallback,
-  Dt as WorkflowPage,
-  Et as WorkflowInfo,
-  Mt as WorkflowTrackingRow,
-  Ot as WorkflowProgressCallback,
-  St as WorkflowCompleteCallback,
-  Tt as WorkflowEventPayload,
-  _t as RunWorkflowOptions,
+  Ct as WorkflowProgressCallback,
+  Dt as WorkflowTrackingRow,
+  Et as WorkflowStatus,
+  St as WorkflowPage,
+  Tt as WorkflowRejectedError,
+  _t as WorkflowCompleteCallback,
+  bt as WorkflowEventPayload,
   c as Agent,
-  ft as AgentWorkflowParams,
-  gt as DefaultProgress,
-  ht as ApprovalEventPayload,
-  jt as WorkflowStatus,
-  kt as WorkflowQueryCriteria,
-  lt as AgentWorkflowEvent,
-  mt as AgentWorkflowStep,
-  vt as WaitForApprovalOptions,
-  wt as WorkflowEventCallback,
-  xt as WorkflowCallbackType,
-  yt as WorkflowCallback
-} from "./agent-routing-CnkaHb-v.js";
+  dt as DefaultProgress,
+  ft as RunWorkflowOptions,
+  gt as WorkflowCallbackType,
+  it as AgentWorkflowEvent,
+  lt as AgentWorkflowStep,
+  mt as WorkflowCallback,
+  pt as WaitForApprovalOptions,
+  st as AgentWorkflowParams,
+  ut as ApprovalEventPayload,
+  vt as WorkflowErrorCallback,
+  wt as WorkflowQueryCriteria,
+  xt as WorkflowInfo,
+  yt as WorkflowEventCallback
+} from "./agent-routing-DE5zmCQ8.js";
 import { WorkflowEntrypoint, WorkflowEvent } from "cloudflare:workers";
 
 //#region src/workflows.d.ts

package/dist/workflows.js

@@ -1,6 +1,6 @@
 import { isInternalJsStubProp } from "./utils.js";
 import { getAgentByName } from "./agent-routing.js";
-import "./src-5W6JNKVb.js";
+import "./src-DlSHshb2.js";
 import { WorkflowRejectedError } from "./workflow-types.js";
 import { WorkflowEntrypoint } from "cloudflare:workers";
 //#region src/workflows.ts

package/docs/agent-class.md

@@ -82,7 +82,7 @@ export class MyDurableObject extends DurableObject {
 
 `Lifecycle` owns the Agent's physical Durable Object alarm because schedules, keep-alive, fibers, sub-agents, and other capabilities share the same alarm slot. Do not override `alarm()` or call `this.ctx.storage.setAlarm()` from an Agent feature; one caller could overwrite another feature's wake-up.
 
-Use `this.schedule()` for named Agent callbacks. A reusable capability with its own durable work implements `getNextAlarm()` and `onAlarm()`, then calls `this.lifecycle.alarms.rearm()` after its durable state changes. See [Durable Object lifecycle](./lifecycle.md#shared-alarm-ownership) and [Scheduling](./scheduling.md).
+Use `this.schedule()` for named Agent callbacks. A reusable capability with its own durable work pushes jobs through `this.lifecycle.jobs` and implements `onJob()`; Lifecycle drives due jobs and re-arms the alarm from queue state. See [Durable Object lifecycle](./lifecycle.md#the-job-queue) and [Scheduling](./scheduling.md).
 
 ### `this.ctx`
 
@@ -278,7 +278,7 @@ class MyAgent extends Agent {
 }
 ```
 
-Schedules are stored in the `cf_agents_schedules` SQL table. Cron schedules automatically reschedule themselves after execution, while one-time schedules are deleted.
+Schedules are stored as jobs in the `cf_agents_jobs` SQL table, the Lifecycle-owned job queue. Cron schedules automatically reschedule themselves after execution, while one-time schedules are deleted.
 
 ### `this.mcp` and friends
 

package/docs/agent-tools.md

@@ -1,7 +1,8 @@
 # Agent Tools
 
 Agent tools let one chat agent dispatch another chat-capable sub-agent as part
-of its work. The child is a real sub-agent with its own Durable Object storage,
+of its work — per-run, parent-supervised delegation is the flagship use case
+for facet-backed dynamic agents. The child is a real sub-agent with its own Durable Object storage,
 messages, tools, resumable stream, and drill-in URL. The parent keeps a small
 run registry so clients can render the child timeline, replay it after refresh,
 and clean it up later.

package/docs/channels.md

@@ -0,0 +1,323 @@
+# `agents/channels`
+
+`agents/channels` gives an agent one interface for sending and receiving
+messages across different platforms. Use a Channel directly, expose it as an AI
+tool, or register it with a durable `ChannelHost` that owns routing and delivery
+recovery.
+
+> [!NOTE]
+> Channels is experimental. Its interface _will_ change before the package
+> reaches a stable release.
+
+## Install
+
+```bash
+npm install agents
+```
+
+## Create channels
+
+Each adapter turns provider configuration into the same `Channel` interface. A
+`ChannelHost` holds them, keyed by names you choose:
+
+```typescript
+import { ChannelHost, routes } from "agents/channels";
+import { email } from "agents/channels/email";
+import { slack } from "agents/channels/slack";
+import { telegram } from "agents/channels/telegram";
+
+const host = new ChannelHost({
+  channels: {
+    slack: slack({
+      botToken: env.SLACK_BOT_TOKEN,
+      webhook: {
+        signingSecret: env.SLACK_SIGNING_SECRET,
+        botUserId: env.SLACK_BOT_USER_ID
+      },
+      route: routes.perThread
+    }),
+    telegram: telegram({
+      botToken: env.TELEGRAM_BOT_TOKEN,
+      webhook: { secretToken: env.TELEGRAM_WEBHOOK_SECRET },
+      route: routes.perThread
+    }),
+    email: email({
+      binding: env.EMAIL,
+      from: "agent@example.com",
+      route: routes.perThread
+    })
+  },
+
+  async onMessage({ route, dispatchId, message }) {
+    await conversationFor(route).receive(dispatchId, message);
+  }
+});
+```
+
+## 1. Send a message
+
+A **surface** is a destination for an outbound message.
+You get one from an inbound message's reply field, or by constructing one from a raw channel identifier through the host.
+
+```typescript
+const surface = host.contactSurface({
+  channelKey: "slack",
+  scope: "T123",
+  subject: "U456"
+});
+
+await host.deliver(surface, {
+  title: "Import needs attention",
+  markdown: "The customer import stopped after **1,240 records**."
+});
+```
+
+An identity's `channelKey` names the configured Channel that observed it. Its
+optional `scope` names a tenant within that Channel and defaults to `"default"`;
+for example, one configured Slack app can observe the same user ID in several
+workspaces. The Host stamps `channelKey` on inbound identities because an adapter
+does not know the key it was configured under.
+
+The same human observed through two configured Channels on one platform is two
+Channel identities, just as the same human on Slack and email is. Applications
+that know they are the same person link those identities explicitly.
+
+Compose destinations with `fallback()` and `fanout()`:
+
+```typescript
+import { fallback, fanout } from "agents/channels";
+
+await host.deliver(fallback([slackSurface, emailSurface]), message);
+await host.deliver(fanout([slackSurface, emailSurface]), message);
+```
+
+`fallback()` tries destinations in order, advancing only after a _confirmed_
+failure, so it can never duplicate a delivery. For a stream, it advances only
+when that failure happens before the destination starts reading; replaying an
+arbitrarily large consumed prefix would require an unbounded buffer. `fanout()`
+sends to all destinations; a partial or uncertain result is reported as
+`uncertain` for the same reason.
+The Host installs both policies as ordinary Channels under reserved keys. You
+can register another composite policy as an ordinary Channel under your own key
+and pair it with a surface constructor that writes that key; inject only the
+outbound resolution capability the policy needs, as the exported built-in
+policy Channels do.
+
+## 2. Give a destination to a model
+
+```typescript
+import { generateText, stepCountIs } from "ai";
+import { createWorkersAI } from "workers-ai-provider";
+import { createSendMessageTool } from "agents/channels/ai-sdk";
+
+const workersai = createWorkersAI({ binding: env.AI });
+
+await generateText({
+  model: workersai("@cf/moonshotai/kimi-k2.7-code"),
+  prompt: "An import stopped after 1,240 records. Notify support.",
+  tools: {
+    contactSupport: createSendMessageTool(
+      host,
+      fallback([slackSurface, emailSurface]),
+      { description: "Contact support when a person needs to intervene" }
+    )
+  },
+  stopWhen: stepCountIs(2)
+});
+```
+
+The model writes the message; you chose the destination. TanStack AI exports the
+same `createSendMessageTool(host, surface, options)` from
+`agents/channels/tanstack-ai`.
+
+## 3. Receive messages
+
+One entry point covers every configured Channel's webhook, and Workers Email
+arrives the same way:
+
+```typescript
+export default {
+  async fetch(request: Request): Promise<Response> {
+    const response = await host.handleRequest(request);
+    if (response) return response;
+    return new Response("Not found", { status: 404 });
+  },
+
+  async email(message: ForwardableEmailMessage): Promise<void> {
+    await host.handleEmail(message);
+  }
+} satisfies ExportedHandler<Env>;
+```
+
+Each Channel authenticates its own input and declines what isn't its business,
+so the Host asks them in configuration order and the first to claim it wins.
+
+### Routing
+
+A Channel's `route` turns one normalized event into an opaque application
+string — a Durable Object name, a queue key, a database id — or `null` to ignore
+the event entirely. The key is used to identify a common destination for
+messages -- i.e. typically a single conversation:
+
+```typescript
+telegram({
+  // …credentials…
+  route(event) {
+    return event.thread.isDirectMessage === true ? event.thread.id : null;
+  }
+});
+```
+
+Channels exposes builtin helpers for the common mappings — `routes.perThread`
+and `routes.perEvent`, which namespace their routes as `thread:…` and
+`event:…`.
+
+Deciding whether an event is relevant at all is a different question, and one
+only your application can answer, because the answer usually depends on state
+you hold. Write that in your own `route` and return `null` to ignore the event:
+
+```typescript
+route(event) {
+  // Slack shows a bot every message in every channel it belongs to. Answer
+  // when addressed, and otherwise only join threads we are already in.
+  const thread = routes.perThread(event);
+  const addressed =
+    event.thread.isDirectMessage === true || event.message.isMention === true;
+  if (addressed) return thread;
+  return (await myConversations.knows(thread)) ? thread : null;
+}
+```
+
+A lookup like that runs for every event reaching it, so put it behind a cheaper
+check, keep it read-only, and do not let it create the state it is testing for —
+otherwise the first stray message conjures the thing the check is looking for.
+
+### Link identities
+
+Personal agents often wwant to resolve users regardless of the channel they messaged on. Your application can explicitly record connections between channel identities and expose them to the Host for messages to be routed on:
+
+```typescript
+const host = new ChannelHost({
+  channels,
+  findUser: (identity) => users.findUser(identity),
+  onMessage,
+  onApprovalResponse
+});
+
+// ...
+// route to a user's central conversaion if one exists, else start a new
+// conversation for each thread:
+route: routes.byUser(routes.perThread);
+
+// or prefer the linked person, then the sender we recognise, then a new
+// conversation per event:
+route: routes.byUser(routes.byIdentity(routes.perEvent));
+```
+
+`byIdentity` groups events carrying the _same_ identity. It never infers that
+two different identities belong to one person — that stays an explicit
+application decision, which `byUser` then exposes to routing. Omit its fallback
+to ignore events that carry no identity at all.
+
+If your application does not already store user identities, `createUserIdentityStore(storage)` creates a Durable Object SQL store of the right shape. Your application can call `store.link` to connect multiple identities together.
+
+### Ask for approval
+
+### Request approval
+
+The Host exposes a utility for durably correlating inbound approvals to outbound requests:
+
+```typescript
+await host.requestApproval({
+  interactionId: "deploy-42",
+  request: {
+    title: "Production deployment",
+    summary: "Deploy version 2026.08.17 to production?",
+    input: {
+      version: "2026.08.17",
+      environment: "production"
+    }
+  }
+});
+await host.requestApproval(surface, {
+  interactionId: crypto.randomUUID(),
+  request: {
+    title: "Production deployment",
+    summary: "Deploy version 2026.08.17 to production?",
+    input: { version: "2026.08.17" }
+  }
+});
+```
+
+Users can respond to approval requests through native surfaces (e.g. Telegram
+buttons) or HTTP inbound URLs, resolved by the Channel Host itself for your application to settle.
+
+## Custom channels
+
+Any transport can become a Channel:
+
+```typescript
+import { matchesPath, routes, type Channel } from "agents/channels";
+
+const supportForm: Channel = {
+  route: routes.perEvent,
+  ingress: {
+    async receive(request) {
+      if (!matchesPath(request, "/support")) return null;
+
+      const raw = await request.json<{ message: string; email: string }>();
+      const eventId = crypto.randomUUID();
+      return {
+        events: [
+          {
+            raw,
+            event: {
+              type: "message",
+              eventId,
+              thread: { id: eventId, isDirectMessage: true },
+              actor: {
+                id: raw.email,
+                // The Host stamps the configured `channelKey`.
+                identity: { subject: raw.email }
+              },
+              message: { id: eventId, text: raw.message }
+            }
+          }
+        ],
+        response: Response.json({ accepted: true }, { status: 202 })
+      };
+    }
+  }
+};
+```
+
+Returning `null` declines the request so another Channel can claim it.
+
+## Durability contract
+
+Channels holds no state: no outbox, no retries, no deduplication, no scheduler.
+Durability is a property of how your application uses it. A caller-supplied
+`deliveryId` is correlation metadata, not an idempotency guarantee; an adapter
+may map it to a provider primitive when one exists.
+
+| Channels guarantees                                                     | Your application must                                                       |
+| ----------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| A `dispatchId` stable across redelivery and unaffected by routing       | Deduplicate on it before starting any side effect                           |
+| The Host awaits your callback before the provider is acknowledged       | Hand off durably before returning — a DO RPC, queue send, or workflow start |
+| One outbound attempt per `deliver()` or `stream()`, reported honestly   | Decide whether to retry; `uncertain` may duplicate a real delivery          |
+| Surfaces are plain JSON you can persist                                 | Keep configured channel keys stable                                         |
+| Decisions arrive as normalized events carrying your own `interactionId` | Own settlement; an interaction id is not an authorization credential        |
+
+## Future work
+
+- [ ] Approval-link ingress: signing, verification, and a confirmation page, so
+      link approvals return through the same normalized path as Slack buttons
+- [ ] Reader-initiated stream cancellation: Slack's `message_stream_stopped`
+      and Telegram's `stopped_message_generation` should reach the running
+      generation as ordinary ingress, so aborting it errors the stream and
+      each Channel finalizes on the path it already has
+- [ ] More built-in channels
+- [ ] Rendering templates (pretty emails)
+- [ ] Automatic webhook registration
+- [ ] Security review of approval flows
+- [ ] Conformance tests of adapters

package/docs/chat-agents.md

@@ -520,13 +520,9 @@ their cleanup and skipped continuations return immediately.
 
 #### Overriding the clear handler
 
-The SDK's built-in `CF_AGENT_CHAT_CLEAR` handler calls `resetTurnState()`
-automatically. If your `onMessage` override intercepts `CF_AGENT_CHAT_CLEAR`
-and returns before the SDK sees the message — for example, to scope the delete
-to a specific workflow — the built-in handler never runs. The active stream
-continues and queued continuations persist into the newly-cleared conversation.
+The SDK's built-in `CF_AGENT_CHAT_CLEAR` handler calls `resetTurnState()` and clears the default Sessions handle. If an `onMessage` override intercepts this frame and returns early, the built-in handler cannot stop the active stream or clear history.
 
-Call `this.resetTurnState()` before performing your scoped delete:
+Perform authorization or logging, then pass the frame to the original handler:
 
 ```typescript
 import { MessageType } from "@cloudflare/ai-chat/types";
@@ -536,19 +532,16 @@ this.onMessage = async (connection, message) => {
   if (typeof message === "string") {
     const data = JSON.parse(message);
     if (data.type === MessageType.CF_AGENT_CHAT_CLEAR) {
-      this.resetTurnState();
-      this.sql`
-        DELETE FROM cf_ai_chat_agent_messages
-        WHERE workflow_id = ${this.workflowId}
-      `;
-      await this.saveMessages([]);
-      return;
+      await this.authorizeClear(connection);
+      console.log("clearing conversation");
     }
   }
   return _onMessage(connection, message);
 };
 ```
 
+Do not write directly to Sessions tables. Use `this.sessions.session().clearMessages()` when implementing a separate server-side history operation outside the chat protocol.
+
 ### Lifecycle Hooks
 
 Override `onConnect` and `onClose` to add custom logic. Stream resumption and message sync are handled for you automatically — you do not need to call `super`:

package/docs/context.md

@@ -0,0 +1,131 @@
+# Context
+
+> **Experimental.** Everything exported from `agents/context` may change between releases while the API stabilizes.
+
+`agents/context` assembles an agent's system prompt from labelled blocks. A block is a piece of prompt text with a storage provider behind it. What the provider can do decides how the block behaves and which tools the model gets for it.
+
+Context is prompt assembly. It is not conversation storage. It composes with [`agents/sessions`](./sessions.md) rather than living inside it, so an agent can have a prompt without a transcript, or a transcript without a prompt.
+
+## Blocks
+
+```ts
+import { ContextBlocks } from "agents/context";
+
+const context = new ContextBlocks([
+  {
+    label: "soul",
+    provider: { get: async () => "You are a helpful assistant." }
+  },
+  {
+    label: "memory",
+    description: "Facts learned about the user",
+    maxTokens: 1_100,
+    provider: memoryProvider
+  }
+]);
+
+const system = await context.freezeSystemPrompt();
+const tools = await context.tools();
+```
+
+Each block renders as a labelled section of the system prompt. The header carries the label, the description, a token-usage percentage when `maxTokens` is set, and a capability marker (`[readonly]`, `[writable]`, `[loadable]`, or `[searchable]`).
+
+An empty read-only block is skipped. Writable, loadable, and searchable blocks always render so the model knows which tools can address them.
+
+## Providers
+
+The provider decides the block's behavior. The checks are structural, not nominal.
+
+| Provider shape          | Block behavior                               |
+| ----------------------- | -------------------------------------------- |
+| `get()`                 | Read-only text in the prompt                 |
+| `get()` + `set()`       | Writable through the `set_context` tool      |
+| `get()` + `search(key)` | Summary in the prompt, `search_context` tool |
+
+`get()` returns the block's current content, or `null` when it has none. An optional `init(label)` receives the block label before first use, so one provider class can serve several labels.
+
+`ContextBlocks` also accepts a `defaultProvider` factory. A block declared without a `provider` is then wired to whatever that factory returns for its label, which is how a host offers durable writable blocks by label alone.
+
+### Durable SQLite blocks
+
+`AgentContextProvider` stores one block per row in `cf_agents_context_blocks` in the Durable Object's own SQLite database:
+
+```ts
+import { AgentContextProvider } from "agents/context";
+
+const context = new ContextBlocks([
+  { label: "memory", provider: new AgentContextProvider(this, "memory") }
+]);
+```
+
+The constructor takes anything with a tagged-template `sql` method, which an `Agent` already has. The label argument is optional: `init()` fills it in from the block declaration.
+
+### Searchable blocks
+
+`AgentSearchProvider` backs a block with a Durable Object FTS5 table:
+
+```ts
+import { AgentSearchProvider } from "agents/context";
+
+const context = new ContextBlocks([
+  { label: "knowledge", provider: new AgentSearchProvider(this) }
+]);
+```
+
+`get()` renders a count of indexed entries rather than the entries themselves. `search(query)` returns up to 10 ranked matches through the `search_context` tool. `set(key, content)` replaces one keyed entry.
+
+The FTS5 table is the only store for these entries. A mirror row table would double the billed writes of every indexed entry to serve a count and a lookup the index already answers. Entries live in `cf_agents_search_fts`, namespaced by label, separate from the Sessions message index.
+
+## Frozen prompts
+
+`freezeSystemPrompt()` renders once and returns the same string on every later call, so the provider's prefix cache stays warm across turns. `setBlock()` writes to the provider immediately but deliberately does not change the frozen prompt; call `refreshSystemPrompt()` to re-render from current block state.
+
+Pass a `promptStore` (any writable provider) as the second constructor argument and the frozen prompt is persisted:
+
+```ts
+const context = new ContextBlocks(
+  configs,
+  new AgentContextProvider(this, "_system_prompt"),
+  (label) => new AgentContextProvider(this, label)
+);
+
+const system = await context.freezeSystemPrompt();
+```
+
+`freezeSystemPrompt()` returns the stored prompt when one exists, and otherwise loads providers, renders, and persists. So a cold wake reuses the exact prompt string the model already cached instead of re-rendering a subtly different one.
+
+`refreshSystemPrompt()` reloads every provider, re-renders, and overwrites the stored prompt.
+
+## Tools
+
+`tools()` returns an AI SDK `ToolSet` wired from what the blocks can do:
+
+- `set_context` when any block is writable
+- `search_context` when any block is backed by a search provider
+
+An agent with only read-only blocks gets no tools at all.
+
+## Think
+
+`Think` builds its `ContextBlocks` from `configureContext()` during startup:
+
+```ts
+import type { ContextConfig } from "agents/context";
+
+class MyAgent extends Think<Env> {
+  configureContext(): ContextConfig[] {
+    return [
+      { label: "soul", provider: { get: async () => "You are helpful." } },
+      { label: "memory", description: "Learned facts", maxTokens: 2_000 }
+    ];
+  }
+}
+```
+
+A block declared without a provider is auto-wired to durable per-agent SQLite. The frozen system prompt is always persisted, in `_system_prompt`, so there is nothing to opt into.
+
+The assembled blocks are available as `this.context` after `onStart()`.
+
+## Related
+
+- [Sessions](./sessions.md) - durable message trees, streamed history, compaction, and attachment offload

package/docs/index.md

@@ -11,13 +11,13 @@ Build stateful AI agents on Cloudflare Workers. Every agent is a Durable Object
 
 Pick the base class that matches what you are building. They share the same Durable Object foundation, so you can start small and move up without re-platforming.
 
-| You are building...                                            | Use                                                                                | Why                                                                                                                    |
-| -------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| Stateful backend logic, real-time sync, custom protocols       | [`Agent`](./agent-class.md)                                                        | The core class: state, WebSockets, scheduling, SQL, and sub-agents. No opinions about chat or LLMs.                    |
-| A chat UI where you own the loop, the stream, and the response | [`AIChatAgent`](./chat-agents.md)                                                  | A thin chat-protocol adapter for `useAgentChat`. Bring your own agentic loop and custom streaming.                     |
-| A durable, general-purpose reasoning agent                     | [`Think`](https://github.com/cloudflare/agents/blob/main/docs/think/index.md)      | Opinionated runtime: agentic loop, sessions, tools, memory, compaction, recovery, and multi-channel delivery built in. |
-| A voice agent (speech in, speech out)                          | [Voice mixins](https://github.com/cloudflare/agents/blob/main/docs/voice/index.md) | `withVoice` adds real-time STT/TTS, interruption and barge-in, and conversation persistence to an agent.               |
-| Durable multi-step processes (not chat)                        | [Workflows](./workflows.md)                                                        | Long-running, retryable step orchestration with Cloudflare Workflows.                                                  |
+| You are building...                                            | Use                                                                           | Why                                                                                                                    |
+| -------------------------------------------------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| Stateful backend logic, real-time sync, custom protocols       | [`Agent`](./agent-class.md)                                                   | The core class: state, WebSockets, scheduling, SQL, and sub-agents. No opinions about chat or LLMs.                    |
+| A chat UI where you own the loop, the stream, and the response | [`AIChatAgent`](./chat-agents.md)                                             | A thin chat-protocol adapter for `useAgentChat`. Bring your own agentic loop and custom streaming.                     |
+| A durable, general-purpose reasoning agent                     | [`Think`](https://github.com/cloudflare/agents/blob/main/docs/think/index.md) | Opinionated runtime: agentic loop, sessions, tools, memory, compaction, recovery, and multi-channel delivery built in. |
+| A voice agent (speech in, speech out)                          | [Voice mixins](./voice.md)                                                    | `withVoice` adds real-time STT/TTS, interruption and barge-in, and conversation persistence to an agent.               |
+| Durable multi-step processes (not chat)                        | [Workflows](./workflows.md)                                                   | Long-running, retryable step orchestration with Cloudflare Workflows.                                                  |
 
 Not sure? Start with [`Agent`](./agent-class.md) for raw building blocks, or [`Think`](https://github.com/cloudflare/agents/blob/main/docs/think/index.md) if you want a chat or reasoning agent that already handles the hard parts.
 
@@ -40,8 +40,8 @@ The differentiator is not "we have durable state" — it is what happens when a
 ## Core Concepts
 
 - [State Management](./state.md) - Managing agent state with `setState()`, `initialState`, and `onStateChanged()`
-- [Routing](./routing.md) - How `routeAgentRequest()` and agent naming works
-- [Sub-agents](./sub-agents.md) - Parent/child DO composition via facets, nested routing, and direct child connections
+- [Routing](./routing.md) - How `routeAgentRequest()` and agent naming works, plus `RoutedAgents` for a hub that routes to many independent Agents
+- [Dynamic agents](./sub-agents.md) - Facet-backed child agents for code the parent supervises (dynamic/generated code, per-run tool agents, sandboxes) — not the recommended primitive for many independent peers like chats
 - [HTTP & WebSockets](./http-websockets.md) - Request handling and real-time connections
 - [Callable Methods](./callable-methods.md) - The `@callable` decorator and client-server method calls
 - [Readonly Connections](./readonly-connections.md) - Restricting which connections can modify state
@@ -57,9 +57,9 @@ The differentiator is not "we have durable state" — it is what happens when a
 - [Webhooks](./webhooks.md) - Receiving and sending webhook events
 - [Push Notifications](./push-notifications.md) - Browser push notifications via Web Push API and scheduled delivery
 - TODO: [SMS](./sms.md) - Text message integration (Twilio, etc.)
-- [Voice Agents](https://github.com/cloudflare/agents/blob/main/docs/voice/index.md) - Build voice agents with real-time speech-to-text, text-to-speech, and conversation persistence
+- [Voice Agents](./voice.md) - Build voice agents with real-time speech-to-text, text-to-speech, and conversation persistence
+- [Channels](./channels.md) - Send and receive messages through Slack, Telegram, email, browser voice, or custom adapters
 - [Chat SDK State](./chat-sdk.md) - Store Chat SDK subscriptions, locks, queues, and history in Agents sub-agents
-- TODO: [Messengers](./messengers.md) - Slack, Discord, Telegram, and other chat platforms
 
 ## Background Processing
 
@@ -80,7 +80,8 @@ The differentiator is not "we have durable state" — it is what happens when a
 - [Server-Driven Messages](./server-driven-messages.md) - Autonomous agent workflows: scheduled follow-ups, queue processing, webhooks, chained reasoning
 - TODO: [Using AI Models](./using-ai-models.md) - OpenAI, Anthropic, Workers AI, and other providers
 - TODO: [RAG (Retrieval Augmented Generation)](./rag.md) - Vector search with Vectorize
-- [Sessions (Experimental)](./sessions.md) - Persistent conversation storage with tree-structured messages, context blocks, compaction, and search
+- [Sessions (Experimental)](./sessions.md) - Durable message trees, streamed history, compaction, search, and lossless attachment offload
+- [Context (Experimental)](./context.md) - System-prompt blocks, frozen prompts, writable/searchable/loadable providers, and their tools
 - [Workspace (Experimental)](https://github.com/cloudflare/agents/blob/main/docs/shell/index.md) - Durable virtual filesystem backed by SQLite + R2
 - [Codemode (Experimental)](https://github.com/cloudflare/agents/blob/main/docs/agents/codemode.md) - LLM-generated executable code for tool orchestration
 - [Client Tools Continuation](./client-tools-continuation.md) - Handling tool calls across client/server
@@ -141,6 +142,8 @@ The differentiator is not "we have durable state" — it is what happens when a
 ## Reference
 
 - [Durable Object Lifecycle](./lifecycle.md) - Compose reusable durable components outside the Agent base class
+- [Tasks](./tasks.md) - Durable, replayable background work with journaled steps and durable sleeps (experimental)
+- [Streams](./streams.md) - Durable incremental output: chunk log, cursor, replay-then-tail reads (experimental)
 - TODO: [API Reference](./api-reference.md) - Complete API documentation
 - TODO: [FAQ / How is this different from Durable Objects?](./faq.md)
 - TODO: [Resources & Further Reading](./resources.md)