Vercel's Agentic Infrastructure Stack Explained

Last updated: October 18, 2026

Updated October 18, 2026: The earlier version framed Vercel's announcement as four primitives (AI Gateway, Sandbox, Flags, Microfrontends) and showed code importing @vercel/ai-gateway, calling Sandbox.create({ runtime: "python3.12" }), sandbox.exec() and sandbox.destroy(). The announcement does not name Flags or Microfrontends, @vercel/ai-gateway is not a published package, and the Sandbox SDK uses runCommand() and stop(). The code now follows the AI Gateway, Sandbox quickstart and Flags SDK docs, and the gateway URL, markup, cold-start and failover claims were corrected to match Vercel's documentation.

Vercel Picked a Side#

For two years the conversation about what an "agent stack" means has been a list of vendors and a vague hand-wave. An orchestration library, a model provider, a vector database, a queue, somewhere to run untrusted code, a flag system bolted on after the first incident. Every team rebuilt the same plumbing.

For the larger agent workflow map, read AI Agents Explained: A TypeScript Developer's Guide and How to Build AI Agents in TypeScript; they give the architecture and implementation context this piece assumes.

Vercel's agentic infrastructure announcement frames the shift as three evolutions, not one:

1. Infrastructure for coding agents to deploy to. Immutable deployments, preview URLs on every commit, instant rollbacks, and access through the CLI, API, MCP servers and git integration, so an agent can open a PR, get a preview URL, verify it and ship.
2. Infrastructure for building and running agents. The AI building blocks, unified on one platform.
3. Infrastructure that is itself agentic. The platform investigates anomalies, reads logs and source, does root-cause analysis and reviews proposed fixes in sandboxes. Vercel says this still happens with human approval in the loop today.

This post focuses on the second part, because that is where your code lives.

The Building Blocks#

The announcement lists the pieces of the "building and running agents" layer as:

• AI SDK, the unified way to build AI features across frameworks and providers. AI SDK 6 added an agent abstraction.
• Chat SDK, for putting agents into chat apps and platforms from one codebase.
• AI Gateway, "a single endpoint for hundreds of models, with budgets, monitoring, routing, retries, and fallbacks."
• Fluid compute, shaped for workloads where latency, concurrency and idle waiting all matter.
• Workflows and Queues, so agents can pause, resume, retry, keep state and offload background work.
• Sandbox, isolated execution environments for untrusted code.
• Observability, to trace what agents are doing and where they go wrong.

AI Gateway works through the AI SDK with a plain model string, or through an OpenAI-compatible endpoint at https://ai-gateway.vercel.sh/v1 with an AI_GATEWAY_API_KEY (Vercel deployments can use OIDC instead). It records status, provider, latency, token usage, cost and every routing attempt per request. Vercel's docs say it "adds zero markup to provider token prices, including with BYOK."

Sandbox runs code in Firecracker microVMs with their own filesystem and network. The default image includes Node.js, Python and common tools. Sandboxes persist state on stop by default, support snapshots, and bill CPU on an Active CPU basis, so time spent waiting on a model is not billed as CPU (memory is still billed while the sandbox runs).

Flags are not part of the announcement's list, but they are the natural runtime control for agents on Vercel. The open source Flags SDK declares flags in code with a decide() function and evaluates them on the server.

What It Looks Like in Code#

A minimal agent that uses three of these: AI Gateway for the model call, Sandbox for tool execution, and a flag as a kill switch. The flag is a Next.js server-side flag; the model string routes through AI Gateway.

// flags.ts
import { flag } from "flags/next";

export const codeExecEnabled = flag({
  key: "agent-code-exec",
  decide() {
    return false; // replace with your targeting logic or a provider adapter
  },
});

// agent.ts
import { generateText, isStepCount, tool } from "ai";
import { Sandbox } from "@vercel/sandbox";
import { z } from "zod";
import { codeExecEnabled } from "./flags";

export async function runAgent(userPrompt: string) {
  const result = await generateText({
    model: "anthropic/claude-sonnet-5.5", // resolved through AI Gateway
    system: "You are a code agent. Use the runPython tool when needed.",
    prompt: userPrompt,
    stopWhen: isStepCount(5),
    tools: {
      runPython: tool({
        description: "Execute Python in an isolated sandbox",
        inputSchema: z.object({ code: z.string() }),
        execute: async ({ code }) => {
          if (!(await codeExecEnabled())) {
            return { error: "Code execution is disabled" };
          }
          const sandbox = await Sandbox.create({ timeout: 60_000 });
          try {
            await sandbox.writeFiles([{ path: "/vercel/sandbox/main.py", content: code }]);
            const run = await sandbox.runCommand("python3", ["/vercel/sandbox/main.py"]);
            return {
              exitCode: run.exitCode,
              stdout: await run.stdout(),
              stderr: await run.stderr(),
            };
          } finally {
            await sandbox.stop();
          }
        },
      }),
    },
  });

  return result.text;
}

The pieces map to the docs: generateText with a provider/model string is how the AI Gateway docs call a model; Sandbox.create(), runCommand() and stdout() come from the Sandbox quickstart, with writeFiles() and stop() from the SDK reference; flag({ key, decide }) and await exampleFlag() come from the Flags SDK. For local development, the Sandbox quickstart uses vercel link and vercel env pull to get an OIDC token.

