Vercel's pitch for eve is that agents today are where the web was before frameworks: everyone hand-rolling the same sessions, retries, streaming, and sandboxes, one project at a time. Its answer is that an agent should just be a directory. The idea is genuinely good, the engineering is better than the launch coverage suggested, and the defaults are looser than you want. All three things are true at once.
What eve actually is
eve is Vercel's open-source framework for durable backend AI agents, announced on June 17, 2026 at its Ship 26 conference and licensed Apache-2.0. Its one idea is filesystem-first: you define an agent as ordinary files under an agent/ directory, and eve discovers them, validates them, compiles a manifest, and serves the runtime as a deployable app. The README is blunt about the motive: core agent capabilities live in conventional locations, so projects are easier to inspect, extend, and operate.
The pitch is convention over configuration, borrowed wholesale from Next.js, and Vercel makes that comparison itself rather than leaving it to the press. The claim underneath is fair: stop hand-assembling sessions, retries, streaming, and sandboxes for every agent you build, and let a framework own the parts that are the same every time. The smallest working agent is two files, an instructions.md holding the prompt and an agent.ts naming a model.
The directory is the API
The layout is the entire interface, and it is worth reading as a list, because the list is the product. instructions.md is the always-on system prompt. agent.ts holds runtime config through defineAgent, mostly the model. Each TypeScript file in tools/ is one typed tool, and the filename becomes the tool name the model sees, so adding a capability is adding a file and there is no registry to update. Files in skills/ are on-demand procedures the model loads only when relevant, which keeps the always-on prompt small. subagents/ holds child agents that run with fresh conversation history and their own state.
The rest of the tree is the production surface. channels/ turns the same agent into an HTTP endpoint, a Slack bot, or a Discord bot without touching the tools, so a weather tool never learns whether the question came from a browser or a chat window. connections/ wires in services you did not author, either an MCP server or any API described by an OpenAPI document. hooks/ and schedules/ cover event side effects and cron. The payoff is legibility, and it is not a small one: the tree tells you what the agent can do, and a capability change shows up as a file in a diff instead of a mutation buried in a graph.
What comes in the box
The most useful thing eve ships is what happens when something goes wrong. Sessions run on the open-source Workflow SDK, which persists progress as an event log and deterministically replays it to reconstruct state. A session is the durable conversation or task; each message or event is a turn. Because progress is a replayable log rather than a live process, a session survives cold starts, redeploys, and long pauses waiting on a tool result, and resumes where it stopped. Be honest about the novelty, though: durable execution is becoming table stakes rather than a moat, and LangGraph and Cloudflare's Durable Objects reach the same place by other routes.
The sharper differentiator is the sandbox, because most frameworks make you bring your own. Every eve agent gets one: an isolated bash-style environment with its own filesystem that the built-in bash, read_file, and write_file tools target, running on ephemeral microVMs on Vercel and on Docker or a backend you write anywhere else. Around it sit the things teams usually bolt on late: an Agent Runs dashboard showing sessions, turns, tool calls, timing, and token usage with no instrumentation file, and an eve eval command with assertions and a judge that can gate CI, so the agent can be held to a standard rather than a vibe. Skills follow the same SKILL.md convention as the broader Agent Skills standard, so a skill written for that standard ports across as-is.
Secure architecture, insecure defaults
The security model is the best documentation eve ships and the part most coverage skipped. The trust boundary is drawn in the right place: your secrets, your environment, and your application code live in the app runtime, and the sandbox gets none of them. Even the built-in bash, read_file, and write_file tools run in the app runtime and proxy into the sandbox, so the model sees tool definitions and results and never your keys. Credentials are brokered at the sandbox firewall rather than handed to the agent, connection tokens are never serialized into durable state, channel signatures are verified in constant time, authentication fails closed unless you explicitly ask for none, and skill frontmatter is treated strictly as data with the code-executing engines disabled. That is a better posture than most agents we are asked to review.
Then read the responsible-use page, which is unusually candid: unless you configure stricter controls, eve agents may operate with permissive settings, including tool execution without human approval where approval is omitted, and sandbox network egress that is not deny-all. Read that twice, because it is the oldest failure mode in security: sound architecture, loose defaults. An agent that can read your data and reach the open internet is one prompt injection away from posting it somewhere, and the docs tell you to close that gap rather than closing it for you. So we close it: approval gates on anything irreversible, deny-all egress with an explicit allow-list, and nothing unattended near data that matters. The framework gives you the controls. Turning them on is still your job.
What you own, and what you rent
The framework is Apache-2.0 with no strings in the license, it is built on the Vercel AI SDK, it is bring-your-own-model, and it runs locally. What is not free is the runtime. On Vercel the durability is Vercel Workflows, the sandbox is Vercel Sandbox, the compute is Vercel Functions, and the observability is a Vercel dashboard. There is no eve line on the bill: you pay for functions, workflow events, sandbox time, and model tokens, so a chatty agent is a cost centre rather than a rounding error.
The lock-in question has a better answer than launch week suggested, and if you read a take from June saying eve cannot be self-hosted, it has already expired. The docs now cover deploying without Vercel: eve build writes standard Nitro output, eve start runs it as an ordinary Node service, and you put TLS, routing, and logs around it like any other process. Workflow execution and sandbox execution are separate runtime adapters rather than hidden couplings, so durability can sit on Postgres and the sandbox can sit on Docker, and Vercel's own labs published a proof of concept doing exactly that on a plain virtual machine.
So the lock-in is ergonomic rather than architectural. That is a real distinction, and it is still a real cost. Self-hosting means pinning beta-line workflow packages to the protocol eve vendors, giving the workflow data somewhere durable to live, and knowing the traps: a reverse proxy that forwards the eve path but not the workflow callback path will let sessions start and then stall them forever, silently. You also give up Vercel Cron, sandbox prewarm, and the Agent Runs dashboard, which is much of what made the framework attractive in the first place. Off Vercel, eve is a good framework. On Vercel, it is a platform. Price that honestly rather than discovering it in month four.
When we'd reach for it
We reach for eve when a client wants a durable, multi-turn backend agent living in the TypeScript codebase they already have, and when Vercel is already where they deploy. In that case the trade is excellent: durability, a sandbox, channels, evals, and observability land on day one instead of consuming three sprints of plumbing nobody will thank you for, and the file layout keeps the thing legible six months later when someone else has to change it.
We hesitate mostly on age. eve is roughly a month old as of this writing, still below version 1.0, shipping releases most days, and depending on beta-line packages for its own durability core, while the docs call it beta and the changelog calls it a public preview. It is Vercel-staffed rather than community-driven, the open issues skew toward the seams you would expect, including deploying to Vercel itself, and there is no first-class memory, so anything that must outlive a session is yours to build. We would not put it under a regulated workload yet, and we would pin every version if we shipped it at all. If you are weighing the alternatives, the companion pieces "What Is OpenClaw? The Local-First AI Agent, Explained" and "Hermes Agent, Explained for Operators" cover the own-your-hardware end, and "Claude Managed Agents, Explained for Operators" covers the fully hosted end. eve sits between them: you own the definition, and you rent the durability.