AI SDK 6 was already "good enough" for a lot of product chat. Typed streams, provider swaps, tool calls that did not feel like a science project. AI SDK 7, shipping around June 25, is a different pitch: stop treating the agent as an in-memory loop that dies when the deploy rolls, and start treating it as something that can pause for approval and wake up hours later.
That is the part worth arguing about. Not whether your roadmap now says "agents" in every slide.
What actually changed for production
The headline primitive is `WorkflowAgent` from `@ai-sdk/workflow`. Same general tool-loop idea as the lighter in-memory agent, but each tool execution sits inside a workflow step. State persists between steps. Restarts, timeouts, and delayed approvals stop meaning "start the whole run over and hope you did not charge the card twice."
Tool approval is first-class. Mark a tool with `needsApproval`, the run suspends, the user (or an internal reviewer) approves or denies later, and the workflow resumes. Higher-risk flows can revalidate inputs and bind approvals more tightly so the args that execute are the args that were approved. That is the difference between a demo HITL checkbox and something I would put near a deploy or billing mutation.
There is also a pile of "platform" surface: typed runtime and tool context, timeouts as real budgets, telemetry hooks, MCP Apps, a terminal UI for poking agents before you wire the product UI, provider-agnostic `reasoning` on `generateText` / `streamText`. Useful. Secondary to whether your loop survives contact with production process lifecycle.
The migration tax is not theoretical
Node 22 minimum. ESM required — `import` or `.mjs`, not a comfortable CommonJS `require` forever. Codemods and a migration skill exist; they will not decide your runtime policy for you. Instruction and message shapes move. Runtime context and tools context split. Stream helpers and multi-step result shapes change enough that "it typechecks" is a weak definition of done.
If you are on AI SDK 6 with a short chat widget, a greenfield v7 bump can wait. If you already fake durability with a homegrown table of run rows and a brittle resume path, the tax may be cheaper than maintaining your private WorkflowAgent.
I would not upgrade a monorepo "because agents." I would upgrade the package that owns long-running tool loops with side effects, then leave the marketing chatbot alone until the smoke clears.
1import { tool } from 'ai'2import { z } from 'zod'34// Keep approval on the irreversible edge, not every read.5export const applySchemaMigration = tool({6 description: 'Apply a reviewed database migration in staging',7 inputSchema: z.object({8 migrationId: z.string(),9 checksum: z.string(),10 }),11 needsApproval: true,12 execute: async ({ migrationId, checksum }) => {13 // runs only after approval survives the workflow boundary14 return runMigration({ migrationId, checksum })15 },16})
When WorkflowAgent is the right adoption reason
Use it when the agent must outlive a single serverless invocation: multi-step research that calls tools, waits on a human, then continues; ops agents that open a PR and pause for review; anything that would be an incident if a deploy mid-run duplicated a side effect.
Use the approval path when the tool can spend money, mutate schema, touch prod-adjacent systems, or ship code. Do not put `needsApproval` on `readRepoFile` and then wonder why nobody likes the product.
Use provider-agnostic `reasoning` when you actually swap providers and are tired of three parallel config dialects. Do not treat it as a quality upgrade by itself — providers still disagree on what "high" means.
When I would wait
If the feature is a single-turn generate with one tool and no resume story, stay put. If your runtime is still on Node 20 and the rest of the fleet is not moving, do not make AI SDK the reason you fork the platform. If you have not defined session id, budget, and approval points, a durable framework will just persist a mess — longer.
AI SDK 6 maturity was about whether the SDK was ready for serious app work. v7's question is narrower: do you need durable, approvable agent loops enough to pay for Node 22, ESM, and a real migration pass?
My bar for merging the upgrade
A run can pause on a mutating tool, survive a deploy, and resume with the same session identity. Approvals bind to the args you care about. Timeouts fail loudly instead of hanging a queue worker. Telemetry shows step boundaries a human can use during an incident. Eval coverage includes at least one interrupted-and-resumed path.
Hit that bar and WorkflowAgent earns its keep. Miss it and you have renamed your chat loop, upgraded the Node line, and added "agent platform" to the README without changing the failure mode that burned you last quarter. Adopt for resumable loops and approvals. Leave the buzzword on the launch blog.