@ai-sdk/workflow@1.0.0
Major Changes
Patch Changes
-
19736ee: feat(ai): rename onStepFinish to onStepEnd
-
382d53b: refactoring: rename context to runtimeContext
-
b567a6c: dependency updates
-
b402b95:
WorkflowAgentnow rejects system messages insidepromptormessagesby default, matching the behavior ofgenerateText/streamText. SetallowSystemInMessages: trueto opt in to the previous behavior. -
eea8d98: refactoring: rename tool execution events
-
98627e5: feat(ai): remove onChunk event from telemetry
-
ca446f8: feat: flexible tool descriptions
-
75763b0: agents: tag outgoing requests with an ai-sdk-agent user-agent segment for usage attribution (tool-loop, workflow)
-
9f0e36c: trigger release for all packages after provenance setup
-
29d8cf4: feat(ai): rename the core-event types
-
7fc6bd6: Raise minimum supported Node.js version to 22. Supported versions: 22, 24, and 26.
-
a0ca584: fix (workflow): preserve invalid tool calls as errors instead of emitting synthetic success results
-
eba685c: Remove
maxStepsoption fromWorkflowAgent. UsestopWhenwith stop conditions likeisStepCount()instead. -
0c4c275: trigger initial canary release
-
258c093: chore: ensure consistent import handling and avoid import duplicates or cycles
-
334ae5d: Update step performance metrics with explicit effective, input, output, and total token throughput fields.
-
b8396f0: trigger initial beta release
-
c3d4019: chore(ai): rename 'TelemetrySettings' to 'TelemetryOptions'
-
083947b: feat(ai): separate toolsContext from context
-
bae5e2b: fix(security): re-validate tool approvals from client message history before execution
The approval-replay path in
generateText/streamText(andWorkflowAgent.stream) reconstructed approved tool calls from the client-supplied messages array and executed them without re-validating input against the tool's schema or re-applying the approval policy. A client could forge an assistant message with a pre-approved tool-call part and have the server execute a tool with attacker-chosen arguments.The replay path now validates HMAC signature (when
experimental_toolApprovalSecretis configured), re-validates tool-call input against the tool's input schema, and re-resolves the approval policy before execution. -
d775a57: feat: introduce Instructions type
-
f32c750: refactoring(ai): simplify mergeAbortSignals
-
bf6c17b: Add
idproperty to WorkflowAgent for telemetry identification, matching ToolLoopAgent's API surface. -
3ca592a: Add
promptas an alternative tomessagesinWorkflowAgent.stream(), matching theAgentCallParameterspattern from ToolLoopAgent. -
eb49d29: Add constructor-level defaults for
stopWhen,activeTools,output,experimental_repairToolCall, andexperimental_downloadto WorkflowAgent, matching ToolLoopAgent's pattern. Stream-level values override constructor defaults. -
0455f24: Enrich WorkflowAgent callback event shapes to align with ToolLoopAgent:
- Add
stepNumbertoonToolCallStartandonToolCallFinish - Add
steps(previous step results) toonStepStart - Adopt discriminated union pattern (
success: true/false) foronToolCallFinish - Add
durationMstoonToolCallFinish
- Add
-
43543dc: Add
experimental_sandboxsupport toWorkflowAgent. The sandbox is passed to tool execution, configurable on the constructor or per stream, and available toprepareStepfor per-step overrides. -
0e462a7: Use
LanguageModeltype for model parameter, aligning withToolLoopAgent. Remove async factory model form. Rename callback types to useWorkflowAgentOn*prefix. -
39dad72: feat(workflow): add stable telemetry integration support to
WorkflowAgentand remove legacy telemetry options. -
1e4b350: Honor
tool.toModelOutputinWorkflowAgent.WorkflowAgentnow routes successful local, provider-executed, and approved tool results through each tool's optionaltoModelOutputhook, matchinggenerateText,streamText, andToolLoopAgent. Previously the hook was ignored and results were always serialized astextorjson.Internally exports the shared tool-result model-output helpers from
ai/internal, and uses the sharedgetErrorMessagebehavior for workflow tool error results. -
c3a6524: Add a
stepNumberoption todoStreamStepso callers can createStepResultobjects with the correct step number. -
907e002: fix (workflow): forward provider-executed tool approvals to the provider on resume
WorkflowAgentstripped everytool-approval-requestandtool-approval-responsepart from the messages when resuming after a tool approval, regardless of whether the tool was locally or provider-executed. For provider-executed tools (e.g. MCP via the OpenAI Responses API) this silently dropped the approval beforeconvertToLanguageModelPromptcould forward it, so the provider never learned of the approval and the tool was never executed. Local approvals are still executed and stripped, while provider-executed approvals are now preserved and forwarded to the provider, matching the discriminator core'sstreamTextalready uses. This is the inverse of the bug fixed in #14289. -
1d56275: feat(workflow): add
runtimeContextandtoolsContexttoWorkflowAgent.runtimeContextis shared agent state that flows throughprepareCall,prepareStep, step results, andonFinish.toolsContextis a per-tool map; each tool receives its own validated entry ascontext, validated againsttool.contextSchemawhen defined. The previousexperimental_contextoption (and corresponding fields on related callbacks and option types) has been removed — useruntimeContextfor shared state andtoolsContextfor per-tool values. Context values inWorkflowAgentshould be serializable because they can cross workflow and step boundaries. -
81e68da: Fix
stepNumberon telemetry events emitted byWorkflowAgent.streamso per-step telemetry integrations (e.g.@ai-sdk/devtools) correctly key state per step. -
69d7128: fix(workflow): reuse the core tool-approval validation in WorkflowAgent
WorkflowAgent.streampreviously reconstructed approved tool calls with a copy of the core collection logic and validated them inline. Because the logic was duplicated, it could drift from the hardenedgenerateText/streamTextimplementation. WorkflowAgent now collects approvals via the sharedcollectToolApprovalsand re-validates each one through the sharedvalidateApprovedToolApprovals(input-schema re-validation, HMAC signature verification when configured, and approval-policy re-resolution) in addition to its existingneedsApprovalguard, so a client-forged approval cannot execute a tool with unvalidated input. The duplicated collector was removed;collectToolApprovalsandvalidateApprovedToolApprovalsare now exported fromai/internal. -
fbea042: refactor: replace duplicate
filterTools/filterToolSetwith sharedexperimental_filterActiveToolsfromai