Vercel shipped eve on June 17 — an open-source agent framework with a genuinely simple premise: every AI agent is a directory of files. Markdown for instructions and skills. TypeScript for tools. A channel file per deployment target. You add a file, you get a capability. For developers who have spent the past year gluing together agent infrastructure from five different libraries, it lands at exactly the right time.
Every Agent Is a Folder #
The central idea in eve is filesystem-first agent architecture. An eve agent lives in an agent/
directory, and its capabilities are determined entirely by what’s inside:
agent/instructions.md
— the always-on system promptagent/tools/*.ts
— one TypeScript file per callable tool; the filename becomes the tool name, no registration requiredagent/skills/*.md
— Markdown playbooks loaded on demand, only when relevantagent/channels/*.ts
— platform deployment targets (Slack, Discord, HTTP, GitHub, and more)agent/subagents/
— child agents for delegated subtasks
Adding a Slack integration means adding channels/slack.ts
. Adding a new tool means dropping a TypeScript file in tools/
. No YAML configs. No runtime registration calls. No framework documentation to re-read every time you add a feature.
The minimal working agent is two files. First, agent/instructions.md
:
You are a helpful assistant. Answer questions clearly and concisely.
And agent/agent.ts
:
import { defineAgent } from 'eve';
export default defineAgent({
model: 'openai/gpt-5.4-mini',
});
Run npx eve@latest init my-agent
, then pnpm dev
, and you have a local agent running in under a minute.
The Infrastructure You Would Have Had to Build Yourself #
What separates eve from a hobbyist framework is what ships alongside that directory model. Every eve agent includes durable execution via Vercel Workflows — checkpointed steps, session state persistence, resumption across messages. It also includes sandboxed compute (isolated VMs, default behavior), model-agnostic routing via AI Gateway so you can swap providers without touching orchestration code, and built-in OpenTelemetry observability with zero setup.
This addresses a real problem. Through most of 2025, building a production agent meant assembling a framework for orchestration, a database for memory, Temporal for durable execution, a custom sandbox, and a model client — before writing a single line of actual agent logic. Eve collapses that stack into the deployment target itself.
Vercel runs more than a hundred agents on eve in production, including one handling over 30,000 support questions per month. That’s not a toy.
Tools Look Exactly Like You’d Want Them To #
Tool definitions in eve are straightforward. Create a file in tools/
, define the function, export it:
// agent/tools/get_weather.ts
import { defineTool } from 'eve/tools';
import { z } from 'zod';
export default defineTool({
description: 'Get current weather for a city',
parameters: z.object({ city: z.string() }),
execute: async ({ city }) => {
const res = await fetch(`https://weather.example.com/${city}`);
return res.json();
},
});
The tool name is get_weather
— derived from the filename automatically. No registration step. No manifest update. This is the kind of DX decision that makes a framework feel considered rather than assembled.
One Agent, Every Surface #
The same agent logic deploys to Slack, Discord, Microsoft Teams, Telegram, Twilio, GitHub, Linear, or a plain HTTP API — add a channel file per target, and the agent’s instructions and tools are shared across all of them. For teams that want the same internal knowledge agent available in Slack for engineers and in Teams for business stakeholders, this is a meaningful reduction in maintenance overhead. You don’t fork the agent per channel; you extend it.
The Part Worth Reading Before You Commit #
Eve is Apache 2.0 and technically runs wherever TypeScript runs. But the production experience — durable execution via Vercel Workflows, sandboxed VMs, model routing via AI Gateway, credential management via Vercel Connect — is Vercel-proprietary infrastructure. Porting eve to another host means rebuilding adapters for each of those components. The framework permits it; nothing makes it easy.
This is the Next.js playbook. Next.js is open source, and advanced features like ISR and Edge Middleware work on other hosts in principle. In practice, the path of least resistance is always Vercel. Eve is structured the same way.
That’s not a dealbreaker, but it should be a deliberate decision. If your team already deploys on Vercel, eve is likely the fastest path to production agents available today. If you run on AWS, GCP, or self-hosted Kubernetes, the lock-in cost is real — Mastra or LangGraph may serve you better.
Eve is also still in public beta. APIs and behavior can change before GA. Factor that in for production-critical workloads.
Who Should Use eve Now #
If you are already on Vercel and want to ship a production agent — an internal knowledge bot, a GitHub issue triage agent, a customer-facing support assistant — eve removes more friction than any alternative available today. The infrastructure stack that used to take a week to assemble ships automatically. The developer experience is genuinely well-considered.
If you need deployment flexibility, self-hosting, or framework-agnostic tooling, wait for GA or pick something less opinionated. The lock-in is real and currently non-trivial to escape.
Vercel published the official announcement at Ship London, with full documentation at vercel.com/docs/eve. The framework is open source on GitHub. For a broader competitive breakdown, The New Stack’s coverage is worth reading alongside this.