Vercel's Eve Framework Puts Agents on Their Own Stack
Vercel shipped Eve, an open-source TypeScript agent framework, at Ship London in June. The filesystem-first design and isolated Sandbox runtime signal a serious play for the production agent layer.

Vercel spent most of its existence being the platform where Next.js apps go to ship. At Ship London on June 17, the company made a different call: it wants to be the default runtime for production AI agents, and it shipped a stack to match.
The centerpiece is Eve, an open-source TypeScript framework that treats each agent as a directory of files. No custom DSLs, no vendor-specific orchestration layers, no YAML sprawl. If your agent needs a system prompt, you write a markdown file. If it needs a tool, you drop a TypeScript file in the tools/ folder. That's the architecture.
TL;DR
- Eve is Apache-2.0, TypeScript-first, and now in public preview at github.com/vercel/eve
- Agents are directories: markdown for instructions, TypeScript for tools, config files for channels and schedules
- Built-in durable execution checkpoints every step - sessions survive crashes and redeploys
- Vercel Sandbox gives agents isolated microVMs; Vercel Connect handles credentials without long-lived tokens
- 6 million daily deployments on Vercel, with 50% triggered by coding agents; 1 trillion tokens flow through the AI gateway daily
What Vercel Shipped
Eve - Agents as Directories
The framework's organizing principle is filesystem-first: a file's name and position in the directory tree define its function. A standard Eve agent looks like this:
my-agent/
├── agent.ts # model config and provider selection
├── instructions.md # system prompt
├── tools/ # capabilities the agent can invoke
├── skills/ # reusable knowledge modules
├── subagents/ # delegated tasks
├── channels/ # deployment targets (Slack, GitHub, Discord, etc.)
└── schedules/ # cron-style automated triggers
Scaffolding takes one command:
npx eve@latest init my-agent
eve dev # local testing
vercel deploy # push to production
That clean developer experience is intentional. Vercel is betting that agents, like web apps, need a strong convention-over-configuration framework before teams will trust them in production. The filesystem approach also makes agents easier to audit - any SRE can read an instructions.md file without understanding the orchestration code that wraps it.
Guillermo Rauch delivers the closing keynote at Vercel Ship NYC on June 30, 2026.
Source: vercel.com
Vercel Sandbox - Isolated MicroVMs for Agent Code
Agents that can run arbitrary code are a security problem waiting to happen. Vercel's answer is Sandbox: isolated microVM environments where agents execute code completely separated from the host application runtime.
For local development, you can use Docker or bash. In production, Sandbox spins up isolated compute that's destroyed after each task. The explicit goal is preventing what CEO Guillermo Rauch described in a TechCrunch interview today - agents accidentally exposing proprietary codebases by running in an environment where they can read files they shouldn't touch.
This isn't a new idea. The agent sandbox tools space has been crowded for two years, with E2B and Daytona building similar isolation primitives. What's different here is that Sandbox is built into the deployment platform, not bolted on as a separate API call.
Vercel Connect - Credentials Without the Risk
The third piece is Vercel Connect, a credential management layer that gives agents access to external services without storing long-lived tokens. The credential exposure problem is real - AI coding agents have already been caught exfiltrating secrets from developer environments when their sandboxing was insufficient.
Connect issues short-lived credentials on demand rather than embedding API keys in agent configuration. Launch integrations cover Slack, GitHub, Snowflake, Salesforce, Notion, and Linear, with OAuth and API key support for anything else.
How the Runtime Actually Works
Durable Execution
This is the part that matters most for production use. Eve checkpoints every step of a conversation as a durable workflow. If a session crashes mid-task, or if you push a new deployment while an agent is mid-conversation, the next invocation picks up exactly where the previous one stopped.
That durability guarantee comes from Vercel Functions under the hood - the same infrastructure that handles millions of web function invocations daily. For a former SRE, this is the most credible part of the Eve story. Durable execution is hard to build correctly, and Vercel isn't building it from scratch.
The framework also includes built-in evals - scored test suites that run locally or in CI pipelines. Vercel's pitch is that agents deserve the same testing culture as software, which is true even if most teams aren't there yet.
Human-in-the-Loop Without the Cost
One design choice worth calling out: Eve's approval workflows pause execution without consuming compute. When an agent needs human sign-off before taking an action, it stops, waits for input through whatever channel the agent is deployed to (Slack, email, a custom UI), and resumes when it gets a response. No idle tokens burning while a human takes 20 minutes to reply.
This is directly relevant to the governance conversation happening at the platform layer. The Agent Control Standard specification has been pushing for exactly this kind of pause-and-resume pattern as a baseline requirement for autonomous agents in enterprise settings. Eve ships it as a default, not a configuration option.
Vercel Ship NYC drew over 2,000 developers to two conferences in London (June 17) and New York (June 30).
Source: vercel.com
The Numbers Driving This Bet
Vercel isn't launching Eve speculatively. The company processes 6 million deployments per day, and CEO Rauch says 50% of those are now triggered by coding agents rather than human engineers pushing code. The AI gateway routes more than 1 trillion tokens daily across multiple model providers.
Those numbers explain the architectural philosophy Rauch laid out in a TechCrunch interview published today. His argument: the mistake companies made last year was committing to a single AI lab as their model provider. The better architecture separates the model layer from the agent layer entirely - model, harness, data platform, sandbox, and gateway as independently swappable components.
That position isn't neutral. Vercel is selling the agent infrastructure layer, and a world where models are commodities is a world where Vercel's platform matters more. But the technical argument holds on its own terms. Coding agents already route between Gemini, Claude, and open-source models based on cost and latency. An agent framework that hardcodes to one provider is a reliability risk and a cost sink.
Vercel reports that Eve already powers more than 100 production agents internally, including a data analyst handling 30,000 monthly queries and a support system resolving 92% of tickets without human escalation.
Eve's filesystem-first design makes agent code readable without specialized orchestration knowledge.
Source: pexels.com
Requirements and Compatibility
| Component | Requirement |
|---|---|
| Language | TypeScript (Node.js 18+) |
| Deployment | Vercel Functions (production) or Docker/bash (local) |
| Model providers | Any via AI SDK - no provider lock-in |
| Context window | No framework-imposed limit |
| License | Apache-2.0 |
| Status | Public preview (subject to change before GA) |
| Integrations | Slack, GitHub, Discord, Teams, Telegram, Snowflake, Salesforce, Notion, Linear |
Where It Falls Short
Eve is in public preview, which means the API will change. Vercel said as much in the announcement. That's not unusual for an agent framework - every major one in the current comparison has shipped a breaking version at some point. But it's worth being explicit about what "public preview" means if you're considering building production agents on it today.
The bigger constraint is hosting. Eve runs on Vercel. The local development story uses Docker or bash, but production deployment goes through Vercel Functions. If your infrastructure team has hard requirements around on-premises deployment or cloud provider choice, that's a real friction point. The framework's open-source license doesn't automatically mean you can run it anywhere without Vercel's platform.
Pricing for Eve itself isn't listed separately - you pay for Vercel compute, Vercel Sandbox runtime, and presumably AI Gateway tokens. For teams already on Vercel, the marginal cost might be low. For teams that aren't, the onboarding cost is the entire Vercel platform.
There's also an observability dependency. The tracing story - OpenTelemetry integration, full run traces, tool call logs - is good. But it assumes you're comfortable sending that trace data through Vercel's infrastructure. For teams handling sensitive internal data, that's a question worth asking before the first production deploy.
None of these limitations make Eve a bad choice. For teams already launching on Vercel, shipping agents the same way they ship apps is truly useful. For everyone else, the right question is whether the framework's production guarantees are worth the platform dependency.
Sources:
