AIArticle
By turning agent capabilities into filesystem directories, Vercel targets the messy state management and sandboxing of production AI.
Building an AI agent today feels a lot like building a web application in 2012. Developers spend eighty percent of their time hand-rolling state machines, configuring sandboxes for untrusted code execution, writing boilerplate to persist chat history, and wiring up API integrations. The actual agent logic, the system prompt and the tool definitions, gets buried under a mountain of infrastructure code.
With the release of Eve, an open-source, Apache-2.0 licensed framework, Vercel is attempting to do for AI agents what Next.js did for React. By introducing a strict, filesystem-based convention, Eve shifts the developer's job from orchestrating infrastructure to simply defining capabilities.
It is a compelling design pattern, but it also represents a calculated strategic play. As developers increasingly "vibe-code" internal tools that bypass corporate IT, Vercel is positioning Eve, alongside its new enterprise security features, as the standardized control plane for production AI agents. For developers, the question is whether the framework's exceptional developer experience is worth buying into Vercel's infrastructure gravity.
The Architecture: Filesystem as the Orchestrator #
Most existing agent frameworks, such as LangGraph or CrewAI, rely on programmatic graph construction. You instantiate a state graph, define nodes and edges, register tools via code, and manually compile the runtime.
Eve throws that out in favor of a filesystem-first architecture. In an Eve project, the directory structure is the application architecture. A typical agent is organized like this:
my-agent/
└── agent/
├── agent.ts # Model and runtime configuration
├── instructions.md # System prompt / identity
├── tools/ # Typed TypeScript functions
│ └── get_weather.ts
├── skills/ # Reusable procedures and knowledge
├── channels/ # Slack, Discord, or HTTP API adapters
└── schedules/ # Cron-based recurring tasks
At build time, Eve's compiler automatically discovers these files and registers them. If you drop a TypeScript file into tools/
, the agent immediately knows how to call it. If you add a Markdown file to skills/
, the agent ingests that domain knowledge.
This filesystem-first approach drastically simplifies multi-agent delegation. To create a subagent, you simply create a subdirectory inside subagents/
with its own instructions and tools. The parent agent can then delegate tasks to this subagent as if it were any other tool, executing it in its own isolated environment before receiving the result.
Solving the Production Hard Parts: Durability and Sandboxing #
While the filesystem convention is elegant, Eve's real value lies in how it handles the two hardest problems of running agents in production: state preservation and security.
First, agents are inherently long-running. They call slow APIs, wait for human approvals, and can run for hours or days. If the server restarts mid-run, a typical agent loses its place. Eve solves this by making every conversation a durable workflow built on Vercel's open-source Workflow SDK. Every step, model call, and tool execution is checkpointed. If a container restarts or a deployment occurs, the agent resumes exactly where it left off without re-running expensive LLM steps.
Second, letting an LLM write and execute code is a security nightmare. Eve addresses this by isolating all agent-generated code execution. By default, the framework runs code inside secure sandboxes. Locally, this can run via Docker or local bash adapters. In production, it defaults to Vercel Sandbox, keeping untrusted execution entirely separate from your primary application runtime.
The Developer Angle: Writing an Eve Agent #
To understand how this works in practice, consider how you define a tool. Instead of writing complex schemas for tool calling, you write standard TypeScript and validate inputs using Zod.
Here is a mock weather tool placed in agent/tools/get_weather.ts
:
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
};
},
});
To configure the agent's brain, you edit agent/agent.ts
:
import { defineAgent } from "eve";
export default defineAgent({
model: "anthropic/claude-sonnet-4.6",
});
Running npx eve dev
starts a local development server with an interactive terminal UI. The framework handles the context window compaction, tool formatting, and execution loop under the hood.
When it is time to deploy, running vercel deploy
pushes the agent to production. However, this highlights the primary tension of the framework. While Vercel CTO Malte Ubl asserts that the company is committed to making Eve work on any platform, early beta users have already noted that the CLI requires a Vercel login even when configured to use external LLM providers.
For teams committed to other cloud providers, writing custom adapters for the durable workflow storage, sandboxed execution, and OAuth handling will require significant engineering effort compared to using Vercel's native serverless primitives.
The Strategic Play: Taming Shadow AI #
Eve did not launch in a vacuum. It debuted alongside Vercel Passport, an identity control layer designed to put employee-built AI apps under enterprise control.
We are seeing a massive wave of shadow IT where developers and non-technical staff use LLMs to "vibe-code" internal tools. These apps run on personal Vercel accounts, using corporate data but bypassing security policies. By offering Eve as a highly attractive, free framework, Vercel is establishing the standard programming model for these agents.
Once a team adopts Eve, the path of least resistance for enterprise security is to adopt Vercel's broader suite: Passport for OIDC identity management, Vercel Connect for secure OAuth token management, and Bring Your Own Cloud (BYOC) to run Vercel's platform on the customer's own AWS infrastructure. It is a classic developer-led adoption funnel.
The Verdict #
Eve is a highly opinionated, beautifully designed framework that successfully tames the chaotic state management of AI agents. If you are already in the Vercel ecosystem, adopting Eve is a no-brainer. It eliminates the need to stitch together separate libraries for sandboxing, tracing, and durability.
For teams committed to alternative architectures, such as Cloudflare Workers or raw AWS Lambda, Eve is still worth watching. The filesystem-first convention is likely to be copied widely. However, until the community builds robust, production-grade open-source adapters for non-Vercel runtimes, deploying Eve outside of Vercel's cloud will feel like swimming upstream.
Sources & further reading #
Vercel Introduces Eve, an Open-Source Framework for Building AI Agents— infoq.com - Introducing eve - Vercel— vercel.com - Vercel launches eve, an open-source framework that treats agents as directories - The New Stack— thenewstack.io - Vercel debuts eve open source agent framework, tries to fix shadow AI with Passport— devclass.com - GitHub - vercel/eve: The Framework for Building Agents · GitHub— github.com
Rachel Goldstein· Dev Tools Editor
Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop.
Discussion 0 #
No comments yet
Be the first to weigh in.