Vercel's Eve: File-System-First AI Agents with Durable Persistence

What It Is: File System as Interface

Most agent frameworks solve how to connect models and tools. Getting a demo running is easy; the hard part is keeping it alive as a service for a month: process restarts, deployment updates, users returning days later to continue the conversation.

Vercel officially open-sourced eve in June 2026 (5.5k stars, Apache-2.0). Its entry point is exactly that problem — a framework designed for durable backend agents.

The homepage subtitle states the positioning plainly: "Like Next.js for agents. File system based and production ready." Just as Next.js did for frontend, eve uses file-system conventions to write agents and targets production directly.

Eve's core design claim in one sentence: agents are written with files, not assembled with code.

An eve agent project structure looks like this:

my-agent/
└── agent/
    ├── agent.ts          # optional: model and runtime config
    ├── instructions.md   # required: standing system prompt
    ├── tools/            # optional: typed functions the model can call
    │   └── get_weather.ts
    ├── skills/           # optional: on-demand loaded procedures
    │   └── plan_a_trip.md
    ├── channels/         # optional: message channels (HTTP, Slack, Discord)
    │   └── slack.ts
    ├── schedules/        # optional: cron jobs
    │   └── weekly_recap.ts
    ├── connections/      # optional: external MCP or OpenAPI services
    └── subagents/        # optional: expert sub-agents
        └── researcher/

This convention replaces "assembling an agent with a giant configuration object." In LangChain, CrewAI, etc., you compose objects, wire connections, and register tools in code. Eve lets you drop files into directories; the file names themselves carry semantics: instructions.md is the system prompt, each file under tools/ is a tool, each subdirectory under subagents/ is an expert sub-agent.

The practical benefits: an agent's capability boundaries can be ls 'd, changing a tool means editing one file, and team review of agent behavior becomes like reviewing a codebase. It ships full documentation to node_modules/eve/docs so coding agents can read it directly.

Project: eve Stars: 5.5k+ Language: TypeScript License: Apache-2.0 Status: Beta (API may change) Site: eve.dev GitHub: github.com/vercel/eve

What's Inside: Full Capability Map

Framework capabilities fall into several categories, all declared via files under the agent/ directory.

Instructions — instructions.md (or .ts) is the standing system prompt, required.

Tools — Each .ts under tools/ declares a tool with defineTool(), input validated by zod schema:

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 };
  },
});

Skills — Markdown under skills/ are on-demand loaded procedure descriptions. Unlike instructions (present every turn), skills load only when the model judges them applicable, saving tokens.

Connections — connections/ hook external MCP servers or OpenAPI services.

Channels — channels/ declare message entry points. Official coverage is extensive: HTTP, Web Chat, Slack, Discord, Teams, Telegram, GitHub, Linear, iMessage (Linq), Twilio SMS/voice, plus custom via chat-sdk.

Sandbox — Each agent gets a sandbox rooted at /workspace. Built-in bash, read_file, write_file tools run inside it. On Vercel it automatically uses Vercel Sandbox; self-hosted can use Docker, microsandbox, or custom.

Subagents — Each directory under subagents/<id>/ is an expert with its own instructions, tools, and sandbox.

Schedules — Files under schedules/ are periodic tasks (cron).

State / Memory / Context Control — Persist state across turns, control what the model sees, integrate external memory services.

Evals — Test agent behavior.

Extensions — The repo also hosts eve-code (coding agents), eve-computer-use, eve-git, eve-self-modification, etc.

The Real Differentiator: Durable Execution

If you only saw the above, eve would look like a "file-based agent framework" — not worth a dedicated write-up.

Its skeleton is the execution model . Work in eve splits into three layers:

session — the entire persistent conversation or task, spanning days or weeks, surviving process restarts and redeployments.

turn — all work triggered by one user message until the agent replies.

step — durable checkpoint inside a turn. By default one step contains one model call plus its inline tool calls.

The key is the step. Every session runs as a durable workflow (built on the open-source Workflow SDK; on Vercel it uses Vercel Workflow). At each step boundary a checkpoint is persisted. This means: if the process crashes mid-way, restart resumes from the last step boundary — completed model and tool calls are not re-executed.

Hence a counter-intuitive effect: your tools, sandbox ops, and sub-agent calls feel synchronous ( await works), yet the whole conversation is durable and resumable. The framework internalizes the contradiction of "write like synchronous code, but survive interruption."

One layer up, long conversations blow the context window, so there is compaction : by default when conversation volume nears a threshold ( thresholdPercent 0.9), earlier turns are summarized into a checkpoint preserving progress, decisions, constraints, and references. After compaction, the session migrates to a fresh workflow run on the same deployment — because each run records every executed step, a run lasting weeks would carry its entire history.

