Vercel's Eve turns AI agents into a folder of markdown files

Picture the last AI agent you tried to ship to production. Somewhere in there you probably hand-rolled a queue system so long-running tasks wouldn't die on a redeploy, wired up a sandbox so the model couldn't nuke your filesystem, bolted on Slack or Discord as an afterthought, and wrote a pile of glue code just to let a human approve a risky action before it fired. None of that is "the agent." That's just plumbing. And every team building agents ends up rebuilding the same plumbing from scratch.

Vercel just shipped a framework that treats all of that as a solved problem, and the way it does it is genuinely unusual: your agent isn't a graph, a chain, or a class hierarchy. It's a folder.

What is Vercel Eve exactly?

Eve is a filesystem-first framework for durable AI agents where core agent capabilities live in conventional locations, making projects easier to inspect, extend, and operate. Vercel launched it in public preview at their Ship conference, and the pitch is blunt: building an agent should mean defining what it does, not assembling all the plumbing that an agent needs to run in production.

The company is comparing it directly to its own flagship product. Vercel describes eve as "Next.js for agents," referring to the popular web framework Vercel created and maintains. That's not just marketing fluff, either — one of the parallels with Next.js is that eve defines an agent similarly to the way Next.js defines a web app, where a single directory holds all the individual files that define what the agent does.

You can check out the Eve documentation and the GitHub repository directly. The project is published as the npm package eve, licensed under Apache-2.0, so it's fully open source and free to inspect, fork, or self-host the parts that don't depend on Vercel's infrastructure.

Why build agents as a folder of files?

This is the part that actually changes how you think about agent development. Instead of writing orchestration code, you organize a directory. A typical project looks like: agent.ts for optional model and runtime config, instructions.md as the required always-on system prompt, a tools/ folder for typed functions the model can call, skills/ for procedures loaded on demand, channels/ for message channels like HTTP, Slack, or Discord, and schedules/ for recurring cron jobs.

That structure alone tells you almost everything about what the agent does without opening a single line of orchestration logic. Each file describes one component of the agent, and at a glance, the tree shows what an agent is and does — it also shows where it lives and when it acts on its own.

The barrier to entry is deliberately low. The smallest agent that runs is just two files: a model and a set of instructions. Write a plain-English system prompt in markdown, point it at a model, and you have a working agent. Want to give it a new capability? You add a tool, skill, channel, or schedule by adding a file, and eve picks them up at build time and wires them in for you, so there's no boilerplate to register them.

That instructions.md file isn't a toy example either — Vercel's own sample shows an agent whose entire personality and rules of engagement fit in a few markdown bullet points, things like preferring exact numbers over hand-waving and stating the assumptions behind any figure it reports.

What ships in the box for production?

This is really the headline feature. Most agent frameworks give you orchestration logic and leave the production concerns to you. Eve flips that. The framework ships with six production capabilities included by default: durable execution, sandboxed compute, human-in-the-loop approvals, subagents, OpenTelemetry tracing, and a built-in evals system.

Here's what each of those actually buys you:

Durable execution. Every conversation is a durable workflow, with each step checkpointed, so a session can pause, survive a crash or a deploy, and resume where it stopped — built on the open-source Workflow SDK. That means you can push a new deploy in the middle of a long-running agent task without losing the user's progress.

Sandboxed compute. Agent-generated code isn't trusted by default. Every agent gets its own sandbox for shell commands, scripts, and file reads and writes, with the backend running as an adapter — Vercel Sandbox in production, or Docker, microsandbox, or just-bash locally.

Human-in-the-loop approvals. For anything sensitive, you can require a human sign-off before an action executes. Any action can be set to require approval, and the agent pauses there and waits, indefinitely if needed, without consuming compute — once approved, eve continues from where it left off. That "waits without consuming compute" detail matters a lot in practice; you're not paying for an idle process sitting around for three days waiting on someone to click approve in Slack.

Secure connections. Hooking up to external services is handled without exposing credentials to the model. In eve, a connection is a file that points at an MCP server or any API with a compatible OpenAPI document — eve discovers the remote tools, hands them to the model, and brokers the auth, and the model never sees the connection's URL or credentials, with Vercel Connect handling interactive OAuth with consent and token refresh built in. At launch, eve agents can connect to Slack, GitHub, Snowflake, Salesforce, Notion, and Linear, plus anything else reachable over OAuth, an API key, or an MCP server.

