Skip to content
Docs

Durable agent approval workflows on Vercel

How enterprise architects choose a stack and decide where to run durable, human-in-the-loop agent approval workflows on Vercel.

Vercel

Agent approval workflows sit in an awkward middle ground. A single run can span seconds of model inference, hours of human review, and days of downstream side effects. Through all of it, the agent has to remember where it was, retry safely, produce a report a reviewer can trust, and enforce access controls on internal data.

That shape breaks the assumptions on which the usual tools are built. A request-and-response function expects to start, finish, and forget within a single invocation. Agent frameworks expect an in-memory state and a long-lived process. An approval run stops mid-thought for days and has to come back knowing everything it knew.

The standard workaround is to use an assembly: keep the agent loop in a framework like LangGraph, add Temporal as the durability engine, and stand up Postgres or Redis to hold the checkpoints. It works, and every seam becomes something the team builds, secures, and pays for before the first approval flow ships.

The Agent Stack collapses that assembly into one platform. An approval workflow runs on Vercel Workflows for orchestration, WorkflowAgent for the agent loop, AI Gateway for model calls, Vercel Functions for tool execution, and Vercel Blob for generated reports, with Secure Compute or Static IPs reaching internal APIs inside a private network.

Copy link to headingContents

Copy link to headingThe six parts of an approval workflow

A production approval workflow has six moving parts, whatever it runs on.

Moving partWhat it needsOn Vercel
Approval consoleA queue, the proposed change, approve and reject actions, live status of in-flight runsA Next.js app in the same project
Workflow runtimeSuspend on approval or sleep, resume on demand, no container idling betweenVercel Workflows
Agent loopTool calls that checkpoint, retry, and resumeWorkflowAgent from @ai-sdk/workflow
Tool executionCompute that bills nothing between steps, with a path to internal APIsVercel Functions on Fluid computeSecure Compute on Enterprise or Static IPs on Pro and Enterprise for private networks
Artifacts and reportsDurable object storage under the same auth as the appVercel Blob, or an external store
Model calls and notificationsOne endpoint for many models, and a route to where reviewers already workAI GatewayChat SDK for Slack or Teams, createWebhook and createHook for custom surfaces

Copy link to headingGate a tool call on human approval

The distinctive requirement of an approval workflow is a tool that calls an internal API and then waits for a person before acting. WorkflowAgent expresses both in one tool definition. A tool built with tool() from ai runs as a durable 'use step', retries on failure from the last checkpoint, and, when marked needsApproval: true, suspends the agent until a user responds hours or days later.

Install the packages with npm install @ai-sdk/workflow workflow. The @ai-sdk/workflow package requires ai and zod as peer dependencies, and the workflow package provides the runtime.

import { WorkflowAgent } from '@ai-sdk/workflow'
import { tool } from 'ai'
import { z } from 'zod'
const applyChange = tool({
description: 'Apply an agent-proposed change through the internal change API',
inputSchema: z.object({ changeId: z.string() }),
needsApproval: true, // suspends the run until a reviewer responds
execute: async ({ changeId }) => {
const res = await fetch(`${process.env.INTERNAL_API_URL}/changes/${changeId}/apply`, {
method: 'POST',
headers: {
authorization: `Bearer ${process.env.INTERNAL_API_TOKEN}`,
'content-type': 'application/json',
},
})
return { applied: res.ok, status: res.status }
},
})
export const agent = new WorkflowAgent({
model: 'anthropic/claude-sonnet-4-6',
tools: { applyChange },
})

A WorkflowAgent tool that calls an internal API and suspends until a reviewer approves

Each call to applyChange runs as a discrete, durable step and retries up to three times by default. For conditional gating, needsApproval also accepts an async function that decides per call from the tool's input. What is WorkflowAgent? covers the suspend and resume mechanics, and the AI SDK WorkflowAgent reference covers tool definitions and model resolution.

Copy link to headingDurable state without persistent containers

A run may wait 48 hours for a reviewer, then resume, then wait again. Holding that state in memory means holding a container open, which is what pushes teams onto Temporal or Kubernetes.

Vercel Workflows removes the container. A workflow suspends on any of three primitives and resumes when the signal arrives:

  • sleep: pause for minutes to months, with no upper limit on duration
  • createWebhook: wait for an HTTP call from an external system
  • createHook: wait for a typed in-app event, such as an approval decision

