Vercel eve: the framework that wants to do for agents what Next.js did for the web

eve is Vercel's open-source framework in which an AI agent is an ordinary folder of files: instructions in Markdown, tools in TypeScript, with channels and a schedule alongside them. The framework takes over the layer that teams usually write for themselves: durable sessions, an isolated sandbox, approval gates and evaluations. Vercel says it runs more than 100 such agents in production itself, and the framework's code is on GitHub under the Apache 2.0 licence.

An agent as a folder of files

The most interesting thing about eve is not what the framework can do but where it keeps the decisions. The agent's behaviour is described in agent/instructions.md, a plain Markdown file. The model and environment settings live in agent/agent.ts. Every file in the agent/tools/ folder is one tool, and the file name becomes the name the model sees: get_weather.ts produces a tool called get_weather. There is no separate registry where all of this has to be declared a second time.

The practical consequence is that you understand what an agent does by reading its folder tree. A new developer on the team reads files instead of reconstructing behaviour from configuration scattered across the project. It is the same shift front-end development went through when a file dropped into the right folder started to become a page. Anyone who has assembled an agent loop by hand knows how much time disappears into gluing it together from separate parts.

A project starts with one command. npx eve@latest init my-agent installs the dependencies, creates the scaffold, initialises a Git repository and starts a development server, so the first session with the agent happens on your own machine, before anything goes near the cloud.

What the framework takes off your hands

These are the parts that a hand-built agent forces you to write and then maintain. Vercel describes them as follows:

• Durable sessions. Each conversation is a durable workflow whose state is saved after every step, so a session can pause, survive a crash or a deployment, and resume exactly where it stopped.
• An isolated sandbox. Every agent gets its own isolated environment for shell commands, scripts, and reading and writing files.
• Approval gates. Any action can be marked as needing human approval. The agent stops at that point and waits, with no time limit.
• Channels. One agent can serve many surfaces, and each channel is a small adapter file. The list includes Slack, Discord, Teams, Telegram, Twilio, GitHub and Linear.
• Evaluations. Scored test suites that you run locally or wire into your CI pipeline.
• The rest of the scaffolding. Subagents, run tracing and cron-style scheduled tasks.

For a business, approval gates carry the most weight, because they concern money and data rather than developer convenience. An agent with access to your inbox, your CRM and your payments that never has to ask anyone for permission is exactly the class of risk we covered when writing about agentjacking (in Polish): slip the agent a crafted message and you can push it into an action nobody asked for.

A good framework does not give an agent new abilities. It removes the scaffolding that stood between the idea and a working product.

Why the comparison with Next.js

Vercel draws the comparison itself. Its launch post says outright that Next.js ended the boilerplate problem for the web, and that eve does the same for agents. The comparison rests on one mechanism: convention over configuration. Instead of declaring in code that a given module is a tool, you put a file in the agreed place, and the framework takes over the agent loop and hands the model the list of available actions on its own.

The company backs this up with figures about its own scale. According to Vercel, a year ago agents triggered fewer than 3% of deployments on its platform, and the figure is now around 29%. That number describes activity on Vercel, not the wider market, and it comes from a party with a stake in the result, so treat it as a sign of direction rather than an industry measurement.

What this means for a small business

Directly, probably not much: eve is a tool for development teams that write TypeScript. Indirectly, quite a lot, because it is setting the list of things that should come as standard in any proposal for an AI agent, rather than as paid extras.

If a supplier quotes you for an agent that will reply to customers or keep an eye on orders, ask four questions. Will a session survive a server restart and the deployment of a new version? Does the agent's code run in isolation from the rest of your systems? Which actions need a person to click "approve"? How will the supplier measure whether the agent answers well, and how will they show you that measurement? That is exactly the set eve ships by default. A supplier with no answers to these questions is selling a demo, not a system.

For many firms the sensible answer is not a custom agent at all. If a process can be written down as a sequence of steps with clear conditions, a no-code automation tool such as Make, n8n or Zapier can be the cheaper and faster route. And if the job is answering customers' questions from your own documents, the quality of those answers depends heavily on how the documents are retrieved, which starts with how they are cut into pieces before a model reads them. We explain that step in our piece on chunking.

There is also a job that no agent framework does for you. When a buyer asks an AI assistant which supplier to hire, what matters is whether it names your company in the answer. That is a matter of Generative Engine Optimization, and it is the work we do.

The other side of the coin

Vercel's documentation labels eve as a beta and warns that the framework, its API, its documentation and its behaviour may change before a stable release. That is not a minor footnote. A project built on a beta today may need parts rewritten a few months from now, so pin specific package versions from the start and commit the dependency lock file to your repository.

The second issue is platform dependence. The framework code is open and you can run an agent locally, but the production setup described in the documentation rests on one company's services: session state is kept by Vercel Workflows, isolation comes from Vercel Sandbox, model requests go through AI Gateway, and tokens and integration keys are held by Vercel Connect. The Apache 2.0 licence gives you freedom over the code, not over that foundation, and running the whole stack somewhere else is left outside the scope of Vercel's documentation.

Then there are the numbers. More than 100 agents in production, an internal data-analyst agent answering more than 30,000 questions a month, a support agent that closes 92% of tickets without help: Vercel published all of these figures about itself, and nobody independent has reproduced them. Until someone does, they are marketing material, even if they are accurate. Your own decision needs your own measurements: the cost of one session, the response time, and the share of cases the agent genuinely closes without a human.

On top of that comes the token bill, which grows differently with agents than with an ordinary chat, because a single case often takes a dozen or more model steps and several tool calls. Estimate the cost of one resolved case, not of one message.

Where to start if you want to try it

1. Pick one narrow process with a measurable outcome, such as qualifying enquiries from a contact form, rather than your entire customer service.
2. Set up the scaffold locally and run a first session through it before you deploy anything to a server.
3. Mark every action that sends, pays or deletes as needing approval. Reading data can go ahead without asking.
4. Write evaluations based on several dozen real cases from your own inbox before the agent sees its first customer.
5. Measure the cost and duration of one session on a sample, and only then work out what the agent saves in staff time.

If you would rather hire a supplier than build this yourself, the four questions above are a good way to open the conversation, and we have gathered a longer checklist in our guide to choosing an AI implementation partner (in Polish).

Common questions

What is eve?

It is Vercel's open framework for building AI agents. An agent is a folder of files: instructions in Markdown, tools in TypeScript, and the framework adds durable sessions, a sandbox, approval gates and evaluations. The code is on GitHub under the Apache 2.0 licence.

What does the Next.js analogy actually mean?

Next.js replaced configuration with convention: a file in the right place becomes a page. In eve, a file in the agent/tools/ folder becomes a tool, and the file name is the name the model sees. Convention instead of registering every element by hand.

Is eve ready for production?

Vercel reports more than 100 of its own agents in production, but Vercel's own documentation describes eve as a beta and warns that the API and behaviour may change before a stable release. For a pilot, yes. For a system that must never stop, not yet.

Does eve lock you into Vercel?

The framework itself is open and runs locally. In the production setup described in the documentation, durable sessions rely on Vercel Workflows, isolation on Vercel Sandbox and connections on Vercel Connect. Running it outside that platform is something Vercel's documentation leaves outside its scope.

Sources: Vercel launch post, Vercel documentation, InfoQ, vercel/eve repository on GitHub.

Neurise editorial team · published 17 June 2026 · updated 28 September 2026