AI SDK Workflow 2.0.95 Update: Stream Transform API Removed

The @ai-sdk/workflow package in the AI SDK ecosystem has released version 2.0.95. This is a patch update focused primarily on fixes and cleanup, with the core change being the removal of the experimental_transform option on WorkflowAgent.stream(), along with the deletion of the StreamTextTransform type export. For teams currently using this experimental API, this is a breaking change worth noting.

Why experimental_transform Was Removed

According to the release notes, stream transforms cannot reliably execute across workflow step boundaries. This limitation is not a minor implementation detail but an architectural constraint: workflow steps are independent execution units, while stream transforms rely on intercepting and rewriting a continuous output stream—the two are semantically in conflict. Keeping an option that silently fails in certain scenarios is riskier than removing it outright.

From an API design perspective, this adjustment sends a signal: experimental interfaces are decisively withdrawn when validation fails, rather than lingering indefinitely under an experimental_ prefix. For developers building production-grade workflow orchestration with the AI SDK, this means re-examining whether their code contains references to this option.

Execution semantics of workflow steps: In @ai-sdk/workflow, a workflow consists of several steps chained in sequence, each being a relatively independent execution unit with its own inputs, outputs, and lifecycle. Steps pass data through explicitly declared input/output contracts, and the orchestration layer handles scheduling order, error propagation, and state transitions. The benefit of this model is that each step can be individually retried, observed, and cached, but the cost is that continuous state cannot be naturally maintained across steps—when an upstream step finishes, its output is typically handed to the downstream as a whole value, rather than as a stream that can be continuously intercepted externally. Understanding this makes it clear why transforms relying on continuous interception break at step boundaries.

What to Check During Migration

The scope of this change is concentrated, and the migration actions are relatively clear.

Call Site

If your code passes experimental_transform to WorkflowAgent.stream(), you need to remove that parameter. After removal, stream output processing logic should be moved down into the step itself, or changed to post-process the final result outside the workflow.

Type Side

The StreamTextTransform type is no longer exported. Any TypeScript code that explicitly references this type will fail to compile and must switch to an alternative type or simply remove the relevant annotations. Since this is a type-level deletion, running tsc after upgrading will quickly surface all affected locations.

TypeScript type exports and breaking changes: StreamTextTransform is a type-level export that produces no runtime code itself. Deleting such an export won't cause compiled JavaScript to error, but it will cause all TS source files that explicitly import type it or use it as an annotation or generic parameter to fail at compile time. This is precisely why patch version numbers can also constitute breaking changes: semantic versioning typically focuses on runtime APIs, while additions and removals of type exports are often underestimated. Running tsc --noEmit first after upgrading is the lowest-cost way to catch such issues.

Dependency Chain

The release notes list numerous dependency updates, including ai@7.0.163, @ai-sdk/provider@4.0.36, @ai-sdk/provider-utils@5.0.75, and more. These coordinated updates indicate tight version coupling between the workflow package and the AI SDK core packages. Upgrades should be done as a whole to avoid mixing different generations of packages, which can lead to type mismatches.

Version coupling and peer dependencies in the AI SDK: @ai-sdk/workflow is built on the ai core package and @ai-sdk/provider/@ai-sdk/provider-utils, sharing message formats, tool definitions, and the type system. When the core package upgrades to a new major generation (e.g., ai@7.x), upstream packages typically need to align their internal type contracts accordingly. Mixing different generations of packages in a project may cause TypeScript errors due to structural type incompatibility, or result in the same entity being recognized as two different types across modules. Therefore, coordinated upgrades and locked consistent versions are standard practice for maintaining ecosystem packages like these.

Impact on Workflow Orchestration Practices

This removal points to a broader question: in step-based execution models like workflows, which capabilities should live inside a step and which can live at the orchestration layer. Stream transforms naturally belong to the output pipeline; elevating them to the agent level creates conflicts with step boundaries. A more reasonable approach is to let each step be responsible for its own output, with the orchestration layer concerned only with the input/output contracts between steps.

For projects that have already designed streaming processing logic around this option, short-term refactoring may be necessary. But in the long run, clear layering makes debugging and observability simpler—when issues arise, you can clearly determine whether it's an output anomaly from a specific step or a problem with the orchestration logic itself.

Upgrade Recommendations

This is a change under a patch version number but includes API removal, so it cannot be treated as a seamless upgrade. It's recommended to first upgrade on a separate branch and run type checks and integration tests, confirming there are no remaining experimental_transform references before merging into the main branch. For projects deeply dependent on streaming intermediate processing, evaluate whether equivalent capabilities need to be rebuilt at the step level rather than simply deleting the call.

FAQ

Is this update a breaking change?

Yes. Although the version number is patch-level, it removes public options and type exports, and existing code may fail to compile or change behavior.

Can stream transform effects still be achieved?

Yes, but at a finer granularity—for example, processing streams within a single step, or post-processing the final workflow output, rather than relying on a unified transform at the agent level.

Should dependent packages be upgraded together?

Yes, it's recommended to upgrade together. The workflow package has version coupling with core packages like ai and @ai-sdk/provider, and mixing them can easily cause type conflicts.

Background Notes

The tension between patch versions and breaking changes: According to semantic versioning conventions, incrementing a patch number should only include backward-compatible fixes. However, on 0.x versions or experimental APIs with the experimental_ prefix, maintainers often reserve the right to remove them at any time. The removal of experimental_transform in this release is essentially fulfilling the instability promise implied by the "experimental" label. When assessing upgrade risk, developers should not only look at the version number digits but also watch for signals in the changelog such as export deletions, signature changes, or prefix removals.

One-line Summary

@ai-sdk/workflow 2.0.95 removes the experimental_transform option—a breaking change under a patch version number.

Paragraph Summary

The @ai-sdk/workflow package has released patch version 2.0.95, with the core change being the removal of the experimental_transform option on WorkflowAgent.stream() and the corresponding deletion of the StreamTextTransform type export. The reason for removal is that stream transforms cannot reliably execute across workflow step boundaries—an architectural constraint rather than an implementation flaw. Since public options and type exports were removed, despite being a patch version number, upgrading may still cause existing TypeScript code to fail compilation or change behavior. The article recommends checking call-site parameters, type references, and the dependency chain during migration, moving streaming processing logic down into steps or changing to post-processing of the final result, and upgrading in coordination with core packages like ai and @ai-sdk/provider.