Six months ago, AI agents represented less than 3% of deployments on Vercel. Today, that number is above 50%. That single data point, disclosed at Vercel's Ship conference, tells you everything you need to know about why the company just announced its most ambitious product expansion since it launched the frontend cloud concept: Vercel is no longer just where you deploy your Next.js app. It is becoming the operating system for user-facing AI agents. The announcements span five distinct product areas: Vercel Services, the Agent Stack, the open-source eve framework, Vercel Agent, and a suite of new enterprise controls. Taken individually, each is interesting. Taken together, they represent a deliberate redefinition of what "frontend infrastructure" means in 2026.

Vercel Services is the structural foundation of the new platform. It bundles frontend, backend, and service deployment into a single Vercel project, with private routing between services, automatic authentication, and a single preview URL per commit that spans the entire stack. That last detail matters more than it sounds. Right now, if you want to preview a full-stack change that touches your frontend, your API layer, and a background worker, you need three separate preview environments and someone to wire them together. Vercel Services makes a unified preview the default. For teams that ship agent-powered features alongside UI changes, this eliminates an entire class of "works in staging, breaks in preview" bugs. Services enters beta on July 1. If you run multi-service workloads on Vercel today, this should be your first stop.

Rather than building a new agent platform from scratch, Vercel is formalizing the stack it already had. The Agent Stack is a coherent grouping of existing Vercel tooling: the AI SDK, AI Gateway, Vercel Sandbox, Workflow SDK, and Chat SDK. These products existed independently. Now they have an explicit integration contract and are being positioned as a complete agent infrastructure layer. This is a smart move. Teams that adopted the AI SDK early now discover they already have most of an agent platform. The migration cost is low; the payoff is standardized observability, routing, and sandboxing across all agent workloads.

eve is Vercel's open-source framework for building AI agents. The defining design decision: each agent is a directory of code and configuration. If you have ever deployed a Next.js app, you already understand the mental model. Your agent is a first-class project artifact, not a blob of prompt strings glued together in a Python script nobody owns. The directory-as-agent convention aligns tightly with Vercel's deployment model, which is almost certainly intentional. Building with eve means your agent deploys the same way your app deploys. Same CI pipeline, same preview URL workflow, same rollback mechanism. For frontend-native teams that have never operated a queue-based worker system, this is a significant reduction in operational complexity.

Vercel Agent is the hosted, managed agent runtime sitting on top of this entire stack. Enterprise controls add the governance layer that production deployments require: sandbox policies, audit logging, and access controls for agent tool execution. DoorDash, Helly Hansen, OpenAI, Stripe, and The Weather Company are cited as reference customers already running production workloads on the platform. That customer list is not decoration. OpenAI and Stripe are both sophisticated infra buyers with high reliability standards. Their presence signals that the durability and observability story is real, not aspirational.

Most coverage will focus on the new brand names. The deeper shift deserves more attention. Vercel is quietly redefining "frontend" to include durable background reasoning and tool execution. An agent that retrieves context, calls external APIs, retries on failure, and writes results to a database is not a frontend concern under any traditional definition. Vercel is betting it should be, because the experience of that agent is inseparable from the user interface it powers.

This has an organizational consequence that engineering leaders should model out now. If your frontend team owns the agent, they also own retries, failure recovery, sandbox security reviews, and reliability budgets for long-running jobs. Those concerns currently live in your platform or backend team. Over the next 12 months, teams on Vercel's stack will face a skills gap: frontend engineers who need to reason about durability, and platform teams who need to decide whether to cede ownership of a workload type they never expected to touch.

The teams that resolve this ambiguity early, ideally by running a low-stakes pilot and establishing ownership before it becomes a production incident, will be ahead.

Vercel is not really competing with Heroku or Netlify here. The relevant comparison set is the emerging agent platform layer:

Vercel's differentiated bet is the last column in row one: the claim that agents which power user-facing web experiences should deploy alongside those experiences, not as separate infrastructure. LangGraph Cloud is powerful but assumes your agents are a backend concern. Cloud provider workflow engines (AWS Step Functions, Google Workflows) are durable but require deep platform expertise and offer no concept of a preview URL or a frontend deployment pipeline. Where Vercel loses on paper is framework agnosticism. eve and the Agent Stack are optimized for the Vercel deployment model. If your agents are Python-heavy, run inside your existing Kubernetes cluster, or need tight integration with non-Vercel data stores, you will feel the edges of this platform faster. That is an honest limitation, and it matters for platform-engineering-led organizations that have already built significant internal tooling. For product-engineering-led organizations, especially those already on Vercel for their SaaS frontend, the consolidation value is real. One vendor, one deployment model, one preview environment, one billing relationship.

Consolidating your AI gateway, agent orchestration, sandboxing, and frontend deployment on one vendor reduces glue code. It also increases switching cost. Both things are true simultaneously. The mitigating factor here is eve's open-source status. A framework that is a directory of code and configuration is, in principle, portable. You could run eve agents on a different compute substrate if Vercel's pricing or reliability ever became a problem. Whether that portability holds in practice depends on how deeply the runtime assumptions bake in over time. Watch the eve repository closely: if the framework's core primitives start requiring Vercel-specific APIs, the lock-in risk increases materially. For now, the architecture is transparent enough that the risk is manageable. The correct response is not to avoid the platform but to structure your adoption so that agent logic lives in eve-defined directories rather than scattered across Vercel-specific SDK calls. Keep your business logic portable even if your deployment layer is not.

The 3% to 50% deployment shift is not a projection. It happened in six months. If you are waiting to form an opinion on agent infrastructure, you are already behind the teams that were in that 3%. Here is a concrete sequencing:

Vercel's Ship announcements reflect a thesis that will be tested over the next 18 months: that the center of gravity for AI agents is the web experience they power, not the model they run on or the orchestration engine they use. If that thesis is right, then the platform that already owns the deployment lifecycle for the world's most performant web applications is uniquely positioned to own the agent lifecycle too. The from-scratch agent platforms face the opposite problem. They can orchestrate agents well, but they have no natural answer to "how does this agent's output connect to the UI the user actually sees?" Vercel has that answer by default. The 50% deployment figure is a leading indicator. The real test is whether those deployments convert into durable production workloads with the reliability characteristics enterprises require. Reference customers like Stripe and OpenAI suggest the answer is yes, but your production environment is not Stripe's. Run the pilot, measure the operational characteristics, and make your own call. The frontier of frontend infrastructure just moved. Teams that recognize agents as first-class production assets today will have the tooling fluency, the organizational clarity, and the operational data to move fast when the rest of the industry catches up.

Want to start building with Vercel? Here's a quickstart: