Approvals that wait for days: what Vercel Workflows costs, keeps and forgets

If your agent has to wait days for a landlord, a manager or a client to say yes, and today that wait lives in a cron job and a status column, this is for you. Vercel Workflows is built for that wait. It costs little to run; the decisions are about what it keeps, for how long, and where. It is not for a team whose run state must stay in the Gulf: no Vercel region is there.

Why do agents that wait for people break?

The model is rarely the part that fails. The wait is. An agent that asks a landlord in London to approve a repair quote may wait an hour or a week. In that time you deploy new code, a function times out, a server restarts. A homegrown version keeps the state in a table and polls it with a scheduled job, and every deploy is a chance to send the reminder twice or never.

That is the durable plane on our architecture map: the write is the risk, and a retry that posts twice is a write you did not mean.

What does Workflows do with the wait?

It turns the wait into a step the platform remembers. Vercel's docs list JavaScript, TypeScript and Python, the last through the vercel Python SDK. You mark a function with "use workflow" and its parts with "use step". Vercel's docs say the result is durable code that "can retry failed steps, wait for external events, and resume across crashes and deployments". On Vercel, Functions run the code, Vercel Queues dispatch each step, and managed persistence stores the state and the event log.

Three behaviours matter for a long approval:

• It parks. A sleep, or a wait on a hook for an outside event such as an approval link, uses no compute. The limits page lists no maximum run duration and no maximum sleep duration.
• It replays. After a crash or a deploy, the run replays its log and continues from the last finished step.
• It keeps its version. Vercel's page says "running workflows continue on their original version while new executions use the latest code", so a deploy on Tuesday does not change a run that started on Monday.

Here is a sample plan, labelled as one, for a property manager whose landlords live abroad.

1. 01A tenant complaint arrives and becomes a work order in your maintenance system.
2. 02The run asks the contractor for a quote and waits for it.
3. 03The run sends the quote to the landlord and waits on an approval hook.
4. 04No answer in 48 hours: it sleeps, then sends one reminder. The run itself never times out.
5. 05Approved: the contractor is booked and the decision, who approved and when, is written to the work order.

Step 4 is where a small model earns its place. A landlord answers in free text: "ok go ahead", "too expensive", "call me". A decision model sorts that reply into approve, reject or needs a person, and anything below the threshold goes to your team, not to the contractor. We set up Jev, TypeSafe's decision model, for clients (Jev page), so weigh that suggestion with that in mind.

For the building side, see Mindcat for property management. If the gap is complaint to closed job, Mindcat Maintain is our app for it, hosted in the UAE or the Kingdom.

What does a long approval cost?

Almost nothing in events. Every state change in a run is stored as an event, and Vercel's pricing docs say a normal step writes three: created, started and completed, plus one for each retry.

Our arithmetic on the sample above: five steps at three events each is 15. The two waits and one retry add a few more, and we round up to 25 a repair to leave room for extra retries (our estimate, not a measured run). At 400 repairs a month that is 10,000 events, or $0.20 on Pro. The Functions that run each step, the model calls and the messages you send are separate lines, and in this sample they are the bill. So we price per closed repair, not per event: in shadow mode the run handles real complaints while your team still sends the quotes, and we add up model tokens, Functions, events and messages for each repair it would have closed. Hobby's allowance would cover the events, but Hobby is for non-commercial, personal use only, so a property manager's approvals belong on Pro or Enterprise.

What does it forget, and when?

Run data is deleted after a fixed time once the run ends. The retention table in Vercel's docs:

The docs say retention is not configurable by default and a custom period goes through support. So the dashboard is a debugging tool, not your audit trail. When the owners' association asks in March who approved the October chiller repair, a Pro run's log has been gone since October. The decision has to be written, as a step, to the work order, the CRM or the ledger you keep.

The same recording works against you on privacy. Vercel's docs say every step's input and output is recorded. Pass IDs between steps, not a tenant's passport scan or phone number, and fetch the personal data inside the step that needs it.

Where does the run live?

In one Vercel region for its whole life, and none of them is in the UAE or Saudi Arabia. By default a run is pinned to the region of the function that started it, with its state, queue dispatch and streams kept there. You can pass a region to start() instead.

Two details matter in the Gulf and India:

• Mumbai is possible. bom1 is a Vercel region, so an India team can keep run state there.
• Old runs stay in Virginia. Multi-region needs workflow 5.0.0-beta.33 or later; runs from the 4.x line always live in iad1, and upgrading does not move them.

For a Dubai or Riyadh team this is the reason to keep personal data out of step payloads: the run's own state sits outside the country even when your system of record does not. We confirm that data path per project, in writing, before you sign.

What is the status, and what limits matter?

Vercel has not announced general availability that we could find on 16 October 2026. The Workflow Development Kit entered public beta on 23 October 2025, and the AI SDK page marks Workflows as New. The SDK itself, workflow on npm, is at 5.2.2 under Apache-2.0, and its docs say you can "run locally, self-host, or swap every component".

The limits that shape a design, from the pricing docs:

1. 25,000 events and 10,000 steps a run. Runs past 2,000 events replay more slowly, and Vercel suggests child workflows or batching.
2. 240 seconds of replay. A run whose replay takes longer may be aborted.
3. 50 MB a payload and 2 GB of stored state a run.

So build one run per job, a repair or an onboarding, not one run per building per year.

Is it the right engine at all? Compare it with what you would build instead. Our reading, not a benchmark:

The exit is better than most. The Workflow SDK is the same code on every backend, and its docs list Local, Postgres and Vercel adapters, so a workflow you write for Vercel can run on your own Postgres later. Vercel's docs say upgrading the SDK does not migrate runs created before the upgrade, so plan a move as a drain: new runs start on the new backend while old ones finish. The docs we read also do not say how Vercel uses step data beyond running and showing the run; ask for that in writing before regulated data goes near it.

How do we start?

We call the method Spec, shadow, gate. We write down every wait, who answers it and where the answer is recorded, run the workflow beside your team with nothing written to your systems, then put a person on the write. The written assessment is free. The first build week is a fixed AED/SAR 14,900, credited in full if you sign the build within 60 days, and our Run plans are on one page. See how we build on Vercel for the rest.

We are not a Vercel partner; we use the product's own names, and mindcat.ai itself runs on Netlify. If none of your agent's steps waits longer than a request takes, or the run's state must stay in the Gulf, you do not need Workflows yet: keep the step synchronous and the record in the system you already trust.