The runtime reconstructs the run's state upon receipt of the resume signal. WorkflowAgent extends the same guarantee to the agent loop itself, so a suspended tool call resumes with the exact message history, tool outputs, and pending decisions it had before. Context values span workflow and step boundaries, so keep them serializable and recreate non-serializable resources, such as database clients, within the step function that uses them.

Copy link to headingWhere the workflow runs in production

In production, the question shifts from what to build to what you operate. On Vercel the answer is a single project, and the platform holds the state.

  • Orchestration state: the durable state of every run, its message history, pending approvals, and step checkpoints, is held by the Workflows runtime in managed persistence. There is no checkpoint database to provision or operate, and no container is held open for a run while it waits for a reviewer.
  • Tool execution: each 'use step' runs as a function invocation on Fluid compute. Steps that call an internal API send their outbound traffic through Secure Compute or Static IPs into the private network.
  • The approval console: the Next.js UI, the workflow, and the tools deploy together, share one identity model, and read the same environment variables. Resuming a run is an authenticated route in the same app.

Three tradeoffs come with that choice:

  • Generality for one surface: Vercel Workflows targets web tooling, model tool calls, and human review. Coordinating Java services or Business Process Model and Notation (BPMN) models as first-class actors belongs in a dedicated engine, covered in the comparison below.
  • Cost while waiting: while a step runs, Fluid compute bills Active CPU; while a run is suspended, nothing executes, and no compute bills. Stored run state bills separately as Workflow Data Retained, alongside Events and Data Written (Workflows pricing). A multi-day approval costs storage cents, and an always-on container costs the container.
  • Egress-only: Secure Compute and Static IPs provide fixed outbound IPs to private networks but no fixed inbound IPs. An approval callback that must originate from a known source uses those egress IPs; an inbound trigger from an internal caller lands on an authenticated Vercel route.

Copy link to headingReaching private APIs from a public workflow

The most common enterprise objection is that internal tools reside in a private VPC, so the workflow must run there as well. Two separate concerns hide in that objection. Tool calls need a network path into the VPC, and orchestration state needs a home. Outbound connectivity from Vercel Functions covers the first while the state stays in the Workflows runtime. The workflow does not need to run inside your VPC for its steps to reach services inside it.

Two features provide that outbound path, and they differ in isolation and plan.

  • Vercel Secure Compute: creates a dedicated private network inside a VPC with static, unchanging IPs, a NAT Gateway, and VPC peering to your backend. Each customer gets a dedicated VPC and subnet, and each network reports its dedicated IP pair, AWS account ID, region, VPC ID, and CIDR block. You can include or exclude the build container from the network. Network creation is self-service via team Settings → Networking, though it is not available to all Enterprise teams; teams without it should contact their Vercel account team. Secure Compute is an Enterprise plan feature, and projects that use it do not support the extended max duration beta, which caps the maximum duration of individual tool steps.
  • Static IPs: provides static egress IPs from a shared VPC with subnet-level isolation, available on Pro and Enterprise at $100.00 per month per project plus Private Data Transfer at regional rates. It is egress only and does not provide fixed inbound IPs. If a project uses Secure Compute, Static IPs are ignored.

Choose Secure Compute when you need dedicated infrastructure, VPC peering, or complete network isolation, which is the common enterprise case for reaching internal systems. Choose Static IPs when a shared egress pool behind an IP allowlist is enough. In both cases the direction is outbound, so an approval callback that must originate from a known source uses these IPs, while an inbound trigger from an internal caller uses an authenticated Vercel route.

Copy link to headingWho approved what, and when

Any approval system has to answer who approved what, when, and with which inputs. The Vercel stack answers it from the workflow itself, without a separate logging pipeline.

Every tool call appears as a discrete step in the workflow dashboard with its inputs, outputs, retries, and timing. Approvals are recorded as workflow events, so the decision that resumed a suspended run is part of the same durable history as the tool call it gated. During local development, npx workflow inspect runs reads the same history from the terminal. Access to the history sits behind team controls, including SAML SSO, role-based access, audit logs, and encrypted environment variables.

Run history is retained after completion for 1 day on Hobby, 7 days on Pro, and 30 days on Enterprise, with custom periods available through support (storage retention). For audits that outlive retention, export the run's history to Vercel Blob as a final workflow step. The exported history is stored alongside the generated report, and together they form an audit bundle that lasts as long as the auditor needs.

Copy link to headingGenerated reports as first-class artifacts

