Production AI agents can run for minutes or hours, calling tools, editing files, and waiting on people between steps. An agent runtime can keep that work going after the first request ends. It hosts the loop and, in durable runtimes, saves completed step results so a crash doesn't restart the task; a separate sandbox isolates code the model writes. Run duration, recovery requirements, and operating capacity help determine what your application needs and which responsibilities a managed platform handles.
Copy link to headingWhat is an agent runtime?
An agent runtime is the execution layer that hosts an AI agent and keeps its runs going. It receives each invocation and runs the agent's code, while its persistence model decides whether a run survives a crash, a timeout, or a wait for approval. Vercel provides managed agent infrastructure: Vercel Functions execute application code, Vercel Workflows preserves progress, Vercel Sandbox isolates generated code or an entire agent harness, and AI Gateway connects the agent to models.
Some vendors use the term to refer to everything an agent needs in production, including durable execution, streaming, and human-in-the-loop support. Others emphasize managed hosting, such as AgentCore Runtime from Amazon Web Services (AWS), Google Cloud's Agent Runtime, and Databricks Agent Runtime.
Copy link to headingHow do agent runtimes differ from frameworks and harnesses?
Frameworks and harnesses control what the agent does at each turn of its loop, including which model it calls and which tools it can use. A runtime controls where that loop runs and what survives when it stops. Choosing among harnesses comes down to what an agent harness can reach, what limits it, and what it hands back for review.
Each layer owns a different part of the job:
Recovery is one area where runtimes differ. Vercel Workflows records completed step results and resumes execution across crashes and deployments. Vercel Sandbox provides isolated Linux micro virtual machines (microVMs), with filesystem persistence across sessions and Drives for storage shared across sandbox runs. Together, these capabilities support application-level recovery, isolated execution, and persistent workspaces.
Copy link to headingWhy do production agents need an agent runtime?
Production agents need a runtime because their work is now part of the ordinary production load. According to Vercel's reported data, coding agents initiate more than 50% of Vercel deployments as of September 2026. Projects those agents deploy are 20 times more likely to call AI inference providers than projects people deploy. As more multi-step loops reach production, a runtime stack can address four gaps in an in-memory loop:
Crash recovery: An in-memory agent loses unsaved state when its process crashes or its function times out. A dropped connection may interrupt execution or delivery, depending on the host. A durable runtime stores execution state where a restarted process can read it.
Resumable retries: A retry with no saved results can start over and repeat model calls already made. A durable runtime saves completed step results so the retry can skip them.
Long-running execution: Agent runs wait on tools, other services, and people for longer than a single request lasts. A durable runtime picks the run back up after each wait.
Code isolation: Agents that execute model-generated code need an execution boundary separate from the application process. A runtime stack can route that code into an isolated sandbox with scoped filesystem, network, and credential access.
Treating these as features to add later can hide production requirements. A short demo may never encounter a deployment or a delayed approval, leaving its assumption that everything happens within a single process untested. Retrofitting persistence then means revisiting tool calls written under that assumption.
Copy link to headingCore components of an agent runtime stack
An agent runtime stack can combine three components, each handling a different responsibility. A managed platform connects their execution, isolation, and persistence capabilities so the application can use them together.
Copy link to headingThe agent loop
The agent loop is the cycle that calls a model, runs the tools it requests, appends the results, and calls the model again. In the AI SDK, the loop ends in one of four ways. The model returns a finish reason other than tool calls, a requested tool has no execute function, a tool call needs approval, or a stop condition fires.
Step limits depend on the agent class. The AI SDK's in-memory ToolLoopAgent stops after 20 steps by default through isStepCount(20), while its durable counterpart, WorkflowAgent, applies no default maximum step count when it streams with stream(). The in-memory class fits short interactive tasks as is, but a streaming durable agent needs an explicit stop condition to bound its model calls. Without one, the loop can keep making paid model calls while the model continues requesting tools.
Copy link to headingThe execution sandbox
An execution sandbox is an isolated environment where model-generated code runs, apart from production systems and your application process. It contains only the work routed into it. The AI SDK's experimental sandbox option hands tools a sandbox to run commands in. Each tool's own code stays in your application process, under the authorization checks you give it.
On Vercel Sandbox, each sandbox is an isolated Linux microVM that you create on demand and stop when the work is done. It can run generated commands, test suites, or an entire agent harness, with filesystem, network, and credential controls configured for the task. This gives an agent an isolated environment for working with code and files.
Copy link to headingThe durable state layer
The durable state layer records the results of completed steps, so an interrupted task resumes from its last persisted checkpoint rather than from zero. Agent memory solves a different problem. A chat-history store can keep messages, preferences, tool calls, and results, but history alone doesn't guarantee reliable recovery of execution state.
Vercel Workflows provides this layer as durable code that retries failed steps, waits on external events, and resumes across crashes and deployments. Between its October 2025 beta and general availability on April 16, 2026, it processed more than 100 million runs and 500 million steps across more than 1,500 customers. You define workflow and step boundaries; Vercel manages execution, persistence, and retries.
Copy link to heading4 best practices to build or buy an agent runtime for developers
Four checks help you choose what to implement in your application and what a managed platform should handle. On Vercel, you define the agent's behavior and workflow boundaries, while Vercel manages the underlying compute, persistence, and execution infrastructure.
Copy link to headingPrice the runtime against your idle time
Wall-clock CPU billing can cost more for workloads that spend substantial time waiting on inference. In one agentic workload study, model inference accounted for 71% to 98% of the total runtime across the tested benchmarks and models. A coding agent's sandbox can sit idle through those waits between commands.
A runtime that bills CPU time only while code executes fits that profile. At 10% utilization, an hour on that meter bills a tenth of the CPU time a wall-clock meter would. Vercel Functions and Vercel Sandbox both use Active CPU pricing.
Copy link to headingCheck run length against session caps
A loop that passes every test can still stop in production once a real run outlasts its host's duration cap. With Fluid compute, Vercel Functions run for up to 300s on Hobby and up to 800s on Pro and Enterprise. Supported Node.js, Bun, and Python functions on Pro and Enterprise can opt into a 1,800s extended duration beta through per-function configuration. Sandbox sessions run for up to 45 minutes on Hobby and for up to 24 hours on Pro and Enterprise. Account for sandbox startup latency when setting request timeouts.
Runs that must outlast a function cap can use a durable workflow; on Vercel, workflows have no maximum duration for runs or sleeps, while each step runs within function limits. On the default Node.js runtime, runs exceeding 2,000 events can replay more slowly, and each run has a 25,000-event limit. Bundling small operations into steps can reduce event counts and replay overhead. Check these limits alongside the host's session ceilings and idle timeouts before launch.
Copy link to headingKeep durable state portable
The open-source Workflow SDK lets you define durable agent behavior independently of a single hosting provider. Its pluggable backends, called Worlds, provide the persistence, compute, and queueing that workflow execution needs.
On Vercel, the platform operates the workflow infrastructure while your application defines the workflow and its steps. For self-hosted deployments, Postgres World provides durable storage and job processing, while your team operates the database and long-lived workers. This gives you a choice of deployment backends; moving in-flight runs between them still requires a migration plan.
Copy link to headingRoute generated code outside the function
Run untrusted, model-generated code in Vercel Sandbox to isolate it from your application process. Apply authorization checks to every tool, validate model-selected arguments, and scope the credentials and network access available to each task. Your application can coordinate the agent through Vercel Functions or Workflows while Sandbox provides the execution environment.
The Open Agents template demonstrates one option: its agent loop runs outside Sandbox and works with files and commands through tools. You can also run an entire agent harness inside Sandbox when the harness needs its own execution environment. Choose the boundary that fits the harness and apply tool authorization checks in either pattern.
Copy link to headingHow Vercel powers agent runtime infrastructure for TypeScript developers
Vercel combines managed compute, durable execution, isolated environments, persistent workspaces, and model access in one platform for running agents. A team writing its agent with the AI SDK defines the loop, tools, and workflow boundaries; Vercel operates the infrastructure that executes the code, preserves progress, and connects those capabilities.
Copy link to headingVercel Workflows turns tool calls into durable steps
An agent that crashes on its ninth tool call can reuse persisted results from the first eight and preserve recorded approvals. WorkflowAgent is the AI SDK class that runs the agent loop inside a workflow on Vercel. It turns each tool's execution function marked with the 'use step' directive into a durable step that records its result, retries on failure, and survives restarts. Tools without the directive still run, but as ordinary in-memory functions; steps that change external systems need idempotency keys because an action can succeed before its result is persisted.
A tool marked needsApproval suspends the workflow until a person approves or denies the call, even hours later, and the run resumes where it left off. Each durable tool call appears as its own step in the workflow dashboard, so a slow tool and a failing one look different at a glance. Vercel manages persistence and retries across these steps, while your application controls which operations require approval and how they resume.
Copy link to headingVercel Sandbox follows the agent across workflow steps
A coding agent that runs the test suite in one step and reads the results in the next needs the same sandbox both times. The second step may resume in a different function invocation. The @vercel/sandbox SDK supports custom class serialization for the Sandbox class inside a workflow. Its methods for creating sandboxes, running commands, snapshotting, and stopping also run as workflow steps on their own.
Notion runs every Notion Worker, the custom code that extends Notion's agents, in an ephemeral Firecracker microVM on Vercel Sandbox. With persistent sandboxes, the filesystem is saved when a session stops and restored when it resumes. An agent waiting overnight on an approval can stop its sandbox and resume the next morning with the same files.
Copy link to headingVercel Drives keep the workspace across sandbox runs
Cloning a large repository and installing its dependencies is slow work to repeat, and an agent that starts a fresh sandbox after a failure would otherwise repeat it every time. Vercel Drives mount persistent storage as a directory inside a sandbox, so code, dependencies, and notes carry over to the next run, even in a different sandbox.
Each Drive takes one read-write mount at a time alongside read-only snapshots. One agent can build up a workspace while others read a point-in-time copy of it. A snapshot won't show the writer's later changes, so readers take a new snapshot to pick up fresh work; each sandbox can mount up to four Drives.
Copy link to headingFluid compute serves waiting agent sessions efficiently
An agent session can spend most of its time waiting for a model to respond. With Fluid compute, Vercel Functions can share an instance across waiting sessions, and Active CPU pricing pauses CPU billing while code waits on I/O. Vercel Sandbox also uses Active CPU pricing, so a coding environment waiting on model responses accrues CPU usage only for work that actually uses the processor.
New projects have Fluid compute on by default, so the routes that start and stream an agent get this behavior without extra configuration.
Copy link to headingAI Gateway routes every model call through one budget
An agent loop that calls models from three providers otherwise needs three API keys, three dashboards, and its own fallback logic for when one provider goes down. AI Gateway puts every model call routed through it behind one endpoint, with failover across healthy providers and ordered model fallbacks. Budgets cap spend for a team, a project, an API key, or a team member.
Switching models is a change to a provider/model-name string such as anthropic/claude-sonnet-5.5. Deployments on Vercel authenticate with an OpenID Connect (OIDC) token, so the loop calls AI Gateway without a stored API key. Spend through bring-your-own-key (BYOK) credentials isn't counted in Gateway budgets, so teams using their own keys set limits with the provider as well.
Copy link to headingShip a durable agent loop on Vercel without managing servers
An agent runtime stack comes down to three decisions about where the loop runs, where model-written code runs if needed, and where progress lives. On Vercel, those decisions shape your application architecture while the platform manages the compute, persistence, isolation, and model access underneath it.
For a coding agent, these managed capabilities support one execution flow:
Vercel Workflows: Runs the durable agent loop and saves step results, so work can resume after a failure or an approval wait.
Vercel Sandbox: Gives the loop an isolated environment for generated commands, or hosts the entire agent harness when that pattern fits the task.
Vercel Drives: Keeps the repository, dependencies, and notes available as the agent moves between sandbox runs.
Fluid compute: Serves the routes that start and stream the agent, with Active CPU billing that pauses during I/O waits; Sandbox also bills for active CPU usage.
AI Gateway: Connects the loop to models via a single endpoint, with provider failover and a spend ceiling for Gateway-billed usage.
Build a durable agent with the Workflow SDK to add persisted steps, resumable streams, and human approvals to your AI SDK application on Vercel.
Copy link to headingFrequently asked questions about agent runtimes
Copy link to headingIs an agent runtime the same as an agent framework?
No, they serve different roles, although their capabilities can overlap. A framework defines the agent loop in your code, and its persistence configuration works with the runtime to determine whether progress survives a restart. The AI SDK loop runs in memory as ToolLoopAgent or durably as WorkflowAgent, so choosing a framework doesn't necessarily lock in a hosting provider.
Copy link to headingWhat happens to a running agent when you redeploy?
On Vercel, by default, a workflow run is pinned to the original deployment that started it, so a redeploy ships new code to new runs without affecting those already in flight. Keep that deployment available while its runs are in flight, and cancel runs you no longer need from the Workflows dashboard or the CLI.
Copy link to headingCan an agent runtime run on Vercel Hobby?
Yes, for personal, non-commercial projects within Hobby's limits. Workflows include 50,000 events and 1 gigabyte (GB) of data written per month, and Sandbox allows 10 concurrent sandboxes. Going past the Sandbox usage quotas pauses sandbox creation until the next billing cycle.
Copy link to headingDoes streaming extend how long an agent loop can run?
No. Maximum duration includes the time spent streaming the response, so a stream keeps the connection open without adding time. Work passed to waitUntil() after the response counts against the same limit.