Vercel built another agent framework. Here is why, and who should care.

eve – The Agent Framework - Vercel

Like Next.js for web apps, but for agents. Markdown for instructions and skills, TypeScript for tools. Durable by default.

Vercel

Vercel released eve in June. It is an open source framework for building and running AI agents, and the pitch is simple: an agent is a folder of files, and the production plumbing comes built in. At Softmax we spend a lot of our hours wiring that plumbing by hand for clients, so we took a close look.

What eve actually is

eve is filesystem-first. You do not write an agent loop. You put files in the right places and the framework finds them at build time:

my-agent/
└── agent/
    ├── agent.ts            # model and runtime config
    ├── instructions.md     # the always-on system prompt
    ├── tools/              # typed TypeScript functions the model can call
    ├── skills/             # markdown procedures loaded on demand
    ├── subagents/          # child agents with their own tools and sandbox
    ├── connections/        # MCP servers and OpenAPI backends
    ├── channels/           # Slack, Discord, Teams, HTTP
    └── schedules/          # cron jobs

The smallest agent that runs is two files: a model and a set of instructions. Tools are TypeScript with a Zod schema. Instructions and skills are markdown. The filename is the tool name. There is no registration step.

Under the hood it sits on the Vercel AI SDK, so it runs any model the AI SDK supports. Model IDs go through Vercel's AI Gateway by default, with provider fallback if one goes down.

Status as of October 2026: public beta, Apache 2.0 license, about 5,600 GitHub stars, version 0.6x. The API is still moving.

Why another framework when LangGraph and CrewAI exist

Three reasons, and only one of them is in the marketing.

Vercel built it for themselves. They run more than a hundred agents internally: a data analyst in Slack that answers 30,000 questions a month, an SDR agent, a support agent that closes 92% of tickets on its own, a content review pipeline, and a router that sends every request to the right agent. Those started as separate projects, each with its own way of storing state, handling credentials, and emitting logs. The same structure kept showing up. eve is that structure turned into a framework. Their line is "agents have a shape." It is the same move they made with Next.js: let hundreds of people build the same thing by hand, then ship the pattern.

The existing frameworks solve orchestration, not operations. LangGraph gives you a graph of nodes and edges. CrewAI gives you roles and crews. Both are good at the loop. Neither gives you a sandbox for code the model writes, a Slack channel with approval buttons, a cron schedule, a trace you can replay, or a deploy command. That is the gap between "it works on my laptop" and "200 people use it in Slack and it survives a redeploy." eve is aimed at that gap. The agent logic is the part you still write. Everything around it is a default.

Vercel sells compute. Durable sessions run on Vercel Workflow. The sandbox runs on Vercel Sandbox. Models route through AI Gateway. OAuth to Slack and Salesforce goes through Vercel Connect. Traces land in Vercel Observability. eve is the on-ramp to all of it. This is not a criticism. It is the same business model as Next.js, and it is worth knowing before you adopt it.

What you get out of the box

• Durable sessions. Every conversation is a checkpointed workflow. It can pause for days waiting on a human, survive a crash or a deploy, and resume where it stopped. Built on the open source Workflow SDK.
• A sandbox per agent. Code the model writes runs in an isolated environment, not in your app process. Vercel Sandbox in production, Docker or similar locally.
• Approvals. Add needsApproval to a tool and the agent waits for a person. In Slack that shows up as a button. No compute is burned while it waits.
• Channels. HTTP is on by default. Slack, Discord, Teams, Telegram, Twilio, GitHub, and Linear are one file each. A session can start in one channel and continue in another.
• Connections. Point a file at an MCP server or an OpenAPI spec. The model gets the tools, never the credentials.
• Schedules. A cron expression and a handler. Deploys as a Vercel Cron job.
• Tracing. Every turn produces OpenTelemetry spans. Export to Datadog, Honeycomb, Braintrust, whatever you already run.
• Evals. Test files that send a message and assert on which tools were called and what came back. Run locally or in CI as a deploy gate.

