Vercel released `durable-harness` on October 20, 2026. It runs an AI agent so that a crash, a function timeout or a redeploy does not kill the job it was doing. Each agent session is kept in a durable log: the conversation, the turn in progress and every model call and tool call. When the function running a turn dies, a new one reads the log and carries on from where the first stopped. Vercel's launch post on X says agents built this way can run for hours, days or months.
It supports Pi, OpenCode, fx and eve, plus Claude Code and Codex as experimental options. This post explains how it recovers, what the replay rules mean for steps that touch money or customers, and when a business needs this kind of setup at all.
We read these Vercel docs pages on October 21, 2026: Running agent harnesses durably on Vercel, Tools, files, and documents and Security for durable agent harnesses. Every Vercel fact below comes from those pages. We have not run `durable-harness` in production.
The problem it solves
An agent harness is the loop around a model: its prompts, its tools and how it manages what the model sees. Most harnesses keep the current turn in the memory of the process running it. If that process dies halfway through, the turn dies too. Someone has to notice, restart it, and hope the agent does not repeat work it already did.
For a coding agent, repeating work wastes time and money. For a business agent, repeating work can mean a customer refunded twice, two copies of the same email, or a duplicate invoice.
How recovery works
Each turn has a message on Vercel Queues behind it. If the function running the turn fails with an error, another function picks the turn up right away. If the function disappears without an error, for example because it ran out of memory, the queue delivers the turn again once its lease runs out. Either way, the new function reads the log and continues:
- A model call that was running when the crash hit runs again.
- A model call or tool call that already finished is read back from the log and never runs again.
- A tool call that was running when the crash hit follows its replay rule.
Vercel's docs use a support agent as the example. It refunds an order, and its function dies while it is writing the reply to the customer. A new function reads the log, runs only the interrupted model call again, and the customer is refunded once.
A turn can also run longer than a single function's time limit, and a browser that disconnects can reconnect to a turn that is still running.
Replay rules, in plain terms
Every tool you give the agent gets one of two rules:
- 1`safe`: the tool can run again after a crash. Looking up an order, reading a calendar or searching a knowledge base are safe, because running them twice changes nothing.
- 2`never`: the tool never runs twice on its own. If a crash interrupted it, the agent is told the action may or may not have happened, so it can check before trying again. Before a `never` call starts, every harness waits until the log has recorded it.
Vercel's own example marks `get_order` as safe and `refund_order` as never. The security docs add a second layer for any tool that changes something, such as a refund or an email: use `never` and also pass an idempotency key to the system the tool calls, so that if the model itself asks for the same action twice, the effect still happens once.
That is the same rule we use for webhooks, explained in our post on webhook idempotency for AI agents. A crash-safe harness does not remove the need for it.
One edge case is worth knowing. A call that finished just before the crash may not be in the log yet, and then it counts as running. That is exactly why the `never` rule and the idempotency key both matter for money and messages.
What the security docs require
The Vercel docs are strict about where the agent's work runs. Your own tools run in your function and are trusted code, but the model writes their arguments, and a prompt injection in a web page, file or message can steer those arguments. So the docs say to check every argument against what the tool allows, to work out who the user is from the session and your own records rather than from an argument the model sends, and to keep arguments out of shell commands and file paths.
Commands and files the model chooses never run on your function's disk. They run in a virtual workspace kept in the log, or in a Vercel Sandbox (a virtual machine for the session). Claude Code and Codex run only in a Sandbox, one per session, and the Sandbox holds no secrets. A Sandbox allows all outbound traffic by default, so the docs recommend blocking it or allowing only the hosts the agent needs. Model spend has no cap unless you set a budget. In production, a chat route with no authorization check refuses every request.
What a business would use this for
These are designs we would consider. None of them describes a client result.
- 1A support agent that can issue small refunds. Order lookups are `safe`. The refund tool is `never`, carries an idempotency key built from the order and the session, and only runs under a set amount; anything larger becomes an approval request, as in our post on agent action budgets.
- 2A long research or reporting job. An agent that reads dozens of supplier pages or CRM records over an hour can resume from the log instead of starting over after a timeout.
- 3An agent that keeps working through deploys. If you ship site updates several times a day, a turn that is running during a redeploy resumes from the log instead of being lost halfway.
For any of these we would first list every tool, mark each one `safe` or `never`, add idempotency keys to every tool that writes, and then test by killing the function mid-turn on purpose to confirm nothing runs twice. We would also trace each run, as covered in our post on agent tracing with OpenTelemetry.
When this is not worth it
Most business automation does not need a durable agent harness. If a job follows fixed steps, such as copying a form into a CRM or sending a reminder, a workflow tool or a scheduled script with retries is simpler and cheaper. If an agent turn takes a few seconds and only reads data, a crash just means asking again. And if your site does not run on Vercel, this package is one option among several durable execution tools; the Vercel docs describe self-hosting the log in another store such as Postgres, but you would still be adopting Vercel's packages.
A durable harness earns its place when an agent runs long, takes actions that cost money or reach customers, and would be painful to restart by hand. Our self-hosted AI agent deployment checklist covers the other parts of running an agent you rely on.
How this fits implementation work
OrchestriAI is not a Vercel partner or reseller. We build AI agent systems and custom software where each tool has clear limits and every action that changes money or customer data runs once. If you want to know which of your processes need a long-running agent and which are fine as plain automation, start with the free automation audit.
Independence and limitations
OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Vercel. This article summarizes Vercel's public documentation as of October 21, 2026. Claude Code and Codex support is marked experimental, and the docs list current limitations, so confirm the details in Vercel's documentation before you build on it.
