WorkflowAgent
Build durable, resumable agents with the WorkflowAgent from @ai-sdk/workflow.
The WorkflowAgent from @ai-sdk/workflow is designed for building durable, resumable agents that run inside a workflow. It provides the same agent loop as the ToolLoopAgent, but adds automatic state persistence, tool schema serialization, and built-in tool approval flows that survive workflow step boundaries.
Why Durable Agents?
A standard ToolLoopAgent runs entirely in memory — if the process crashes, all progress is lost. For production agents that make multiple tool calls, this creates problems:
- Statefulness — Long-running agent loops need to persist state across process boundaries
- Resumability — If a step fails, you want to retry from the last checkpoint, not restart from scratch
- Human-in-the-loop — Tools that require user approval need to pause the agent and resume later
- Observability — Each tool call runs as a discrete workflow step, visible in dashboards
WorkflowAgent solves these by running inside a workflow, where each tool execution is a durable step with automatic retries.
When to Use WorkflowAgent vs ToolLoopAgent
| ToolLoopAgent | WorkflowAgent | |
|---|---|---|
| Package | ai | @ai-sdk/workflow |
| Runtime | In-memory | Workflow |
| Durability | Lost on crash | Survives restarts |
| Tool retries | Manual | Automatic (via workflow steps) |
| Human approval | Built-in | Built-in + survives suspension |
generate() method | Available | Available with durable non-streaming model calls |
stream() method | Available | Primary API |
| Stream output | streamText return value | writable parameter with ModelCallStreamPart |
For simpler use cases that don't need durability, use ToolLoopAgent from the ai package.
Installation
@ai-sdk/workflow requires Workflow 5, as well as the ai package and zod peer dependencies. The workflow package provides the Workflow DevKit runtime (getWritable, 'use workflow', 'use step').
Creating a WorkflowAgent
Define an agent by instantiating the WorkflowAgent class with a model, instructions, and tools:
Model Resolution
The model parameter accepts two forms:
Using the Agent in a Workflow
WorkflowAgent is designed to run inside a workflow function. The key integration points are:
- Mark your function with
'use workflow' - Pass
getWritable()to the agent'sstream()method - Start the workflow from your API route
End-to-End Example
Message Conversion
WorkflowAgent.stream() expects ModelMessage[], not UIMessage[]. When receiving messages from the client (via useChat), convert them first:
Writable Streams
Unlike ToolLoopAgent where you consume the returned stream, WorkflowAgent writes raw ModelCallStreamPart chunks to a writable stream provided by the workflow runtime via getWritable(). At the response boundary, use createModelCallToUIChunkTransform() to convert these into UIMessageChunk objects for the client:
The transform also forwards reset-step events emitted by WorkflowAgent on
retries.
Clients remove partial parts from the failed model-call step before processing
the retried output.
Resumable Streaming with WorkflowChatTransport
Workflow functions can time out or be interrupted by network failures. WorkflowChatTransport is a ChatTransport implementation that handles these interruptions automatically — it detects when a stream ends without a finish event and reconnects to resume from where it left off.
The transport requires your POST endpoint to return an x-workflow-run-id response header, and a GET endpoint at {api}/{runId}/stream for reconnection:
WorkflowChatTransport counts UIMessageChunk objects, while the durable
WorkflowAgent stream stores raw ModelCallStreamPart objects. Replay the raw
stream from index 0 and apply the non-negative UI cursor in
createModelCallToUIChunkTransform() as shown above. Negative start indexes
require a durable stream that already stores UIMessageChunk objects and
cannot be used with this raw-to-UI conversion.
For the full API reference, see WorkflowChatTransport.
Tools as Workflow Steps
Mark tool execute functions with 'use step' to make them durable workflow steps. This gives each tool call:
- Automatic retries — Failed tool calls are retried automatically (default: 3 attempts)
- Persistence — Results survive process restarts
- Observability — Each tool call appears as a discrete step in the workflow dashboard
Tools without 'use step' still work but run as regular in-memory functions without durability guarantees.
Tool Approval
For WorkflowAgent, human approval is configured on the tool definition with
needsApproval. This is specific to WorkflowAgent; for generateText,
streamText, and ToolLoopAgent, use toolApproval instead. When a workflow
tool has needsApproval set, the agent pauses and emits an approval request to
the writable stream. The workflow suspends until the user approves or denies:
Because the workflow is durable, the approval request survives process restarts — the user can approve hours later and the agent will resume.
Signed Tool Approvals
Client-supplied message history can be modified before it is replayed to the
workflow. For tools that perform sensitive operations, configure
experimental_toolApprovalSecret to authenticate approval requests:
The agent HMAC-signs the approval ID, tool call ID, tool name, and validated
input. When approved message history is replayed, a missing or invalid
signature prevents the tool from executing. The signature is preserved through
the durable model-call stream, createModelCallToUIChunkTransform(),
addToolApprovalResponse(), and convertToModelMessages().
Use a high-entropy secret of at least 32 bytes and make the same secret available to every worker that can issue or resume an approval. Keep old keys available while approvals signed with them are pending; changing the secret invalidates those pending approvals.
WorkflowAgent passes only the environment variable name into signing and
verification steps. Each step reads the secret from its local environment, and
the raw value is never included in step arguments, durable stream parts,
callbacks, or telemetry events. Configure the environment variable on every
worker, and do not put the secret value in runtimeContext or toolsContext.
You can also provide experimental_toolApprovalSecret to agent.stream().
The stream-level value overrides the constructor default.
Loop Control
Unlike ToolLoopAgent, WorkflowAgent does not apply a default step limit.
When stopWhen is omitted, it continues until the model stops calling tools or
another natural termination condition is met.
A model that repeatedly calls tools can make an unlimited number of model calls. Configure an explicit stop condition when you need to bound execution time and cost.
Control how many steps the agent can take:
Omitting stopWhen already lets WorkflowAgent continue until it has finished
calling tools. You can make that intent explicit with isLoopFinished():
isLoopFinished() is equivalent to omitting stopWhen for WorkflowAgent.
Use it with caution because a model that keeps calling tools can run
indefinitely and incur significant costs. See
isLoopFinished().
Structured Output
Parse agent responses into typed objects using Output:
Configuration Options
WorkflowAgent accepts the same generation settings as ToolLoopAgent (temperature, maxOutputTokens, topP, etc.) plus workflow-specific options.
runtimeContext and toolsContext
Pass server-side state through the agent loop without putting it into the prompt. Use these instead of the previous experimental_context option.
runtimeContextis shared agent state that flows throughprepareStep, lifecycle callbacks, andonEnd. Treat it as immutable; return a new value fromprepareStepto update it for the current and subsequent steps.toolsContextis a per-tool map keyed by tool name. Each tool'sexecuteonly sees its own validated entry ascontext. Tools that declare acontextSchemavalidate their entry against the schema before execution.
runtimeContext and toolsContext can also be passed per-call to stream(), where they override the constructor-level defaults.
Because WorkflowAgent runs inside the Workflow runtime, context values may be persisted and replayed across workflow and step boundaries. Keep runtimeContext, toolsContext, and any context values returned from prepareStep serializable. Use plain data such as strings, numbers, booleans, arrays, plain objects, dates, URLs, maps, sets, and other Workflow-supported structured data. Do not put functions, class instances, symbols, WeakMap, WeakSet, database clients, or SDK clients in context. Pass identifiers or configuration data instead, and recreate non-serializable resources inside step functions.
This differs from ToolLoopAgent, which runs in memory and can carry richer JavaScript values for the lifetime of a single process. With WorkflowAgent, treating context as durable data keeps workflow replay and step execution reliable.
experimental_sandbox
Pass a sandbox session when tools need an execution environment. The sandbox is
available to tool descriptions and execute functions as
experimental_sandbox, and to prepareStep, where you can override it for the
current step:
experimental_sandbox is a live runtime handle, not durable context. Do not
store it in runtimeContext or toolsContext. If a tool runs as a separate
workflow step, pass serializable sandbox identifiers or configuration and
reattach inside that step.
prepareCall
Called once before the agent loop starts. Use it to transform model, instructions, or other settings based on runtime context:
prepareStep
Called before each step (LLM call). Use it to modify settings, manage context, or inject messages dynamically:
Both prepareCall and prepareStep can also be passed per-call in stream().
Lifecycle Callbacks
Agents provide lifecycle callbacks for logging, observability, and custom telemetry. All callbacks can be defined in the constructor (agent-wide) or in stream() (per-call). When both are provided, both fire (constructor first):
For concrete tool sets, WorkflowAgentToolExecutionStartEvent and
WorkflowAgentToolExecutionEndEvent preserve the relationship between each
tool name and its input, context, and output types. TypeScript narrows the
nested toolCall directly, but use Extract or a user-defined type guard when
you need to narrow the correlated toolContext or output fields by tool name.
Tool input callbacks (onInputStart, onInputDelta, and
onInputAvailable) are also preserved by WorkflowAgent. The model call runs
inside a durable step, while callback functions remain in the workflow
context because arbitrary functions cannot cross the step boundary. As a
result, WorkflowAgent records the callback events during the model step and
replays them in order immediately after that step completes, before tool
execution and step lifecycle callbacks. They do not run concurrently with
model generation and cannot provide in-flight cancellation or backpressure.
Each callback receives its tool's toolsContext entry after
contextSchema validation.
For highly fragmented tool inputs, onInputDelta replay data is part of the
durable model-step result. Only configure onInputDelta when each generated
delta is needed; omit it to avoid retaining delta replay data.
The deprecated experimental_onStart and experimental_onStepStart names
remain available for backwards compatibility. When both the stable and
experimental name are provided in the same constructor or stream() call, the
stable callback is used.
Type Inference
Infer the UI message type for type-safe client components:
Migrating from DurableAgent
WorkflowAgent replaces the Workflow DevKit's DurableAgent. The two share the same core idea — a durable agent loop that runs inside a workflow — but WorkflowAgent moves the class into the AI SDK, tightens typing, and introduces first-class tool approval. If you are using DurableAgent today, follow the steps below to switch.
Change the import and class name
DurableAgent was exported from workflow/ai. WorkflowAgent is exported from @ai-sdk/workflow, alongside its helpers.
Install the new package alongside workflow:
Write ModelCallStreamPart, not UIMessageChunk
DurableAgent wrote UIMessageChunk objects directly to the writable returned by getWritable(). WorkflowAgent writes the lower-level ModelCallStreamPart shape and leaves the conversion to a transform at the response boundary. This keeps the durable stream provider-shaped and avoids baking a UI protocol into the workflow payload.
Replace maxSteps with stopWhen
DurableAgent accepted maxSteps directly. WorkflowAgent uses the AI SDK's shared stopWhen conditions so the same stop logic works across ToolLoopAgent, generateText, and streamText.
See Loop Control for the full list of stop conditions.
Replace experimental_output with output
The returned value is now on result.output (previously result.experimental_output).
WorkflowAgent: Use needsApproval for human-in-the-loop tools
With DurableAgent, tool approval was implemented by calling a Hook from inside the tool's execute function. WorkflowAgent makes approval a first-class tool property — the agent emits the approval request, suspends the workflow, and resumes automatically when the user responds.
needsApproval also accepts an async function so you can decide per-input
whether approval is required (see Tool Approval above).
uiMessages / collectUIMessages is gone
DurableAgent.stream() returned accumulated uiMessages when collectUIMessages: true was set. WorkflowAgent.stream() returns ModelMessage[] on result.messages instead.
For persistence, store UIMessage[] as your source of truth and call convertToModelMessages before passing them to the agent — this is the pattern described in Chatbot Message Persistence. There is no built-in ModelMessage → UIMessage conversion, so avoid persisting result.messages as your only copy if you need to render the conversation in the UI later.
Non-streaming generation
Use agent.generate() when you need the completed result without streaming:
Generation uses the provider's doGenerate() method and the same durable tool loop as streaming. It defaults to a maximum of 20 steps, while stream() remains unbounded unless you set stopWhen. Generation failures reject; stream model errors retain their existing result.error behavior.
The generated result uses core's final-step text and all-step content, tool results, warnings, and usage semantics. responseMessages contains generated messages only. output defaults to text and supports constructor or per-call output specifications. End callbacks run before complete-output parsing.
Use result getters inside the workflow, then return selected serializable fields through run.returnValue. Returning the whole result class is not supported. See the generate reference for options and remaining differences.
Approval round trips without streaming
Both generate() and stream() return approval requests even when no writable is provided. For generation, keep result.responseMessages, display the requested tool and input to the user, then append their decision to the next call:
Use the approvalId from the returned tool-approval-request and the user's approved decision. Preserve the request signature and original tool-call input when storing the conversation. Configure experimental_toolApprovalSecret with the same environment-variable reference for both invocations. Secrets are resolved inside durable signing and verification steps.
Local tools execute only after approval validation; denied tools produce an execution-denied result. Provider-executed approvals are forwarded to the provider. Tools that wait on Workflow hooks can also suspend and resume during generation.
Deadlines, cancellation, and replay
Inside a workflow, timeout sets an absolute deadline for model calls. Each model step checks it before dispatch, before SDK retry attempts, and after the provider returns. The same deadline remains in effect after a tool suspends and resumes. SDK maxRetries governs model retries; the durable model step does not add another retry layer. Expiration before dispatch rejects with TimeoutError; expiration during SDK retry backoff rejects with AbortError. Neither starts a new retry.
A model deadline does not cancel a tool waiting on a Workflow hook. The run can remain suspended after that deadline. Once the hook resumes, any subsequent model call fails before dispatch if the deadline has expired. To stop the suspended run, use the Workflow runtime's run.cancel() API. Cancellation does not undo external side effects that already happened.
Workflow reuses completed durable model and tool steps on replay. Put external side effects inside step functions and use the external service's idempotency mechanism where necessary: completed-step replay does not guarantee exactly-once effects for an interrupted attempt.
Generated files and result getters are available inside workflow code. Return the data the caller needs, for example:
The generated result class itself is not a supported run.returnValue shape. Request and response bodies are omitted unless explicitly enabled with include; available response headers, timestamps, IDs and provider metadata are retained. Workflow uses its existing callback shapes and preparation rules, and reports model response timing rather than complete tool/step timing. It does not implement ToolLoopAgent's callOptionsSchema abstraction or core's live streaming readers and HTTP response helpers.
Replace experimental_context with runtimeContext and toolsContext
WorkflowAgent no longer accepts experimental_context. Split the value into shared agent state (runtimeContext) and per-tool state (toolsContext); each tool's execute then receives only its own validated entry as context. See runtimeContext and toolsContext for the full shape.
Everything else
Other options carry over with the same names: prepareStep, onStart, onStepStart, onStepEnd, onEnd, onError, toolChoice, activeTools, timeout, repairToolCall, experimental_sandbox, and the usual generation settings (temperature, maxOutputTokens, topP, …). WorkflowAgent additionally adds prepareCall (runs once before the loop) and the onToolExecutionStart / onToolExecutionEnd lifecycle callbacks documented above. The deprecated experimental_onStart and experimental_onStepStart aliases remain available for backwards compatibility.
Next Steps
- WorkflowAgent API Reference for detailed parameter documentation
- WorkflowChatTransport API Reference for stream reconnection options
- Building Agents for the in-memory
ToolLoopAgentalternative - Loop Control for advanced stop conditions