DurableAgent/WorkflowAgent duplicates doStreamStep return size

[VaguelySerious]

In DurableAgent, chunks and step return contain the same data after chunksToStep runs, and both are serialized through the step boundary, causing unnecessary data transfer when chunksToStep could also be run in the workflow layer.

[shtefcs]

+1, hitting this in production. Running V2 DurableAgent on workflow@5.0.0-beta.7, @workflow/ai@5.0.0-beta.4, world-vercel@5.0.0-beta.6. Most-impacted flows are coding agents that emit large tool outputs (sandbox build logs, browser snapshots, web search payloads), where the chunks echo of each step output adds roughly 2x bandwidth on every step transition.

App-layer mitigations we've already applied if useful as reference for what's left after exhausting the user-facing levers:

• collectUIMessages: false on every agent.stream call site
• pruneMessages (from ai) capping tool calls/results to the last 5 messages
• Pre-step summarization of any tool result >50KB via a cheap model (Gemini 3 Flash) before it enters the history
• Rolling history summarization once message count exceeds 60

After all of the above the remaining serialized payload per step is dominated by (a) inherent message history for the LLM input and (b) the chunks duplication this issue is about. (a) is unavoidable. (b) is the one we can't reach from the app.

Happy to share concrete payload sizes from production traces if it helps with prioritization.

[VaguelySerious]

@shtefcs If you're open to help experiment, could you try https://workflow-tarballs-git-peter-issue-1929-reduce-stream-ste-ebf8eb.labs.vercel.dev/workflow-ai.tgz and see if this meaningfully reduces payload sizes for you?

[shtefcs]

@shtefcs If you're open to help experiment, could you try https://workflow-tarballs-git-peter-issue-1929-reduce-stream-ste-ebf8eb.labs.vercel.dev/workflow-ai.tgz and see if this meaningfully reduces payload sizes for you?

tnx, I will test this out, but I need to merge few git work trees with the new Workflow and test around. After that I will give a test with ur latest tarball.

[VaguelySerious]

This is fixed in the latest beta release, going out today, and then ported to WorkflowAgent soon.

[shtefcs]

Thanks for the fast turnaround on both of these, really appreciate it.

One question on the WorkflowAgent side. We're moving our durable coding agent off DurableAgent onto @ai-sdk/workflow's WorkflowAgent. We hit #1835 (the reasoning-delta orphan-chunk crash on resume) in production and are currently patching it ourselves, and the request.body payload was our other big cost.

Is the plan to land both fixes in @ai-sdk/workflow, the request.body reduction from #1932 and the orphan-chunk filter from #2082, inside its WorkflowChatTransport? Right now 1.0.2 has the smaller step body but not the orphan filter. If both are coming, we'd rather time our migration to pick them up natively instead of carrying local patches. Any rough sense of when the orphan filter ports over would help us plan.

[VaguelySerious]

@shtefcs Yes, all the recent fixes to DurableAgent and WorkflowChatTransport should be landing in @ai-sdk/workflow over the coming two weeks

[shtefcs]

Follow-up now that I actually tried the WorkflowAgent migration on our durable coding agent.

Following the documented pattern (WorkflowAgent instantiated and streamed inside a "use workflow" function, with getWritable), the build fails with:

[plugin: workflow-node-module-error] You are attempting to use "ai" which depends on Node.js modules. Packages that depend on Node.js modules are not available in workflow functions.

It traces to @ai-sdk/workflow@1.0.2 statically importing ai and ai/internal values at the top of its entry, which leaks ai Node deps into the workflow sandbox when WorkflowAgent is imported into a "use workflow" file. Our bundler does not seem to isolate @ai-sdk/workflow internal "use step" boundaries the way it does for our own code.

Stack: @ai-sdk/workflow@1.0.2, ai@7.0.2, workflow@5.0.0-beta.24, Next.js with withWorkflow, self-hosted (WORKFLOW_TARGET_WORLD).

Two questions:

1. What workflow runtime version does @ai-sdk/workflow@1.0.2 target? Latest published workflow is 5.0.0-beta.24 and stable is 4.5.0, and @ai-sdk/workflow shipped after both, so I am not sure which pairing is correct.
2. Is there a withWorkflow or next.config setting (transpilePackages, serverExternalPackages, etc.) needed so the bundler processes @ai-sdk/workflow "use step" boundaries and keeps ai out of the workflow sandbox?

Happy to share a minimal repro.