Vercel eve and the shape of agents

Vercel released eve at Ship London on June 17, 2026 as an open-source framework for building AI agents. The pitch is that an agent is a directory: instructions, tools, skills, channels, and schedules are all files in a tree, and the framework reads the tree, validates a manifest, and runs the result.

The framing in the announcement is "Next.js for agents." It is the same company making that comparison about its own most successful product. The framing is worth taking seriously for that reason. It is also worth scrutinising, because the hardest parts of shipping an agent are rarely the parts a framework can solve.

This post breaks down what eve actually changes, what it deliberately leaves to the team building on it, and how we at Senrok are thinking about adopting it.

The problem eve is solving

For the last three years, every agent framework has had roughly the same shape. You import a library. You instantiate an agent class. You register tools as decorated functions. You write some glue to persist state, retry tool calls, surface logs, and ship it as a long-running process. The "agent" exists at runtime. There is no canonical file you can point at and say this is the agent.

This works until you ship the second agent. Then the same scaffolding appears again, slightly different, and by the third or fourth agent every team in the company is maintaining their own version of durable execution, sandboxing, approvals, and tracing. None of it carries over. The plumbing is the same. The implementations are not.

eve's claim is that this plumbing has converged enough to standardise. The structure is the same regardless of what the agent does, so the framework can own the structure and let teams focus on the work the agent performs. That is the bet.

An agent is a directory

The most distinctive choice in eve is the filesystem-first model. There is no large config object. The agent is the directory, and each capability has a named home.

agent/
  agent.ts                  # model + runtime config
  instructions.md           # system prompt, personality
  tools/                    # one .ts file per tool
  skills/                   # on-demand markdown playbooks
  subagents/                # delegated child agents
  channels/                 # Slack, Discord, HTTP, etc.
  schedules/                # cron-style triggers
  connections/              # MCP, OpenAPI, OAuth-backed
  sandbox/                  # per-agent isolated runtime

The minimum viable agent is two files: a model declaration and a system prompt.

import { defineAgent } from "eve";
 
export default defineAgent({
  model: "anthropic/claude-opus-4.8",
});

# Identity
 
You are a senior data analyst. You answer questions about the team's data.
 
- Prefer exact numbers to hand-waving. If you can compute it, compute it.
- State the assumptions behind any number you report.
- Use the tools available to you rather than guessing. If you cannot answer
  from the data, say so plainly.

Adding a capability is a matter of dropping a file in the right folder. A tool is a typed TypeScript file, a skill is a markdown playbook, a channel is an adapter, a schedule is a cron expression and a handler. There is no separate registration step. The directory is the contract.

import { defineTool } from "eve/tools";
import { z } from "zod";
import { runReadOnlySql } from "../lib/sample-db";
 
export default defineTool({
  description:
    "Run a read-only SQL query against the orders and customers tables.",
  inputSchema: z.object({
    sql: z.string().describe("A single read-only SELECT statement."),
  }),
  async execute({ sql }) {
    const { columns, rows } = await runReadOnlySql(sql);
    return { columns, rows: rows.slice(0, 500), truncated: rows.length > 500 };
  },
});

Why this matters beyond aesthetics

Filesystem-first looks like an organisational preference, but the consequences run further than that.

Agents become diffable

A change to an agent is a commit, not a code change buried in a Python module. A team can review "this agent now has access to the delete-customer tool" as a one-line pull request. Tool descriptions, system prompts, and the new schedule for the Monday report are all versioned together with the rest of the codebase. That is the same property that made package.json and package-lock.json possible, and the same property that lets a frontend PR carry an agent change as a side effect.

Skills become importable

A skill is a markdown file. A team can copy refunds.md from one agent to another, fork a third-party agent and modify three files, or publish a library of skills that drop into any eve project. The unit of reuse is the file, not a code dependency.

Conventions carry over between teams

When every agent in a company has the same shape, the same operational tooling works on all of them. The same trace viewer, the same eval runner, the same deploy pipeline. The cost of the second agent is dramatically lower than the cost of the first, and the cost of the tenth is lower still. This is the part of the bet that has the longest tail.

What eve ships with

A framework is only as useful as the production concerns it absorbs. Here is the list of things eve claims to handle out of the box, and the engineering reality of each.

