A Quick Example: Building an Agent with Vercel's Eve Framework

Vercel's eve is an open-source framework for building AI agents, released in public preview in mid-2026. The pitch Vercel makes is "Next.js for agents": an agent is just a directory of files, where a file's name and place in the tree define what it does. There is no registration boilerplate and no orchestration glue to write — you add a file, and the framework wires it up.

It is worth being precise about what eve is, because the name invites confusion. Eve is not a coding agent that edits your repository and opens pull requests. It is a framework you use to build and run your own agents — the kind that answer questions in Slack, triage issues, or automate a back-office workflow. This post is a quick, concrete example of that build loop.

The mental model: an agent is a directory

The core idea is that everything about an agent lives in files under version control. A minimal agent is essentially two files:

agent/
  agent.ts          # model configuration
  instructions.md   # the system prompt — the agent's role
  tools/            # TypeScript files; each becomes a callable tool
  skills/           # markdown files encoding domain knowledge

The filename is the definition. Drop a TypeScript file into tools/ and the model can call it — the filename becomes the tool name, with no registration step. Because it is all just files in a directory, a new prompt, tool, or skill is an ordinary commit with a diff, a review, and a history.

Scaffolding

You start a new agent with a single command, which installs dependencies, scaffolds the project, and starts a local dev server:

npx eve@latest init my-agent

Within a minute you have an agent running locally that you can talk to. The generated agent/instructions.md is where you describe the agent's role in plain Markdown — this is the highest-leverage file in the project, and it reads like an onboarding doc for a new teammate rather than code.

Adding a tool

Tools are how the agent does anything beyond generating text. Each tool is a single TypeScript file in tools/, and the filename becomes the tool name. A trivial example — a tool that looks up the current deployment status — is just an exported function with a typed schema:

// agent/tools/deploymentStatus.ts
export const schema = {
  description: 'Get the current production deployment status for a project',
  parameters: {
    project: { type: 'string', description: 'The project slug' },
  },
};

export async function run({ project }: { project: string }) {
  const res = await fetch(`https://api.internal/deployments/${project}/latest`);
  const data = await res.json();
  return { state: data.state, url: data.url, createdAt: data.createdAt };
}

No wiring, no registry entry. The model sees deploymentStatus as an available tool because the file exists.

What the framework handles for you

The reason to use eve rather than assembling this yourself is the infrastructure it bundles:

• Durable execution. Every conversation runs as a durable workflow built on Vercel's Workflow SDK, with each step checkpointed. A session can pause, survive a crash or a redeploy, and resume exactly where it stopped — you do not manage that state yourself.
• Sandboxing. Code the agent runs is isolated from your application, backed by Docker locally or Vercel Sandbox in production.
• Channels. Agents reach users through adapter files for Slack, Discord, Microsoft Teams, Telegram, Twilio, GitHub, and Linear. The same agent runs on every channel; adding one is a single file.

Deploying

Because an eve agent is an ordinary Vercel project, shipping it is the same command you would use for any site:

vercel deploy

The same directory that ran on your laptop runs in production unchanged — the sandbox swaps from Docker to Vercel Sandbox with no code change. And because it is a normal Vercel project, every commit gets its own preview deployment, and that preview carries the agent's channels with it. In practice that means you can talk to the next version of your Slack bot in a preview environment before it replaces the one your team uses every day.

When this is worth it

Eve is a good fit when you want to own an agent as part of your codebase — reviewed in pull requests, deployed on your own infrastructure, and connected to your internal tools — rather than configuring a hosted agent product you do not control. The filesystem-first model keeps the whole thing legible: you can read an agent's entire behavior by reading its directory.

It is a heavier choice than a no-code assistant builder, and that is the point. If your requirements are a durable, sandboxed, multi-channel agent that lives in Git alongside the rest of your services, having the framework handle execution, isolation, and channels — while you focus on instructions.md and a handful of tool files — is a genuine reduction in what you have to build.

Takeaway

The build loop is short: scaffold with npx eve@latest init, describe the role in instructions.md, add capabilities as files in tools/, and ship with vercel deploy. The framework absorbs the parts that are tedious and easy to get wrong — durable state, sandboxing, and channel plumbing — and leaves you with a plain directory of files you can read, review, and version like any other code.

If you already deploy on Vercel, scaffolding one small agent is a low-cost way to see whether the filesystem-as-agent model fits how your team wants to build.