Workflow DevKit splits an agent into a deterministic workflow and retryable steps whose inputs and outputs are persisted.
2
Streams remain available after an API connection is lost, so a client can reconnect and continue receiving an agent's output.
3
Sleep and web hooks let an agent pause for days or weeks without consuming compute, then resume after a timer or human action.
Summary
Peter Wielander demonstrates how to turn a TypeScript coding agent into a durable workflow with Vercel's Workflow DevKit and AI SDK. The starting app uses an AI SDK agent, tools backed by Vercel Sandbox, and a streamed chat interface. The refactor moves the agent loop into a workflow function, marks model calls and tools as steps, and starts the workflow through the Workflow API. Steps run independently, with cached inputs and outputs, retries, and observability. Wielander then adds streams that can be resumed after a dropped connection, a sleep tool for long pauses, and a web hook for human approval. He also explains deployment adapters, workflow inspection, concurrency, cancellation, version upgrades, and the separation between workflow orchestration and the sandbox where code executes. The talk is practical and honest about the beta status and the responsibility developers retain for step side effects and permissions.
Workflow DevKit replaces queues, state storage, retries, and tracing code with one orchestration layer
Wielander begins with the production work that surrounds an agent: queues for long-running work, a database for messages and state, error and retry handling, and an observability layer. Workflow DevKit provides these pieces for TypeScript applications and can run on different clouds. The workflow separates orchestration from steps. In the coding agent, the workflow is the loop between model calls and tool calls, while each model or tool operation can run in isolation, be retried, and have its data persisted.
The example starts as a small AI SDK coding agent backed by sandbox tools
The workshop uses an open-source example from the Vercel examples repository. The application accepts a prompt, generates files, runs commands in a Vercel Sandbox, and eventually displays an iframe with the finished application. Its endpoint checks the model, creates an AI SDK agent, passes in tools, and streams chunks to the client. The four tools create a sandbox, retrieve its URL, run a command, and generate a file. The front end uses useChat from AI SDK to consume the stream.
A workflow function must be deterministic, while model calls and tools become steps
Wielander moves the agent code into a separate code workflow and adds the use workflow directive. The compiler places the workflow code in a separate bundle and rejects imports with side effects because the orchestration function must be deterministic when it is rerun. A durable agent class marks the underlying model calls as steps. Each tool's execute function gets a use step marker. In production, a step runs in its own serverless instance, its inputs and outputs are cached, and a failed step can be retried.
Streams belong to the workflow run, so clients can reconnect after losing the API connection
The workflow gets a writable stream associated with its run, instead of writing directly to the API handler's stream. Tools can obtain the same writable and write data packets that the UI understands, such as a sandbox creation event and its sandbox ID. Wielander explains that streams are not bound to the lifetime of the API request. The API returns the workflow run ID, and a second route can use that ID to retrieve the run and return its stream from a chosen start index. The client can then reconnect and resume from where it stopped.
Sleep pauses a workflow without holding a serverless instance
The workflow can call sleep with a duration such as three days. The workflow pauses and consumes no resources during that period, then resumes at the next line. Wielander gives recurring work as an example: an agent can sleep for a day, read email, perform its work, and sleep again. Completed step events and outputs are stored, so if the process is later killed, the workflow can be rehydrated and continue without repeating completed work or consuming resources to replay it.
Web hooks provide a durable pause for human approval
The web hook example creates a URL, logs it for the client, and awaits the hook inside the workflow. The run pauses until someone calls the URL. In local development, the URL is local; in production, it uses the deployment URL. The hook can also return a response, behave like an API endpoint, and validate its body against a result schema before allowing the workflow to resume. Wielander shows the paused run continuing after a human clicks the approval link, after which the agent codes a Pokédex.
Workflow orchestration does not provide the execution sandbox or agent permissions
Wielander separates Workflow DevKit from Vercel Sandbox. The workflow is a general durable orchestration layer. Sandbox creates a new VM for running commands and storing files for the coding agent. Permissions remain the developer's responsibility through model providers, tools, and sandbox configuration. A tool that can delete an S3 resource still has that power when called by the agent. Developers also need to make step side effects safe to retry, since steps can have side effects even though the workflow layer itself is deterministic.
Deployments, adapters, and concurrency determine how runs are managed
A workflow is tied to the deployment from which it was started. If code is deployed again while an older run is active, the old run continues on its original deployment and new runs use the new one. The system can list active runs, show their deployment version and current step, and cancel them. Wielander says runs can be started without a fixed limit in the serverless model, subject to available provider compute. Planned controls allow a workflow or step to have a concurrency limit, with additional starts waiting in a queue.
Version compatibility and observability are built around recorded step signatures and events
Each deployment can have a workflow version, and the run records which version it uses. Workflow DevKit can compare stored step signatures, inputs, outputs, and events with a newer deployment before upgrading a run. If an in-place upgrade is not possible, developers can cancel runs and restart them on the new version. For observability, the open-source UI displays step spans, inputs, outputs, and events. Wielander also describes exporting OpenTelemetry data and adding workflow context before sending it to systems such as Datadog.
"A workflow pattern is essentially a sort of orchestration layer that separates your code into steps that can run in isolation and can be retried and have their data persisted."03:42
Who should watch
You have an AI agent that works locally but needs retries, persisted state, and inspection in production.
Your chat or agent session must survive dropped connections or wait for human approval before continuing.
You are deciding whether durable orchestration belongs in your agent framework or in a separate sandbox and deployment layer.