Durable sessions

Every conversation is a durable workflow with each step checkpointed. A session can pause, survive a crash or a deploy, and resume exactly where it stopped. Under the hood, eve uses the open-source Workflow SDK to make sessions resumable, idempotent, and crash-safe.

This is genuinely hard to build from scratch. Most teams who try end up writing a state machine on top of Postgres, a queue, and a lot of try/catch logic. Having it built in is a meaningful reduction in surface area.

Sandboxed compute

Agent-generated code should be treated as untrusted. Eve keeps it out of the application runtime entirely: every agent gets its own sandbox, an isolated environment for shell commands, scripts, and file operations, running in a separate security context from the harness that controls the agent.

The default backend is Vercel Sandbox in production, with Docker, microsandbox, or just-bash for local development. The adapter pattern means the team is not locked to a single provider.

For a team that has not yet had to handle the security review of an agent that can run bash, this is the part that buys the most sleep. For a team that already runs agents in production, the local development story is what makes it actually usable day to day.

Human-in-the-loop approvals

Any tool can be configured to require approval, and the agent will pause there and wait — indefinitely if it has to — without consuming compute. Once approved, eve continues the task right from where it left off.

import { defineTool } from "eve/tools";
import { z } from "zod";
import { runReadOnlySql, estimateScanGb } from "../lib/sample-db";
 
export default defineTool({
  description: "Run a read-only SQL query against the warehouse.",
  inputSchema: z.object({ sql: z.string() }),
  needsApproval: ({ toolInput }) => estimateScanGb(toolInput.sql) > 50,
  async execute({ sql }) {
    return runReadOnlySql(sql);
  },
});

The semantic is exactly right. Approvals are a property of the tool, not a separate workflow construct. The agent does not need to know which of its tools require review. The framework pauses on the ones that do, surfaces the request to the operator, and resumes when the webhook arrives.

This lines up with how we think about checkpoints at Senrok: they belong at the point of no return, they should be triggered by a defined condition, and they should not block the workflow unnecessarily. Eve ships the machinery for all three.

Subagents

A subagent is the same shape, one level down. A directory inside subagents/ with its own instructions, tools, and sandbox. The parent calls it the same way it calls a tool, and the child starts with a clean context window and only the tools it was given.

import { defineAgent } from "eve";
 
export default defineAgent({
  description:
    "Investigates anomalies in the data before the analyst reports them.",
  model: "anthropic/claude-opus-4.8",
});

This is the right primitive for breaking a complex agent into maintainable pieces. The risk is the same one any multi-agent system has: a parent and child can disagree about which one is responsible for a given step, and the failure modes are not always obvious. The clean shape helps, but it does not eliminate the design work.

Tracing and evals

Every run produces a trace. Each model call and tool call appears in order with its inputs and outputs, down to the commands the agent ran in its sandbox. The spans are standard OpenTelemetry and export to any tracing service — Braintrust, Raindrop, Arize, Honeycomb, Datadog, or Jaeger. Evals are scored test suites you can run locally or wire into CI.

import { defineEval } from "eve/evals";
import { includes } from "eve/evals/expect";
 
export default defineEval({
  description: "The analyst answers revenue questions by the team's rules.",
  async test(t) {
    await t.send("What was revenue last week?");
    t.completed();
    t.calledTool("run_sql");
    t.check(t.reply, includes("net of refunds"));
  },
});

This is the part of the framework that pays for itself fastest. Tracing turns "the agent did something weird" into a specific span with inputs, outputs, and timing. Evals turn a prompt change from a gamble into a CI check.

What eve deliberately does not solve

The framework is honest about its scope, but it is worth being explicit about what remains on the team's plate after adopting it.

The orchestration policy is still your job

Eve ships the loop, the durability, the sandbox, and the approval machinery. It does not decide which tools exist, when the agent should escalate, or what a low-confidence answer looks like in your specific workflow. That policy lives in the tools you write, the instructions you author, and the boundaries you set on the model. A team that adopts eve without investing in the policy will end up with a fast, well-traced, badly-behaved agent.

The model is still the model