Multi-surface channels. You don't rebuild your agent for every place people want to talk to it. Most agents live in exactly one place because every new surface is its own integration to build, but in eve, the same agent serves every surface and each channel is just a small adapter file — the HTTP API is on by default, with Slack, Discord, Teams, Telegram, Twilio, GitHub, and Linear included.

Vercel isn't just theorizing about this either. Eve is the framework Vercel builds and runs its own agents on, and according to Vercel, it runs more than a hundred agents in production today.

How do you actually build your first agent?

Getting started takes one command. This creates a new my-agent directory, installs its dependencies, initializes Git, and starts the interactive terminal UI. Head to the official Getting Started guide for the current setup instructions, and check the eve GitHub README for the exact CLI syntax, since the framework is still in active beta and commands can shift.

The rough workflow looks like this:

1. Scaffold the project. Run the CLI init command to generate a fresh agent/ directory with the minimum required files.
2. Write instructions.md. This is your system prompt, in plain markdown. Describe the agent's role, its tone, and any hard rules it needs to follow.
3. Add tools as TypeScript files. Drop a file in tools/ and the model can call it. Add a TypeScript file to tools/ and the model can call it — the filename becomes the tool name, no registration required.
4. Add skills for on-demand knowledge. Skills are markdown playbooks loaded when they are relevant, so the agent gets focused guidance without carrying it in every prompt. This is a clever way to keep your context window lean — the agent only pulls in the "how to plan a trip" playbook when someone actually asks about trip planning.
5. Wire up channels. Add a channel file and the same agent starts responding in Slack, Discord, Teams, or a web chat interface without duplicating any logic.
6. Deploy. Because eve compiles the directory into an app that runs on Vercel Functions, shipping to production is close to a single deploy command rather than a separate infrastructure project.

If you want to go deeper on any single piece — subagents, scheduling, sandbox configuration — the documentation covers the full project layout and guides for each folder type, and it's worth reading before you touch real or sensitive data, since Vercel explicitly recommends reviewing which default tools, custom tools, MCP tools, and connected services are available to the agent before using eve with non-public, sensitive, regulated, or production data.

How does Eve stack up against Mastra, LangGraph, and the rest?

Eve isn't launching into an empty field — it's landing in a market that's already crowded. Its closest TypeScript-native rival is Mastra, a Y Combinator-backed framework built to run on any platform in contrast to eve's default to Vercel, while LangChain's LangGraph is Python-first and centers on the same durable execution eve offers, and Inngest's AgentKit is another TypeScript option with built-in durability. The big cloud providers are circling the same space too, with Cloudflare building agents on Workers and Durable Objects, Amazon's Bedrock AgentCore, Google's Vertex AI Agent Engine, and Microsoft's Agent Framework offering managed runtimes that can run agents from any framework.

The real philosophical difference is where each framework puts its attention. Most competing frameworks focus on the agent's logic — how to orchestrate steps, manage memory, define execution graphs — while eve takes that part as given and shifts attention to the production infrastructure: deploy, durability, sandbox, observability, approvals. As one comparison put it, where LangGraph asks you to draw a graph of states, eve asks you to create files and takes care of turning them into a deployable service.

Worth noting: the trade-off is real, not hidden. Eve is tightly coupled to Vercel's own infrastructure — Sandbox, Workflows, AI Gateway, Connect — so you're buying convenience by leaning into their platform. If you need to run somewhere else entirely, that's a bigger lift than it would be with a platform-agnostic framework like Mastra.

Should you actually build on Eve right now?

The honest answer: it depends on your tolerance for beta software. The framework is currently in public beta, and Vercel says the APIs and behavior may change before general availability. That's not a knock — it's just the reality of a project that launched a few weeks ago and is already iterating fast. The GitHub Discussions page is active and Vercel is clearly treating early feedback seriously.

If you're already deployed on Vercel, already comfortable with TypeScript, and tired of rebuilding the same durability-and-sandbox scaffolding for every new agent idea, Eve removes a genuine amount of tedious work. If you need multi-cloud flexibility or you're deep in the Python ecosystem, it's worth watching from a distance for now rather than betting production workloads on it today.

Either way, the underlying idea is worth internalizing regardless of which framework wins: the hard part of shipping agents was never really the prompt. It was everything standing between "works on my laptop" and "survives a redeploy at 2am." Whoever solves that plumbing problem best is going to own a lot of the next few years of agent development — and right now, Vercel just made a very serious opening move.