Pros and cons

What we like

• Almost no boilerplate. Two files to a running agent, and the dev loop is one command with a terminal UI that shows every tool call.
• Production concerns are defaults, not add-ons you bolt on in month three.
• Non-engineers can read it. The instructions and skills are markdown, and a prompt change is a Git diff with a review.
• Coding agents are good at it. The docs ship inside the npm package, and the file conventions are predictable, so Claude Code or Codex can scaffold a working agent from a short prompt.
• It is proven at scale. Vercel's own numbers are real production numbers, not a demo.

What gives us pause

• It is beta. Early users report canary dependencies breaking tool loops mid-run and webhook paths failing silently. Pin your versions and commit the lockfile.
• It is Vercel-first. Self-hosting exists now (eve build, eve start, Postgres for workflow state, Docker for the sandbox), but it is the second path, not the happy path. The default authenticator is Vercel OIDC. Expect friction if you leave the platform.
• TypeScript only. If your team lives in Python, this is not for you.
• Convention is magic. Filename equals tool name is lovely until a tool is not being discovered and you have to figure out why.
• The ecosystem is young. 5,600 stars against LangGraph's 43,000 means fewer examples and fewer answered questions.
• Vercel's track record on lock-in with Next.js is a known debate. Decide for yourself how much that matters.

How it compares

The closest comparison is Mastra. Both are TypeScript, both are built on the AI SDK, both bundle agents, workflows, and evals. Mastra is more portable and has a head start. eve has the sandbox, the channels, and the tighter Vercel integration. The Claude Agent SDK and Google ADK are a different category: they are the model vendor's own harness, and they make the most sense if you are committed to that vendor.

Hello world

Scaffold a project. This installs dependencies, initializes Git, and starts a dev server.

npx eve@latest init hello-agent

Replace agent/instructions.md:

You are a concise weather demo assistant. Tell users that the weather data is mocked.

Pick a model in agent/agent.ts:

import { defineAgent } from "eve";

export default defineAgent({
  model: "anthropic/claude-opus-4.8",
});

Add a tool at agent/tools/get_weather.ts. The filename becomes the tool name.

import { defineTool } from "eve/tools";
import { z } from "zod";

export default defineTool({
  description: "Return mock weather data for a city.",
  inputSchema: z.object({ city: z.string().min(1) }),
  async execute({ city }) {
    return { city, condition: "Sunny", temperatureF: 72 };
  },
});

Run it:

npm run dev

Ask it about the weather in Vancouver and you will see the tool call and the reply in the terminal. That is a working, durable agent with a sandbox and a trace.

Want a human to sign off before a tool runs? One more field:

export default defineTool({
  description: "Delete a customer record.",
  inputSchema: z.object({ customerId: z.string() }),
  needsApproval: true,
  async execute({ customerId }) {
    // ...
  },
});

Deploy with vercel deploy. Add Slack with eve channels add slack. The same folder runs in production the way it ran on your laptop.

Who this is for

A good fit

• TypeScript teams already on Vercel. The friction is close to zero.
• Internal agents: Slack bots, data analysts, support triage, ops automation. The channels and approvals are where eve earns its keep.
• Small teams without a platform engineer who still need durable sessions and a sandbox.
• Projects you want a coding agent to build end to end. The conventions make that reliable.

Not a fit

• Python teams. Use LangGraph or CrewAI.
• Regulated environments where you have to own every piece of infrastructure. Most of our clients in mortgage, legal, and government are here. Self-hosting eve is possible, but you are swimming against the current.
• Workflows that need an explicit, auditable graph with branching you control step by step. That is LangGraph's job.
• Anyone with a hard "no Vercel" rule.

Our take: if you are shipping an internal agent on a TypeScript stack and you are fine with Vercel, eve removes most of the work we normally charge for. If you need to run it inside your own VPC, wait a few releases and see how the self-host path matures.

Links: Announcement, GitHub, Docs