Eve routes through the Vercel AI Gateway, which means provider fallbacks, retries, and observability across providers are handled. It does not make a non-deterministic model deterministic. Every assumption in this and other posts about agent systems still applies: the model will be wrong sometimes, the system needs to detect that, and the recovery path cannot depend on the model never failing.

The integration is still the work

Eve ships connectors for Slack, GitHub, Snowflake, Salesforce, Notion, and Linear at launch, plus a generic MCP and OpenAPI bridge for everything else. The framework discovers the tools and brokers auth. It does not write your business logic. The run_sql tool still needs to know which Postgres connection string is appropriate, which tables the agent is allowed to query, and how to enforce row-level security in a way the framework cannot infer.

The system around the agent is still the system

When Vercel says more than 100 of its own agents run on eve, the framework is what makes them consistent. The thing that makes them correct is still the work of the teams that built them: the data layer they read from, the permissions they enforce, the human checkpoints they require, and the eval suite that catches regressions before users do. eve reduces the cost of consistency. It does not replace the engineering.

How to think about adopting it

The right way to evaluate eve depends on the kind of agent team you already have.

You are shipping your first agent

Eve is a reasonable default. The local-first dev loop is fast, the production story is taken care of, and the shape of the project matches the shape of the work. The framework is opinionated enough that you spend less time on the plumbing and more time on the agent's actual job. The cost of being wrong about the framework is low because the project is small.

You already have two or three agents in production

This is the most interesting case. You have most of the plumbing eve provides, but it lives in three different codebases, written by three different teams, and none of them match. Eve is not a free migration. It is a consolidation opportunity, and the migration is most valuable when you commit to porting the fleet rather than running two systems in parallel. Plan a quarter for the port, not a sprint.

You are evaluating a build-vs-buy decision

Eve is open source and self-hostable, which means it is closer to "build" than "buy" in the relevant sense. You own the deployment, the upgrade path, and the operational risk. The bet is that the standardisation across agents is worth more than the loss of flexibility. For a company with three or more internal agents, that bet usually pays off. For a company with one, it is harder to justify the cognitive overhead of learning the framework before the second agent exists.

You are running agents at serious scale already

At a certain size, the lock-in concern becomes real. The framework is Apache-2.0, the Workflow SDK is open source, and the AI Gateway is a managed service. The runtime adapters for sandboxes mean the underlying compute is swappable. None of that removes the cost of migrating off the framework later. It does, however, keep the cost bounded — eve is not a walled garden, and a determined team can replace any of its parts.

What this means for the agent ecosystem

The interesting thing about eve is not the framework itself. It is the direction it points.

The first wave of agent frameworks was about giving developers primitives to call. LangGraph gave you a graph. CrewAI gave you roles. OpenAI's SDK gave you tool calls. They were libraries you imported.

The second wave is about giving teams a shape. An agent is a directory. A tool is a file. A skill is a markdown file. The framework reads the tree, validates the manifest, and runs the result. The unit of reuse is the file, and the unit of review is the pull request. The unit of operation is the directory, and the unit of consistency is the shape.

This is what made Next.js work for the web. It is not the only way to build a website, but it is the way that makes a hundred small frontends in a company feel like one codebase. If eve does the same for agents, the agents that win will not be the most clever ones. They will be the ones whose teams could ship the tenth one as cheaply as the first.

What we are doing with it

At Senrok, we build production agent systems for companies that have workflows with real consequences: underwriting, compliance review, internal request routing, customer operations. Our pattern is the Sense · Reason · Rock loop, with deterministic checks and human checkpoints at every point of no return.

We are evaluating eve the same way we evaluate any new framework: not by whether it can run a demo, but by whether it can hold up under the operational conditions our clients care about. The durable sessions, the sandbox story, the approval primitive, and the OpenTelemetry export are the parts that map directly onto the production requirements we already have. The filesystem-first model is the part that changes how a team collaborates on an agent over its lifetime, which is where most of the long-term cost lives.

The honest answer is that we do not yet know whether eve will be the framework our agent projects standardise on. What we know is that the problem it is solving — the same plumbing, rebuilt in every team — is the same problem we have been solving by hand for the last three years. If the framework holds up under real workloads, the answer to whether to adopt it is obvious. We are watching the early production deployments with interest and will write again once we have something to say from direct operational experience.