AI Workflow With Vercel: Plan Steps, Retries, and Checkpoints

A Vercel AI workflow uses the AI SDK to sequence model calls, tool use, and routing logic inside serverless functions or edge routes. The serverless model adds a constraint the workflow design must account for: functions have a time limit, so long-running work must be broken into resumable steps.

The key design decision is what survives between steps. Runtime state — the conversation so far, tool results in flight — lives in the function. The task record, approved rules, and handoff history belong somewhere else. Tools like fenbs hold that lasting record so the next step, or the next session, starts from the same known state. AI workflows for education, research, and advertising are covered on their own pages.

Serverless constraints and what they mean for AI workflows

Vercel functions on the Hobby plan time out at 10 seconds; the Pro plan allows longer-running functions, and Edge Functions have their own limits. Check the current limits on Vercel's documentation rather than relying on any number here.

A model call with several tool steps can easily exceed a 10-second limit. The practical solutions are: stream the response to the client so the function does not need to wait for the entire completion, break the workflow into multiple function calls connected by state, or use a durable execution service for long-running tasks.

Each solution has tradeoffs. Streaming works well for interactive use but makes sequential multi-step logic harder. Multiple function calls require state storage between calls. A durable execution service adds infrastructure. Choose based on the workflow's latency requirements and complexity.

Planning resumable steps

A resumable step is one that can be restarted from a known state if the function times out or fails. Design steps to be idempotent: running the same step twice with the same input produces the same output and leaves the same external state.

Before each step, write a checkpoint to your state store. The checkpoint records the task id, the step number, the input, and any prior outputs. When the step completes, update the checkpoint with the result. If the function is interrupted, the next invocation reads the checkpoint and resumes from where it stopped.

• Step id: a unique, stable identifier for this step in the workflow. Do not use a timestamp — timestamps are not stable across retries.
• Input snapshot: the exact input to this step, so a retry uses the same data, not a re-fetched version that may have changed.
• Completion flag: a boolean or status field set only after the step fully completes. Check this first to skip already-completed steps on retry.
• Output: the step's result, stored before passing it to the next step.

Retries

The AI SDK's maxSteps setting limits how many tool calls an agent makes in one pass. For explicit retry logic across function invocations, you need your own retry mechanism at the workflow level.

A simple retry strategy records the attempt count in the checkpoint and compares it against a maximum. On the first failure, the workflow increments the count and re-queues. When the count reaches the maximum, it surfaces the task to a person instead of retrying.

Match the retry strategy to the error type. A 429 rate-limit error warrants a delay and retry. A malformed model output warrants a different prompt or a fallback model, not a plain retry. An error in an external service the workflow calls warrants human review before any retry that might repeat the same external action.

Human review checkpoints

Some steps should pause and wait for a person before continuing. A workflow that drafts a message for a client should stop before sending it. A workflow that modifies database records should stop before committing.

Implement human review as a state field in the checkpoint. The step writes the draft or proposed action to the state, sets the review status to "pending", and stops. A notification tells the reviewer what is waiting. When the reviewer approves, the workflow picks up from the checkpoint with the approved state.

The AI agent approval workflow guide covers the full review pattern in detail.

Keeping the work record outside the function

A serverless function is ephemeral. Everything it holds in memory ends when it ends. The work record — what the workflow was trying to do, what was approved, what was completed, and what remains — must live in a store the next function invocation can read.

The Vercel AI SDK overview covers the SDK's built-in capabilities in depth. What the SDK does not provide is a human-readable task record with decision history. That needs a separate store.

How to do this with fenbs

1. Create a free account and add the workflow as a project in fenbs. Model each major phase as a task with its input requirements and completion conditions.
2. Write the approved rules in Decisions and rules: which steps need human review, what the retry limits are, which models are authorized for which steps. Connect your AI assistant from Integrations.
3. At the start of each function invocation, the agent reads the project context from fenbs, including the rules and Where we left off, before reading the checkpoint.
4. At the end of each invocation, the agent updates the task in fenbs with what happened, what it produced, and where the next invocation should start.
5. When a human review is needed, create a task in fenbs with the proposed action and mark it waiting for review. The reviewer acts in fenbs, and the next invocation reads the approved decision.

fenbs works alongside your checkpoint store, not instead of it. The checkpoint holds the low-level, per-step state the function needs to resume. fenbs holds the high-level task record a person reads to understand what the workflow is doing and why.