A few things worth pointing out.

Failover is configuration, not code. AI Gateway routes a model across healthy providers, and you can configure ordered provider and model fallbacks. Keep that policy out of your application code.

The Sandbox lifecycle is explicit. You create, you run, you stop. Stopping matters for cost: you pay for provisioned memory while the sandbox runs, even when the CPU is idle.

Flags evaluate on the server. The Flags SDK evaluates decide() server-side, which keeps model selection and tool gating out of the browser bundle.

The Gotchas#

Budgets are soft caps on system-credential spend. AI Gateway can reject new requests once a team, project, key or member budget is exceeded, but the docs say BYOK spend is metered separately and does not count toward those limits.

Sandbox start is fast; your setup may not be. Vercel says sandboxes start in milliseconds. Installing dependencies on every run is what gets slow, which is what snapshots and custom images are for.

Isolation is per sandbox, not per tool call. If you reuse one sandbox across calls for speed, everything the agent wrote earlier is still there. Use separate sandboxes, or the multi-agent isolation features (separate Linux users per agent), when that matters.

Do not leak flag logic to the client. If you ship a Next.js page that reads a flag in the browser, the value is in the response. Anything cost or safety related, model choice, tool gating, should be decided on the server.

Where It Fits in the Agent Stack#

The right way to read this announcement is as a redrawing of the seams. Model calls go through AI Gateway, untrusted code goes through Sandbox, long-running runs go through Workflows, and the AI SDK ties them together. Memory layers, evals and your product logic are left to you or to other tools.

That is a defensible split. Orchestration frameworks sit on top of the AI SDK and Gateway. Memory layers (Mem0, Letta, your own pgvector) live alongside. Evals consume the gateway's request logs.

Where it gets interesting for indie devs is the MCP angle. The natural complement to AI Gateway is a hosted MCP server registry, a place to publish tools your agents can use, with auth, rate limits and observability. That is what we built MCPaaS for: deploy an MCP server in one command, get a public endpoint, and plug it into any agent runtime.

The other adjacent need is filesystem state for agents. Sandbox gives you ephemeral compute, but agents that work on files for hours need persistence and addressability. AgentFS is the DD product for that - a virtual filesystem with versioning that any sandbox or agent can mount. Vercel does not solve this problem and arguably should not; it is a different shape than what Sandbox is for.

I walked through stack composition on the Developers Digest YouTube channel, including a live agent build with an external MCP server.

Wiring It Into a Real Product#

Define model selection as a flag from day one. Even with one model, wrap it. The day you want to A/B a new release or fall back to a cheaper model during a billing emergency, you will be glad you did.

Treat Sandbox as the only place untrusted code runs, including code your own agents generate. The temptation to "just eval this small Python snippet" in your Node process is the temptation that ends careers.

Log every model request somewhere you own. AI Gateway's request logs are useful, but vendor logs are not your logs.

Use flags and gateway fallbacks for incident response. When a provider degrades at 3am, the move is a config change that routes around it, not a deploy.

What To Watch Next#

The first open question is how far the "infrastructure that is itself agentic" part goes. Today Vercel describes investigation, root-cause analysis and proposed fixes reviewed in sandboxes, with a human approving. Watch how much of that loop becomes automatic, and what controls come with it.

The second is how much of the orchestration layer Vercel owns. With AI SDK agents, WorkflowAgent in AI SDK 7 and the Workflow SDK, it already owns more than a router would. See Vercel's durable execution model for that layer.

Either way, the abstractions are now named. If you are designing an agent stack in 2026, these are the boxes to start from. You can swap implementations later. You cannot easily swap the architecture.

FAQ#

What are the building blocks in Vercel's agentic infrastructure?#

Vercel's announcement lists AI SDK, Chat SDK, AI Gateway, Fluid compute, Workflows and Queues, Sandbox, and Observability as the layer for building and running agents. It also describes infrastructure for coding agents to deploy to, and infrastructure that is itself agentic. See the AI Gateway docs and Sandbox docs for the references.

How does AI Gateway handle model failover?#

AI Gateway routes a model across healthy providers, and you can configure ordered provider and model fallbacks. Each request log records every routing attempt, so you can see which provider served it.

Does AI Gateway add a markup on tokens?#

No. Vercel's docs say AI Gateway adds zero markup to provider token prices, including with bring-your-own-key.

Are Vercel Sandbox cold starts a real cost?#

Vercel says sandboxes start in milliseconds. The slow part is usually your own setup, such as installing dependencies, which snapshots and custom images avoid. Under Active CPU pricing you are not billed for CPU while code waits on a model, but provisioned memory is billed while the sandbox runs, so stop sandboxes you no longer need.

Is it safe to evaluate flags client-side?#

Not for anything sensitive. Keep model selection, tool gating and cost-related toggles server-side. The Flags SDK evaluates decide() on the server, as covered in AI Agents Explained.

Sources#

• Vercel agentic infrastructure announcement: vercel.com/blog/agentic-infrastructure
• Vercel AI Gateway documentation: vercel.com/docs/ai-gateway
• Vercel Sandbox documentation: vercel.com/docs/sandbox
• Vercel Sandbox quickstart: vercel.com/docs/sandbox/quickstart
• Flags SDK: flags-sdk.dev
• AI SDK tool calling: ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling