Vercel's eve bets the agent plumbing layer consolidates the way Next.js did

Vercel has released eve, an open-source framework for building, running and scaling agents, in public preview ^[1][2]. The interesting part is not the syntax but the claim underneath it: that the production plumbing every team has been hand-rolling is now a solved layer that ships with the framework, specifically durable execution, sandboxed compute, human-in-the-loop approvals, subagents and evals ^[3].

The company states the lineage plainly. "Agents today are where the web was before frameworks, with everyone hand-rolling the same plumbing and nothing carrying over to the next one. Next.js ended this for the web, and eve is doing the same for agents," Vercel writes ^[4]. The shape it proposes is filesystem-first: an agent is a directory, with the model in agent.ts, the system prompt in instructions.md, and tools, skills, subagents, channels and schedules each as their own files ^[5][6]. The smallest agent that runs is two files ^[7], and eve picks up new files at build time with no registration boilerplate ^[8].

Two of the five bundled capabilities ^[20] are the ones operators have actually been paying engineers to build. On durability, Vercel says every conversation is a durable workflow with each step checkpointed, so a session can pause, survive a crash or a deploy, and resume where it stopped, built on the open-source Workflow SDK ^[9]. On isolation, every agent gets its own sandbox running in a separate security context from the harness that controls it, keeping agent-generated code out of the application runtime entirely ^[10]. That sandbox backend is an adapter: Vercel Sandbox when deployed, Docker, microsandbox or just-bash locally, and you can write your own ^[11].

The provenance argument is the strongest part of the pitch. Vercel says it built agents for years, v0 among them, then shipped hundreds of agents and internal apps and found every team rebuilding the same plumbing with none of it carrying over between use cases ^[12]. Its conclusion, "Agents have a shape" ^[13], is also the uncomfortable one for anyone maintaining a bespoke harness. If the shape is real, the checkpointing, resumption, approval queue and container isolation you built are undifferentiated work now available as a dependency, and the ongoing cost is not the original build but the upkeep of a private fork of a public abstraction.

Watch where the pull is. The agent definition is portable and the sandbox layer is pluggable ^[11], but an eve agent is an ordinary Vercel project and vercel deploy ships it unchanged ^[14]. The model surface is deliberately open, working with any model, any MCP server, and channels including Slack, Discord and GitHub ^[15], with provider fallbacks through AI Gateway ^[16]. So the neutrality sits at the top of the stack and the gravity sits at the bottom, which is exactly the Next.js pattern being invoked.

Three things to track through preview. Whether durable execution gets adapters the way sandboxing did, or stays coupled to Vercel's Workflow SDK ^[9][11]. Whether the session HTTP API holds still, given it is already documented down to POST /eve/v1/session and continuation tokens ^[17]. And whether the once-only migration cost is small enough to pay twice, because development is in the open on GitHub ^[18] and the onboarding claim, an agent running locally in under a minute from one command ^[19], is Vercel's own and untested here.