There is also cross-deployment handoff : on Vercel, after a deployment update, a new message delivery hands off idle session state to the new deployment. The session keeps the same ID and event stream; the next turn uses the new deployment's model, instructions, and tools. In-flight work does not migrate mid-run — sessions with running turns, awaiting human input, queued messages, or active sub-agents stay on the original deployment.

This stack is the dividing line between "agent as toy" and "agent as service." Most frameworks have no answer here; they just say "store history yourself."

A Complete Scenario: Subagents and Tasks

Eve's subagent design deserves separate attention because it ties into durability.

The root agent gets a built-in agent tool by default; the model can invoke it to delegate a task to a replica of the root agent (shares sandbox, inherits same tools, but has a fresh conversation history and state). You can also declare expert subagents under subagents/<id>/ with their own agent.ts and description.

Critical detail: every subagent invocation runs as a task .

The call immediately returns a receipt with a taskId; the subagent works while the parent agent continues its own work; the subagent's final reply becomes the task result. The parent's turn does not block waiting for the subagent. The subagent's session can later be continued using the same taskId.

For "wait for result then continue" scenarios (e.g., approve before deploy), don't force it on this async model — put both sides inside a single workflow tool ( ctx.agent() called by name).

One deliberate restriction: the built-in agent tool exists only on the root agent . Replicas cannot use it, and declared subagents don't get it either. This prevents infinite recursive delegation.

How to Use

Create project: npx eve@latest init my-agent It scaffolds directories, installs deps, initializes Git, opens a terminal UI. Defaults to openai/gpt-6-luna-fast with high reasoning. Switch model with --model, set reasoning level with --reasoning.

Run locally:

cd my-agent
npm run dev

Add Web Chat UI (requires Vercel project):

npx eve link
npx eve add channel/web

Deploy: npx eve deploy Prerequisites: Node.js 24+, plus a model credential. Can use ChatGPT subscription, Vercel account, or AI Gateway / OpenAI / Anthropic API keys — no Vercel project needed to start chatting .

Don't want Vercel? Works anyway. Eve is frontend-agnostic: embed in Next.js, Nuxt, SvelteKit, TanStack Start; self-host as Node service (Nitro output); swap sandbox for Docker. Local models supported — point at any OpenAI-compatible endpoint (Ollama, LM Studio, llama.cpp, vLLM all work).

Is It Worth Using?

First, status clarity: eve is in Beta; the framework, API, docs, and behavior may change before GA , under Vercel's beta terms.

Repo activity shows both velocity and newness: 744 open issues, top contributors are Vercel employees with 100+ commits each, bot roboeve[bot] also on the leaderboard. npm latest is 0.79.2 with a parallel 0.6.0-beta line.

It fits:

Teams running agents as backend services. Durable sessions, checkpoint resume, deployment handoff, compaction — these are eve's core features, rarely found as a cohesive implementation elsewhere.

Teams that believe in convention over configuration. File-system-as-interface makes agent capabilities ls -able, reviewable, and readable/writable by coding agents (it ships docs and can self-modify instructions/tools/skills).

Existing Vercel users. AI Gateway with one-line model IDs, Vercel Sandbox, Vercel Workflow, Cron, OIDC auth, observability — the whole chain is seamless.

Teams needing multi-channel routing. Slack threads, Discord, Telegram, GitHub, Linear all have official channels; each channel thread auto-maps to a durable session.

It does not fit:

Teams needing stable APIs for production today. Beta phase, behavior will change.

Teams wanting lightweight one-off scripts. A framework designed for "weeks-long persistent sessions" is overkill for a 20-line agent.

Teams avoiding Vercel flavor. Self-host path exists (Node service + own sandbox + own workflow world), but smoothness lags behind the pure Vercel route.

One Must-Mention Detail: Defaults Are Permissive

Eve's docs have a dedicated section on responsibility boundaries, worth quoting its key points — by default, eve agents may run in permissive configuration : approvals omitted means tools execute without human confirmation, sandbox network egress is not deny-all.

The docs explicitly state two sentences: don't rely solely on model behavior to prevent sensitive or irreversible operations; the deployer is responsible for configuring approval policies, tool restrictions, connection scopes, routing/session auth, sandbox controls, and telemetry export.

This isn't unique to eve, but they put it upfront. Before using eve, decide clearly what your agent can touch and what it can act on.

Back to the Opening Question

What makes eve worth watching isn't that it's another agent framework. It's that this framework treats "durable agent" as the first-principle problem — file system is the interface, workflow is the skeleton, every step has a checkpoint, sessions survive deployment updates.

Vercel has a natural place here: it already operates "request in, run to completion, state remains" infrastructure; agents happen to be that workload.

The watershed in agent building is shifting from "can it run?" to "can it be operated?"

GitHub: github.com/vercel/eve