Reports are part of the workflow's contract with the reviewer. The path from generation to the reviewer's screen:

  1. Generate inside a 'use step': the work is checkpointed and retried like any other step.
  2. Store through the @vercel/blob SDK: the store lives under the same auth and environment model as the rest of the project, with storage backed by Amazon S3 for durability. Derive the object key from stable identifiers of the run and step rather than a timestamp, and set allowOverwrite: true so a retried step writes the same key instead of failing. When data residency, existing lifecycle policies, or cross-cloud requirements dictate an external store, the step writes to S3, GCS, or Azure Blob Storage instead.
  3. Link from the approval console: the reviewer reads the report and records the decision against the same run.

Stored next to the exported run history, the report completes the audit bundle.

Copy link to headingWhen Vercel Workflows replaces Temporal, Step Functions, or Camunda

Vercel Workflows covers the same approval-flow ground as Temporal, AWS Step Functions, and Camunda when the flow is built from web tooling, LLM tool calls, and human review. Feature-by-feature comparisons live in the Workflow SDK docs for Temporal and Step Functions. Choose Vercel Workflows when:

  • The workflow is expressed in TypeScript alongside the UI that triggers it
  • Durability, retries, sleep, and human approval primitives are the core requirements
  • The team wants one deployment target for UI, workflow, and tools
  • Approvals resume through webhooks, chat surfaces, or authenticated app routes

Choose Temporal, Step Functions, or Camunda when:

  • Non-web systems like Java services, batch jobs, or BPMN process models need to participate as first-class workflow actors
  • A dedicated workflow engineering team already owns Temporal Cloud or a Camunda cluster
  • Regulatory or contractual requirements pin orchestration to a specific vendor or on-premise deployment

Vercel does not replace every workload. When one of the conditions above holds, integrate rather than migrate. A Vercel-hosted agent can call into Temporal or Step Functions as a step, and a Temporal workflow can trigger a Vercel Workflow through an HTTP endpoint. The boundary belongs at the systems that already own the process.

Copy link to headingHow the stack compares to LangGraph plus Temporal plus S3

A common assembly for the same problem uses LangGraph for agent orchestration, Temporal for durability, Postgres or Redis for LangGraph checkpoints, S3 for artifacts, and a separate Next.js or FastAPI service for the UI. That stack works, but each seam becomes something the team owns.

ConcernVercel stackLangGraph plus Temporal plus S3
OrchestrationVercel WorkflowsTemporal
Agent loopWorkflowAgent (@ai-sdk/workflow)LangGraph
DurabilityBuilt into WorkflowsTemporal plus Postgres or Redis checkpoints
Approval primitivesneedsApprovalcreateWebhookcreateHooksleepCustom, built on Temporal signals
Artifact and report storageVercel Blob or external object storeS3 or equivalent, wired separately
Internal API accessSecure Compute or Static IPsSelf-managed VPC, NAT, and IAM
Audit trailWorkflow run history in the dashboard, exportable to BlobAssembled from Temporal history and app logs
UI layerNext.js on Vercel, same projectSeparate service and deployment
Enterprise controlsSAML SSO, audit logs, encrypted env varsAssembled per component

One column is a project; the other is a portfolio of systems the team assembles, secures, and pays for separately.

The Vercel stack trades some orchestration generality for one deployment surface and built-in approval primitives. The LangGraph assembly trades operational weight for flexibility across non-web runtimes.

Copy link to headingFAQ

Does a run cost anything while it waits for approval? No compute. Functions bill Active CPU only while a step executes, and a suspended run executes nothing. Stored run state bills as Workflow Data Retained at $0.50 per GB-month (Workflows pricing).

Can workflow steps reach APIs inside a private VPC? Yes. Steps on Vercel Functions route outbound traffic through Secure Compute on Enterprise or Static IPs on Pro and Enterprise, while orchestration state stays in the Workflows runtime. Both paths are egress only.

How long is workflow run history retained? After a run completes: 1 day on Hobby, 7 days on Pro, 30 days on Enterprise, with custom periods available through support. For longer audit windows, export the history to Vercel Blob as a final step.

Can the workflow coordinate with an existing Temporal or Step Functions deployment? Yes. A Vercel-hosted agent can call either system as a step, and an external workflow can trigger a Vercel Workflow through an HTTP endpoint. Integrate at the boundary of the system that already owns the process.

Copy link to headingNext steps

More Vercel Workflows guides