At its Ship conference on June 17, 2026, Vercel released eve, an open-source framework for building, running, and scaling AI agents. The framing in the announcement is direct: "Agents today are where the web was before frameworks, with everyone hand-rolling the same plumbing." eve is Vercel's attempt to do for agents what Next.js did for the web, which is to standardize the repetitive infrastructure so teams can focus on what their agent actually does.
That comparison is worth taking seriously, because it is the same company making it about its own most successful product. It is also worth scrutinizing, because the hardest parts of shipping an agent are rarely the parts a framework solves. This post breaks down what eve is, what comes built in, the larger bet it sits inside, and how technology leaders should think about adopting it.
What eve Actually Is
eve is filesystem-first. An agent is a directory, and the files inside it map directly to capabilities. There is no separate wiring layer to maintain.
agent/
agent.ts # model configuration
instructions.md # system prompt and personality
tools/ # custom capabilities (one file per tool)
skills/ # markdown knowledge files
subagents/ # delegated agents
channels/ # Slack, Discord, HTTP, and more
schedules/ # cron-style triggers
The configuration surface is deliberately small. A working agent can be as little as a model declaration:
import { defineAgent } from "eve";
export default defineAgent({
model: "anthropic/claude-opus-4.8",
});
Tools are single TypeScript files with typed input validation and an async execute function. Skills are markdown files that teach the agent domain rules and context. Subagents are child agents the parent can delegate to, each with its own instructions and tools. The result is that an agent reads like a project rather than a tangle of glue code, and the structure is the same regardless of which team built it or what it does. eve is open source on GitHub under an Apache-2.0 license, and a project scaffolds in under a minute with npx eve@latest init.
Source: Vercel.
What Comes Built In
The configuration is the easy part. The reason eve is interesting is the set of production concerns it handles by default, the work most teams discover they need only after their prototype meets real traffic. Six capabilities stand out.
- Durable execution. Conversations checkpoint at each step, so a session can survive a crash, a deploy, or a long pause and resume exactly where it stopped. This is built on Vercel's open-source Workflow SDK.
- Sandboxed compute. Agent-generated code is treated as untrusted. Every agent gets its own isolated sandbox for shell commands, scripts, and file access, running on Vercel Sandbox in production and Docker locally.
- Human-in-the-loop approvals. Any action can be flagged to require a human sign-off. The agent pauses there indefinitely without burning compute, which matters for anything that touches money, customer data, or production systems.
- Subagents. A parent agent can hand work to specialized child agents, each scoped to its own tools and instructions, instead of stuffing every capability into one prompt.
- Evals. Scored test suites validate agent behavior locally, in CI, or against a deployed agent, so a change that quietly breaks behavior gets caught before it ships.
- Multi-channel deployment. One agent can run across Slack, Discord, Teams, Telegram, Twilio, GitHub, Linear, and plain HTTP without rebuilding it per surface.
For observability, eve exports OpenTelemetry traces to the tools teams already run, including Datadog, Honeycomb, and Jaeger, and a local eve dev server shows every model call, tool execution, and skill load as it happens. Each of these is solvable on its own. The argument eve makes is that solving all of them, the same way, on every agent, is the part that does not carry over from one project to the next.
How It Connects to the Rest of Your Stack
An agent is only useful if it can reach real systems. eve connects through Model Context Protocol servers, any OpenAPI document, and Vercel Connect, which replaces long-lived credentials with short-lived tokens and ships with pre-built integrations for Slack, GitHub, Snowflake, Salesforce, Notion, and Linear. The model layer is configurable through Vercel's AI Gateway, with fallback providers, so the anthropic/claude-opus-4.8 in the example above is a default rather than a lock-in.
The Larger Bet
eve did not launch alone. Vercel positioned it as the framework on top of an "Agent Stack" that bundles its existing pieces: the AI SDK, AI Gateway, Vercel Sandbox, the Workflow SDK, and the Chat SDK. CEO Guillermo Rauch used the launch to argue that the company is becoming infrastructure for the "agent era," and he brought numbers. Vercel says agent-triggered deployments grew from under 3% of commits to more than 50% in six months, and token volume through its AI Gateway rose from 2 million to 20 million.
The most credible evidence is that Vercel runs eve itself. The company says it operates more than 100 agents in production on the framework, including a data analyst that fields over 30,000 Slack questions a month, a support agent it credits with resolving 92% of tickets autonomously, and a revenue-operations agent built by non-engineers in six weeks. Treat the specific figures as vendor claims, because they are. But a framework its maker depends on at that scale is a different proposition from one shipped as a demo.
How to Think About Adopting It
eve is a strong piece of engineering, and for teams already on Vercel it lowers the cost of getting an agent to production in a real way. The decision to use it, though, sits downstream of harder questions that no framework answers for you.
The first is whether the agent should exist at all. The documented failure mode for agentic AI is not bad plumbing. It is automating a workflow that was never worth automating, or handing autonomy to a process that needed a form. eve makes building faster, which makes building the wrong thing faster too.
The second is lock-in, and it cuts both ways. The framework is open source and the model layer is portable, both genuine. But the production story, durable execution, sandboxing, and the dashboard, is most seamless on Vercel's own platform. That is a reasonable trade for many teams and a dealbreaker for a few. It is a decision to make deliberately, with eyes open, not one to back into because the scaffolding was convenient.
The third is governance. The approval gates, eval suites, and OpenTelemetry traces eve provides are the right primitives. They are not a policy. Who approves what, what an agent is allowed to touch, and how you prove after the fact that it behaved are organizational decisions the framework can enforce but cannot make.
How This Maps to How Honra Works
At Honra we sit on the client's side of these decisions. We do not resell frameworks or take a margin on the tools a client adopts, so our read on eve is the same one we would give privately: it is a serious option, well suited to teams already invested in Vercel, and the framework choice is the smallest of the choices in front of you.
The work we care about is the work eve does not do. Deciding which processes deserve an agent and which deserve a fix elsewhere. Setting the governance and approval model before the first agent ships, not after an incident. Building the thing directly when that is the right call, with the same judgment we bring to advising on it, and working alongside the implementers a client already has when it is not. eve removes a real category of busywork from that build. It does not remove the judgment, and that is the part worth getting right.
Key Takeaway
eve is Vercel making a credible claim that the production infrastructure of AI agents can be standardized the way web infrastructure was, backed by a framework it runs at scale on itself. For teams building agents, especially on Vercel, it is worth a serious look. Just keep the order of operations straight: decide whether the agent should exist, how it will be governed, and what you are willing to depend on, and only then decide which framework builds it.
