workflow 5.0.0-beta.5 → 5.0.0-beta.51

package/docs/ai/message-queueing.mdx

@@ -7,15 +7,14 @@ prerequisites:
   - /docs/ai
 related:
   - /docs/ai/chat-session-modeling
-  - /docs/api-reference/workflow-ai/durable-agent
   - /docs/api-reference/workflow/define-hook
 ---
 
 When using [multi-turn workflows](/docs/ai/chat-session-modeling#multi-turn-workflows), messages typically arrive between agent turns. The workflow waits at a hook, receives a message, then starts a new turn. But sometimes you need to inject messages *during* an agent's turn, before tool calls complete or while the model is reasoning.
 
-`DurableAgent`'s `prepareStep` callback enables this by running before each step in the agent loop, giving you a chance to inject queued messages into the conversation. `prepareStep` also allows you to modify the model choice and existing messages mid-turn, see AI SDK's [prepareStep callback](https://ai-sdk.dev/docs/agents/loop-control#prepare-step) for more details.
+`WorkflowAgent`'s `prepareStep` callback enables this by running before each step in the agent loop, giving you a chance to inject queued messages into the conversation. `prepareStep` also allows you to modify the model choice and existing messages mid-turn, see AI SDK's [prepareStep callback](https://ai-sdk.dev/docs/agents/loop-control#prepare-step) for more details.
 
-## When to Use This
+## When to use this
 
 Message queueing is useful when:
 
@@ -24,154 +23,116 @@ Message queueing is useful when:
 - You want messages to influence the agent's next step rather than waiting for the current turn to complete
 
 <Callout type="info">
-If you just need basic multi-turn conversations where messages arrive between turns, see [Chat Session Modeling](/docs/ai/chat-session-modeling). This guide covers the more advanced case of injecting messages *during* turns.
+If you need basic multi-turn conversations where messages arrive between turns, see [Chat Session Modeling](/docs/ai/chat-session-modeling). This guide covers the more advanced case of injecting messages *during* turns.
 </Callout>
 
-## The `prepareStep` Callback
+## The `prepareStep` callback
 
-The `prepareStep` callback runs before each step in the agent loop. It receives the current state and can modify the messages sent to the model:
+The `prepareStep` callback runs before each step in the agent loop. Use WorkflowAgent's exported types rather than redeclaring its normalized provider-prompt contract:
 
 ```typescript lineNumbers
-import type { ModelMessage, LanguageModel } from "ai";
-
-interface PrepareStepInfo {
-  model: string | (() => Promise<LanguageModel>);    // Current model
-  stepNumber: number;                                // 0-indexed step count
-  steps: StepResult[];                               // Previous step results
-  messages: ModelMessage[];                          // Messages to be sent
-}
-
-interface PrepareStepResult {
-  model?: string | (() => Promise<LanguageModel>);   // Override model
-  messages?: ModelMessage[];                         // Override messages
-}
+import type {
+  PrepareStepInfo,
+  PrepareStepResult,
+} from "@ai-sdk/workflow";
+
+const prepareStep = (
+  { messages }: PrepareStepInfo
+): PrepareStepResult => ({ messages });
 ```
 
-## Injecting Queued Messages
+`PrepareStepInfo.messages` is a normalized `LanguageModelV4Prompt`, not the application-level `ModelMessage[]` accepted by `WorkflowAgent.stream()`.
 
-Once you have a [multi-turn workflow](/docs/ai/chat-session-modeling#multi-turn-workflows), you can combine a message queue with `prepareStep` to inject messages that arrive during processing:
+## Queueing messages during and between turns
+
+Use one async Hook consumer and one FIFO. `prepareStep` atomically drains messages that arrived during a model turn; messages that arrive after the final model step become input to the next turn. Each Hook payload therefore has exactly one ownership path.
 
 ```typescript title="workflows/chat/index.ts" lineNumbers
-import { DurableAgent } from "@workflow/ai/agent";
+import { WorkflowAgent, type ModelCallStreamPart } from "@ai-sdk/workflow";
 import { getWritable, getWorkflowMetadata } from "workflow";
 import { chatMessageHook } from "./hooks/chat-message";
 import { flightBookingTools, FLIGHT_ASSISTANT_PROMPT } from "./steps/tools";
-import type { UIMessageChunk, ModelMessage } from "ai";
+import type { ModelMessage } from "ai";
 
 export async function chat(initialMessages: ModelMessage[]) {
   "use workflow";
 
   const { workflowRunId: runId } = getWorkflowMetadata();
-  const writable = getWritable<UIMessageChunk>();
+  const writable = getWritable<ModelCallStreamPart>();
+  let messages: ModelMessage[] = [...initialMessages];
   const messageQueue: Array<{ role: "user"; content: string }> = []; // [!code highlight]
+  let stopped = false;
+  let notifyMessage: (() => void) | undefined;
 
-  const agent = new DurableAgent({
-    model: "bedrock/claude-haiku-4-5-20251001-v1",
+  const agent = new WorkflowAgent({
+    model: "spacexai/grok-4.6",
     instructions: FLIGHT_ASSISTANT_PROMPT,
     tools: flightBookingTools,
   });
 
-  // Listen for messages in background (non-blocking) // [!code highlight]
   const hook = chatMessageHook.create({ token: runId }); // [!code highlight]
-  hook.then(({ message }) => { // [!code highlight]
-    messageQueue.push({ role: "user", content: message }); // [!code highlight]
-  }); // [!code highlight]
-
-  await agent.stream({
-    messages: initialMessages,
-    writable,
-    prepareStep: ({ messages: currentMessages }) => { // [!code highlight]
-      // Inject any queued messages before the next LLM call // [!code highlight]
-      if (messageQueue.length > 0) { // [!code highlight]
-        const newMessages = messageQueue.splice(0); // Drain queue // [!code highlight]
-        return { // [!code highlight]
-          messages: [ // [!code highlight]
-            ...currentMessages, // [!code highlight]
-            ...newMessages.map((m) => ({ // [!code highlight]
-              role: m.role, // [!code highlight]
-              content: [{ type: "text" as const, text: m.content }], // [!code highlight]
-            })), // [!code highlight]
-          ], // [!code highlight]
-        }; // [!code highlight]
+  // This is the only code path that consumes Hook payloads. // [!code highlight]
+  const consumeMessages = (async () => { // [!code highlight]
+    for await (const { message } of hook) { // [!code highlight]
+      if (message === "/done") { // [!code highlight]
+        stopped = true; // [!code highlight]
+        notifyMessage?.(); // [!code highlight]
+        break; // [!code highlight]
       } // [!code highlight]
-      return {}; // [!code highlight]
-    }, // [!code highlight]
-  });
-}
-```
-
-Messages sent via `chatMessageHook.resume()` accumulate in the queue and get injected before the next step, whether that's a tool call or another LLM request.
-
-<Callout type="info">
-The `prepareStep` callback receives messages in `ModelMessage[]` format (with content arrays), which is the internal format used by the AI SDK.
-</Callout>
-
-## Combining with Multi-Turn Sessions
-
-You can also combine message queueing with the standard multi-turn pattern:
-
-```typescript title="workflows/chat/index.ts" lineNumbers
-import { DurableAgent } from "@workflow/ai/agent";
-import { getWritable, getWorkflowMetadata } from "workflow";
-import { chatMessageHook } from "./hooks/chat-message";
-import type { UIMessageChunk, ModelMessage } from "ai";
-
-export async function chat(initialMessages: ModelMessage[]) {
-  "use workflow";
-
-  const { workflowRunId: runId } = getWorkflowMetadata();
-  const writable = getWritable<UIMessageChunk>();
-  const messages: ModelMessage[] = [...initialMessages];
-  const messageQueue: Array<{ role: "user"; content: string }> = [];
-
-  const agent = new DurableAgent({ /* ... */ });
-  const hook = chatMessageHook.create({ token: runId });
-
-  while (true) {
-    // Set up non-blocking listener for mid-turn messages // [!code highlight]
-    let pendingMessage: string | null = null; // [!code highlight]
-    hook.then(({ message }) => { // [!code highlight]
-      if (message === "/done") return; // [!code highlight]
       messageQueue.push({ role: "user", content: message }); // [!code highlight]
-      pendingMessage = message; // [!code highlight]
-    }); // [!code highlight]
-
+      notifyMessage?.(); // [!code highlight]
+      notifyMessage = undefined; // [!code highlight]
+    } // [!code highlight]
+  })(); // [!code highlight]
+
+  const waitForMessage = async () => {
+    while (messageQueue.length === 0 && !stopped) {
+      await new Promise<void>((resolve) => {
+        notifyMessage = resolve;
+      });
+    }
+  };
+
+  while (!stopped) {
     const result = await agent.stream({
       messages,
       writable,
       preventClose: true,
+      sendFinish: false,
       prepareStep: ({ messages: currentMessages }) => {
-        // Inject queued messages during turn // [!code highlight]
-        if (messageQueue.length > 0) {
-          const newMessages = messageQueue.splice(0);
-          return {
-            messages: [
-              ...currentMessages,
-              ...newMessages.map((m) => ({
-                role: m.role,
-                content: [{ type: "text" as const, text: m.content }],
-              })),
-            ],
-          };
-        }
-        return {};
+        const queued = messageQueue.splice(0); // Atomic drain // [!code highlight]
+        if (queued.length === 0) return {};
+        return {
+          messages: [
+            ...currentMessages,
+            ...queued.map(({ role, content }) => ({
+              role,
+              content: [{ type: "text" as const, text: content }],
+            })),
+          ],
+        };
       },
     });
+    messages = result.messages;
 
-    messages.push(...result.messages.slice(messages.length));
+    if (stopped) break;
+    await waitForMessage(); // [!code highlight]
+    if (stopped) break;
 
-    // Wait for next message (either queued during turn or new) // [!code highlight]
-    const { message: followUp } = pendingMessage ? { message: pendingMessage } : await hook; // [!code highlight]
-    if (followUp === "/done") break;
-
-    messages.push({ role: "user", content: followUp });
+    // Anything not consumed by prepareStep arrived after the final model step.
+    messages = [...messages, ...messageQueue.splice(0)]; // [!code highlight]
   }
+
+  await consumeMessages;
+  return { messages };
 }
 ```
 
-## Related Documentation
+Messages sent via `chatMessageHook.resume()` accumulate until either `prepareStep` or the between-turn branch drains the FIFO. Send `/done` to stop the consumer and let the workflow return.
+
+## Related documentation
 
 - [Chat Session Modeling](/docs/ai/chat-session-modeling) - Single-turn vs multi-turn patterns
 - [Building Durable AI Agents](/docs/ai) - Complete guide to creating durable agents
-- [`DurableAgent` API Reference](/docs/api-reference/workflow-ai/durable-agent) - Full API documentation
+- [`WorkflowAgent`](https://ai-sdk.dev/v7/docs/agents/workflow-agent#workflowagent) - AI SDK API for durable, resumable agents
 - [`defineHook()` API Reference](/docs/api-reference/workflow/define-hook) - Hook configuration options

package/docs/ai/meta.json

@@ -7,6 +7,7 @@
     "sleep-and-delays",
     "human-in-the-loop",
     "defining-tools",
+    "message-queueing",
     "chat-session-modeling"
   ],
   "defaultOpen": true

package/docs/ai/resumable-streams.mdx

@@ -12,23 +12,31 @@ related:
   - /docs/api-reference/workflow-api/get-run
 ---
 
-When building chat interfaces, it's common to run into network interruptions, page refreshes, or serverless function timeouts, which can break the connection to an in-progress agent.
+<Callout type="warn">
+`WorkflowChatTransport` now ships in AI SDK as a 1:1 port, so import it from `@ai-sdk/workflow` (the `@workflow/ai` export is deprecated). See [Resumable Streaming with `WorkflowChatTransport`](https://ai-sdk.dev/v7/docs/agents/workflow-agent#resumable-streaming-with-workflowchattransport) for the full reference.
+</Callout>
+
+Network interruptions, page refreshes, or Vercel Functions timeouts can break a chat interface's connection to an in-progress agent.
+
+Workflow runs and their attached streams are durable, so users can resume a stream without resending a message or waiting for the entire response again. The client can optionally sync only the data missed since the last connection.
 
-Where a standard chat implementation would require the user to resend their message and wait for the entire response again, workflow runs are durable, and so are the streams attached to them. This means a stream can be resumed at any point, optionally only syncing the data that was missed since the last connection.
+Workflow SDK supports resumable streams, but the client must identify the stream and the position from which to reconnect. The [`WorkflowChatTransport`](/docs/api-reference/workflow-ai/workflow-chat-transport) helper is a drop-in AI SDK transport that handles this client-side resumption logic.
 
-Resumable streams come out of the box with Workflow SDK, however, the client needs to recognize that a stream exists, and needs to know which stream to reconnect to, and needs to know where to start from. For this, Workflow SDK provides the [`WorkflowChatTransport`](/docs/api-reference/workflow-ai/workflow-chat-transport) helper, a drop-in transport for the AI SDK that handles client-side resumption logic for you.
+<Callout type="info">
+When deploying a streaming route to Vercel, enable request cancellation so a browser disconnect terminates that route's abandoned stream reader instead of letting the function run until `FUNCTION_INVOCATION_TIMEOUT`. See [Avoiding Function Timeouts After Client Disconnects](/docs/foundations/streaming#avoiding-function-timeouts-after-client-disconnects).
+</Callout>
 
 ## Implementing stream resumption
 
-Let's add stream resumption to our Flight Booking Agent that we build in the [Building Durable AI Agents](/docs/ai) guide.
+Add stream resumption to the Flight Booking Agent from the [Building Durable AI Agents](/docs/ai) guide.
 
 <Steps>
 
 <Step>
 
-### Return the Run ID from Your API
+### Return the run ID from your API
 
-Modify your chat endpoint to include the workflow run ID in a response header. The Run ID uniquely identifies the run's stream, so it allows the client to know which stream to reconnect to.
+Modify your chat endpoint to include the workflow run ID in a response header. The run ID uniquely identifies the stream so the client knows which stream to reconnect to.
 
 {/*@skip-typecheck: incomplete code sample*/}
 
@@ -54,9 +62,9 @@ export async function POST(req: Request) {
 
 <Step>
 
-### Add a Stream Reconnection Endpoint
+### Add a stream reconnection endpoint
 
-Currently we only have one API endpoint that always creates a new run, so we need to create a new API route that returns the stream for an existing run:
+Create an API route that returns the stream for an existing run. The current endpoint always creates a new run.
 
 ```typescript title="app/api/chat/[id]/stream/route.ts" lineNumbers
 import { createUIMessageStreamResponse } from "ai";
@@ -92,16 +100,16 @@ export async function GET(
 }
 ```
 
-The `startIndex` parameter ensures the client can choose where to resume the stream from. For instance, if the function times out during streaming, the chat transport will use `startIndex` to resume the stream exactly from the last token it received. Negative values are also supported (e.g. `-5` starts 5 chunks before the end), which is useful for custom stream consumers (such as a dashboard showing recent output) that want to show the most recent output without replaying the full stream.
+The `startIndex` parameter lets the client choose where to resume the stream. For example, if the function times out during streaming, the chat transport uses `startIndex` to resume from the last token it received. Negative values are also supported. A value of `-5` starts 5 chunks before the end, which is useful for custom stream consumers that show recent output without replaying the full stream.
 
-When using a negative `startIndex`, your stream endpoint must return a `x-workflow-stream-tail-index` header in order for relative resumption to work. Missing the header will fall back to replaying the entire stream.
+When using a negative `startIndex`, your stream endpoint must return an `x-workflow-stream-tail-index` header for relative resumption. If the header is missing, the transport replays the entire stream.
 </Step>
 
 <Step>
 
-### Use `WorkflowChatTransport` in the Client
+### Use `WorkflowChatTransport` in the client
 
-Replace the default transport in AI-SDK's `useChat` with [`WorkflowChatTransport`](
+Replace the default transport in AI SDK's `useChat` with [`WorkflowChatTransport`](
   /docs/api-reference/workflow-ai/workflow-chat-transport
 ), and update the callbacks to store and use the latest run ID. For now, we'll store the run ID in localStorage. For your own app, this would be stored wherever you store session information.
 
@@ -109,7 +117,7 @@ Replace the default transport in AI-SDK's `useChat` with [`WorkflowChatTransport
 "use client";
 
 import { useChat } from "@ai-sdk/react";
-import { WorkflowChatTransport } from "@workflow/ai"; // [!code highlight]
+import { WorkflowChatTransport } from "@ai-sdk/workflow"; // [!code highlight]
 import { useMemo, useState } from "react";
 
 export default function ChatPage() {
@@ -158,23 +166,23 @@ export default function ChatPage() {
 
 </Steps>
 
-Now try the flight booking example again. Open it up in a separate tab, or spam the refresh button, and see how the client connects to the same chat stream every time.
+Open the flight booking example in another tab or refresh the page repeatedly. The client reconnects to the same chat stream each time.
 
-## How It Works
+## How it works
 
-1. When the user sends a message, `WorkflowChatTransport` makes a POST to `/api/chat`
-2. The API starts a workflow and returns the run ID in the `x-workflow-run-id` header
-3. `onChatSendMessage` stores this run ID in localStorage
-4. If the stream is interrupted before receiving a "finish" chunk, the transport automatically reconnects
-5. `prepareReconnectToStreamRequest` builds the reconnection URL using the stored run ID, pointing to the new endpoint `/api/chat/{runId}/stream`
-6. The reconnection endpoint returns the stream from where the client left off
-7. When the stream completes, `onChatEnd` clears the stored run ID
+1. When the user sends a message, `WorkflowChatTransport` makes a `POST` request to `/api/chat`.
+2. The API starts a workflow and returns the run ID in the `x-workflow-run-id` header.
+3. `onChatSendMessage` stores this run ID in `localStorage`.
+4. If the stream is interrupted before receiving a `finish` chunk, the transport automatically reconnects.
+5. `prepareReconnectToStreamRequest` builds the reconnection URL using the stored run ID and points to `/api/chat/{runId}/stream`.
+6. The reconnection endpoint returns the stream from where the client left off.
+7. When the stream completes, `onChatEnd` clears the stored run ID.
 
-This approach also handles page refreshes, as the client will automatically reconnect to the stream from the last known position when the UI loads with a stored run ID, following the behavior of [AI SDK's stream resumption](https://ai-sdk.dev/docs/ai-sdk-ui/chatbot-resume-streams#chatbot-resume-streams).
+This approach also handles page refreshes, as the client will automatically reconnect to the stream from the last known position when the user interface (UI) loads with a stored run ID, following the behavior of [AI SDK's stream resumption](https://ai-sdk.dev/docs/ai-sdk-ui/chatbot-resume-streams#chatbot-resume-streams).
 
 ### Resuming from the end of the stream
 
-By default, reconnecting replays the entire stream from the beginning (`startIndex: 0`). If you only need to show recent output — for example, when resuming a long conversation after a page refresh — you can set `initialStartIndex` to a negative value to read from the end of the stream instead:
+By default, reconnecting replays the entire stream from the beginning (`startIndex: 0`). If you only need to show recent output (for example, when resuming a long conversation after a page refresh), you can set `initialStartIndex` to a negative value to read from the end of the stream instead:
 
 {/*@skip-typecheck: incomplete code sample*/}
 
@@ -194,8 +202,12 @@ This avoids replaying potentially thousands of chunks and lets the UI render fas
 When using a negative `initialStartIndex`, the reconnection endpoint **must** return the `x-workflow-stream-tail-index` header (as shown in [Step 2](#add-a-stream-reconnection-endpoint) above). The transport uses this header to compute absolute chunk positions so that retries after a disconnect resume from the correct position. If the header is missing, the transport falls back to `startIndex: 0` (replaying the entire stream) and logs a warning.
 </Callout>
 
-## Related Documentation
+### Mid-part resumes
+
+A workflow stream is a flat sequence of chunks, but the AI SDK's UI protocol groups chunks into logical parts (`text-*`, `reasoning-*`, `tool-input-*`) that must be opened with a `*-start` before any `*-delta` or `*-end`. A non-zero `startIndex` can land in the middle of an open part. See [`WorkflowChatTransport` → Mid-part resumes](/docs/api-reference/workflow-ai/workflow-chat-transport#mid-part-resumes) for how this is handled and an example of rewinding to a step boundary on the server.
+
+## Related documentation
 
-- [`WorkflowChatTransport` API Reference](/docs/api-reference/workflow-ai/workflow-chat-transport) - Full configuration options
-- [Streaming](/docs/foundations/streaming) - Understanding workflow streams
-- [`getRun()` API Reference](/docs/api-reference/workflow-api/get-run) - Retrieving existing runs
+- [`WorkflowChatTransport` API reference](/docs/api-reference/workflow-ai/workflow-chat-transport): Full configuration options
+- [Streaming](/docs/foundations/streaming): Understanding workflow streams
+- [`getRun()` API reference](/docs/api-reference/workflow-api/get-run): Retrieving existing runs

package/docs/ai/sleep-and-delays.mdx

@@ -12,23 +12,23 @@ related:
   - /docs/api-reference/workflow/sleep
 ---
 
-AI agents sometimes need to pause execution in order to schedule recurring or future actions, wait before retrying an operation (e.g. for rate limiting), or wait for external state to be available.
+AI agents sometimes need to pause execution to schedule recurring or future actions, wait before retrying an operation (e.g. for rate limiting), or wait for external state to be available.
 
-Workflow SDK's `sleep` function enables Agents to pause execution without consuming resources, and resume at a specified time, after a specified duration, or in response to an external event. Workflow operation that suspend will survive restarts, new deploys, and infrastructure changes, independent of whether the suspense takes seconds or months.
+Workflow SDK's `sleep` function enables Agents to pause execution without consuming resources, and resume at a specified time, after a specified duration, or in response to an external event. Workflow operations that suspend will survive restarts, new deploys, and infrastructure changes, independent of whether the suspense takes seconds or months.
 
 <Callout type="info">
 See the [`sleep()` API Reference](/docs/api-reference/workflow/sleep) for the full list of supported duration formats and detailed API documentation, and see the [hooks](/docs/foundations/hooks) documentation for more information on how to resume in response to external events.
 </Callout>
 
-## Adding a Sleep Tool
+## Adding a sleep tool
 
-Sleep is a built-in function in Workflow SDK, so exposing it as a tool is as simple as wrapping it in a tool definition. Learn more about how to define tools in [Patterns for Defining Tools](/docs/ai/defining-tools).
+Sleep is a built-in function in Workflow SDK. To expose it as a tool, wrap it in a tool definition. Learn more about how to define tools in [Patterns for Defining Tools](/docs/ai/defining-tools).
 
 <Steps>
 
 <Step>
 
-### Define the Tool
+### Define the tool
 
 Add a new "sleep" tool to the `tools` defined in `workflows/chat/steps/tools.ts`:
 
@@ -60,7 +60,7 @@ export const flightBookingTools = {
 ```
 
 <Callout type="info">
-  Note that the `sleep()` function must be called from within a workflow context, not from within a step. This is why `executeSleep` does not have `"use step"` - it runs in the workflow context where `sleep()` is available.
+  Call `sleep()` from within a workflow context, not from within a step. `executeSleep` does not have `"use step"` because it runs in the workflow context where `sleep()` is available.
 </Callout>
 
  This already makes the full sleep functionality available to the Agent!
@@ -71,7 +71,7 @@ export const flightBookingTools = {
 
 ### Show the tool status in the UI
 
-To round it off, extend the UI to display the tool call status. This can be done either by displaying the tool call information directly, or by emitting custom data parts to the stream (see [Streaming Updates from Tools](/docs/ai/streaming-updates-from-tools) for more details). In this case, since there aren't any fine-grained progress updates to show, we'll just display the tool call information directly:
+To round it off, extend the UI to display the tool call status. This can be done either by displaying the tool call information directly, or by emitting custom data parts to the stream (see [Streaming Updates from Tools](/docs/ai/streaming-updates-from-tools) for more details). Since there aren't any fine-grained progress updates to show, we'll display the tool call information directly:
 
 {/*@skip-typecheck: incomplete code sample*/}
 
@@ -153,11 +153,11 @@ function renderToolOutput(part: any) {
 
 Now, try out the Flight Booking Agent again, and ask it to sleep for 10 seconds before checking any flight. You'll see the agent pause, and the UI reflect the tool call status.
 
-## Use Cases
+## Use cases
 
 Aside from providing `sleep()` as a tool, there are other use cases for Agents that commonly call for suspension and resumption.
 
-### Rate Limiting
+### Rate limiting
 
 When hitting API rate limits, use `RetryableError` with a delay:
 
@@ -180,7 +180,7 @@ async function callRateLimitedAPI(endpoint: string) {
 }
 ```
 
-## Related Documentation
+## Related documentation
 
 - [`sleep()` API Reference](/docs/api-reference/workflow/sleep) - Full API documentation with all duration formats
 - [Workflows and Steps](/docs/foundations/workflows-and-steps) - Understanding workflow context

package/docs/ai/streaming-updates-from-tools.mdx

@@ -16,13 +16,13 @@ After [building a durable AI agent](/docs/ai), we already get UI message chunks
 
 Workflow SDK enables this by letting step functions write custom chunks to the same stream the agent uses. These chunks appear as data parts in your messages, which you can render however you like.
 
-As an example, we'll extend out Flight Booking Agent to use emit more granular progress updates while searching for flights.
+As an example, we'll extend our Flight Booking Agent to emit more granular progress updates while searching for flights.
 
 <Steps>
 
 <Step>
 
-### Define Your Data Part Type
+### Define your data part type
 
 First, define a TypeScript type for your custom data part. This ensures type safety across your tool and client code:
 
@@ -44,9 +44,9 @@ The `type` field must be a string starting with `data-` followed by your custom
 
 <Step>
 
-### Emit Updates from Your Tool
+### Emit updates from your tool
 
-Use [`getWritable()`](/docs/api-reference/workflow/get-writable) inside a step function to get a handle to the stream. This is the same stream that the LLM and other tools calls are writing to, so we can inject out own data packets directly.
+Use [`getWritable()`](/docs/api-reference/workflow/get-writable) inside a step function to get a handle to the stream. This is the same stream that the LLM and other tool calls are writing to, so we can inject our own data packets directly.
 
 {/* @skip-typecheck: incomplete code sample */}
 ```typescript title="workflows/chat/steps/tools.ts" lineNumbers
@@ -95,7 +95,7 @@ Key points:
 </Step>
 
 <Step>
-### Handle Data Parts in the Client
+### Handle data parts in the client
 
 Update your chat component to detect and render the custom data parts. Data parts are stored in the message's `parts` array alongside text and tool invocation parts:
 
@@ -143,7 +143,7 @@ The pattern is:
 
 Now, when you run the agent to search for flights, you'll see the flight results pop up one after another. This will be most useful if you have tool calls that take minutes to complete, and you need to show granular progress updates to the user.
 
-## Related Documentation
+## Related documentation
 
 - [Building Durable AI Agents](/docs/ai) - Complete guide to durable agents
 - [`getWritable()` API Reference](/docs/api-reference/workflow/get-writable) - Stream API details

package/docs/api-reference/index.mdx

@@ -17,9 +17,33 @@ All the functions and primitives that come with Workflow SDK by package.
     <Card title="workflow/api" href="/docs/api-reference/workflow-api">
         API reference for runtime functions from the `workflow/api` package.
     </Card>
+    <Card title="workflow/runtime" href="/docs/api-reference/workflow-runtime">
+        Runtime functions for resolving the World instance and the low-level World SDK, including storage and analytics queries.
+    </Card>
+    <Card title="workflow/observability" href="/docs/api-reference/workflow-observability">
+        Utilities to hydrate step I/O, parse display names, and decrypt workflow data.
+    </Card>
     <Card title="workflow/next" href="/docs/api-reference/workflow-next">
         Next.js integration for Workflow SDK that automatically configures bundling and runtime support.
     </Card>
+    <Card title="workflow/nitro" href="/docs/api-reference/workflow-nitro">
+        Nitro module for workflow bundling and runtime support.
+    </Card>
+    <Card title="workflow/nuxt" href="/docs/api-reference/workflow-nuxt">
+        Nuxt module for workflow bundling and runtime support.
+    </Card>
+    <Card title="workflow/sveltekit" href="/docs/api-reference/workflow-sveltekit">
+        SvelteKit Vite plugin for workflow bundling and runtime support.
+    </Card>
+    <Card title="workflow/astro" href="/docs/api-reference/workflow-astro">
+        Astro integration for workflow bundling and runtime support.
+    </Card>
+    <Card title="workflow/vite" href="/docs/api-reference/workflow-vite">
+        Standalone Vite plugin for workflow bundling and runtime support.
+    </Card>
+    <Card title="workflow/nest" href="/docs/api-reference/workflow-nest">
+        NestJS module for workflow bundling and runtime support.
+    </Card>
     <Card title="workflow/errors" href="/docs/api-reference/workflow-errors">
         Semantic error types for handling workflow storage backend failures.
     </Card>
@@ -27,7 +51,7 @@ All the functions and primitives that come with Workflow SDK by package.
         Serialization symbols for custom class serialization in workflows.
     </Card>
     <Card title="@workflow/ai" href="/docs/api-reference/workflow-ai">
-        Helpers for integrating AI SDK for building AI-powered workflows.
+        Deprecated AI integration APIs kept for existing applications. Use `@ai-sdk/workflow` for new agents.
     </Card>
     <Card title="@workflow/vitest" href="/docs/api-reference/vitest">
         Vitest plugin and test helpers for integration testing workflows in-process.

package/docs/api-reference/meta.json

@@ -4,7 +4,15 @@
     "workflow-globals",
     "workflow",
     "workflow-api",
+    "workflow-runtime",
+    "workflow-observability",
     "workflow-next",
+    "workflow-nitro",
+    "workflow-nuxt",
+    "workflow-sveltekit",
+    "workflow-astro",
+    "workflow-vite",
+    "workflow-nest",
     "workflow-errors",
     "workflow-serde",
     "workflow-ai",