# Vercel's eve and the agent-as-a-directory bet

URL: https://www.thedeepfeed.ai/posts/2026-06-21-vercel-eve-agent-framework-directory-of-files/
Category: Tools
Published: 2026-06-17
Author: the-deep-feed
Tags: eve, vercel, agents, typescript, harness
Kind: deep

> Vercel open-sourced eve at Ship London — a framework where an agent is a folder of files. We built 75 agents on it and ran an adversarial review. Here's what holds up, what breaks, and the stateful-on-stateless tension the launch posts skip.

## TL;DR

- Vercel open-sourced **eve** on **June 17** at Ship London — a framework built on one idea: **an agent is a directory**. `instructions.md` is the prompt, `tools/*.ts` are typed actions, `skills/*` are markdown procedures, `agent.ts` is config. We didn't take the launch post's word for it: we built a **75-agent monorepo** on eve in its first week and ran a **code-grounded adversarial review** (1 P0, 4 P1, 8 P2). This piece is what that surfaced.
- **The durability is real and we proved it the hard way:** save a value, kill the dev server entirely, start a new process with a different PID, recall the value through the same continuation token. State survived a full restart and the sandbox reconnected to the *same* Firecracker microVM.
- **The tension the launch skips is stateful guards on stateless serverless.** We wrote a cost cap the obvious way — a module-scoped counter — and on Vercel it silently became a *per-request* cap with a check-then-act race. The fix (a concurrency queue, durable-state budget) is real work the framework makes possible but does not do for you.
- eve and **Flue** are the two poles of the TypeScript agent debate — **deploy gravity vs portability** — and we have the receipts: one agent running identically on both took a custom resolver and sandbox backend. shadcn's **agentcn** builds on both.
- **The 'APIs may change' warning was not boilerplate.** In the week after launch eve went 0.11 → **0.13.3**: 0.13.0 *removed* the top-level `auth` field from `defineTool()` (credentials now resolve inline via `ctx.getToken(provider)`), Connections landed (MCP + OpenAPI servers the model calls without ever seeing the URL or token), and the Slack channel matured. The convention is stable; the surface around it still moves weekly.

![A labeled agent directory tree (instructions, tools, skills, sandbox) compiling into a deployed serverless function](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/hero-agent-directory.jpg)

On June 17, at Vercel Ship London, **Vercel** open-sourced an agent framework called **eve**. The pitch fits in one screenshot, which is exactly how the company posted it:

> Introducing eve, an agent framework.
>
> agent/ · agent.ts · instructions.md · tools/ · skills/ · sandbox/ · schedules/ …
>
> Like Next.js, for agents.
>
> — [@vercel](https://x.com/vercel/status/2067180054979936413), June 17, 2026

The framing is a deliberate echo. Next.js won the frontend framework wars by making a *convention*, where files in a `pages/` directory become routes, feel so obvious that wiring a router by hand started to look like busywork. eve makes the same move for agents. An agent is not an object you instantiate or a graph you assemble. It is a **directory**, and the framework's job is to read that directory and turn it into a running, deployable, durable backend service.

That is the claim. We wanted to know whether it survives contact with production, so we did not write a docs walkthrough. We built **75 agents** on eve during its first week: framework fixtures, real-world job templates, monid-integrated production agents, and a set of deliberate stress tests. Then we put the whole thing through an adversarial, code-grounded review. One P0, four P1, eight P2 findings came out. This piece is what we learned: what eve gets right, what quietly breaks, and the one architectural tension that decides whether your agent ships correct or teaches you a lesson in an incident review.

# An agent is a directory

The whole framework rests on a single convention. From the [official docs](https://vercel.com/docs/eve): *"eve is a filesystem-first framework for durable backend AI agents. You define each agent with files under an `agent/` directory. eve discovers those files and compiles them into an app that runs on Vercel Functions."*

The directory has a fixed vocabulary, and each entry maps to a concept the agent needs to do real work:

| File / folder | Role |
|---|---|
| `instructions.md` | The system prompt. Required. Plain markdown, the agent's identity and operating rules. |
| `agent.ts` | Config — which model, context window, runtime options. |
| `tools/*.ts` | Typed functions the agent can call. **Filename sets the tool name.** |
| `skills/*` | Markdown procedures loaded on demand — reusable expertise. |
| `sandbox/` | The isolated environment for code, file, and shell execution. |
| `subagents/` | Specialist agents the parent can delegate to. |
| `schedules/` | Cron-style scheduled runs. |
| `evals/` | First-class tests, run with `eve eval`. |

This is not a loose suggestion. eve *discovers* by convention: drop a file named `get_weather.ts` in `tools/` and the agent gains a `get_weather` tool with no registration step. We leaned on this hard — across 50 catalog agents, a tool is frequently a one-line re-export whose only job is to set the name from the filename:

```typescript
// agent/tools/load_dossier.ts
export { loadDossierTool as default } from "@eve-agents/agent-kit/tools";
```

The contrast with the incumbent TypeScript approach is the point. In Vercel's own AI SDK, in LangGraph.js, in most frameworks, the agent's capabilities are assembled imperatively — you build a tool object, push it into an array, pass the array into a constructor. eve replaces all of that with the filesystem, the same way Next.js replaced router config with a folder.

![Side-by-side: imperative tool registration as tangled wiring on the left, a clean labeled file tree on the right, the right side accented in red](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/convention-vs-config.jpg)

# The smallest eve agent

A minimal agent is `agent.ts` plus `instructions.md`. The config file is almost empty — it declares a model and a context window, and eve provides everything else (the session runtime, multi-turn history, image attachments, output schemas). This is verbatim from a fixture we ported from upstream:

```typescript
// agent/agent.ts

export default defineAgent({
  model: "openai/gpt-5.4-mini",
  modelContextWindowTokens: 131072,
});
```

```markdown
<!-- agent/instructions.md -->
You are a helpful assistant.
```

That is a complete, runnable agent. `eve dev` starts a local server exposing a session protocol at `/eve/v1/session`; `eve build` produces deployable output; `eve eval` runs the tests. The prompt lives in markdown, deliberately separated from the TypeScript, so a non-engineer can edit the agent's behavior without touching code — the same split that made Claude Code skills and Cursor rules portable.

# Tools are typed functions with an approval verb

A tool is a Zod schema plus an `execute` function. What makes eve's tool model distinctive is that **approval is a first-class field**, not an afterthought. Here is a real side-effecting tool from one of our integration agents — a refund that must not fire without a human:

```typescript
// agent/tools/refund_charge.ts

export default defineTool({
  description: "Refund a charge by id. Requires human approval before executing.",
  inputSchema: z.object({
    chargeId: z.string().min(1),
    amount: z.number().positive(),
  }),
  needsApproval: always(),
  async execute({ chargeId, amount }) {
    return { chargeId, amount, status: "refunded", refundId: `re_${chargeId}_${Date.now()}` };
  },
});
```

`needsApproval` takes a verb — `never()`, `once()`, `always()` — and that verb is the human-in-the-loop boundary. A read-only lookup uses `never()`. A side-effecting action uses `always()` or `once()`, and eve **durably parks the turn** at the tool call until a human approves or denies.

The HTTP flow is concrete, and we exercised it end to end: a client does `POST /eve/v1/session`, the stream emits `input.requested` carrying a `requestId` and approve/deny options, then `session.waiting`. The client later resumes by posting back the decision:

```json
POST /eve/v1/session/:id
{ "continuationToken": "...", "inputResponses": [{ "requestId": "...", "optionId": "approve" }] }
```

The stream then emits `action.result` and `message.completed`. A `deny` skips execution entirely. The reason this pause is even possible is the part that matters most, and it is the next section.

# Durable by construction — and we proved it

The word eve uses for itself is *durable*, and it is load-bearing. From the [launch post](https://vercel.com/blog/introducing-eve): *"eve is designed around the idea that building an agent should mean defining what it does without assembling all of the pieces that it needs to run in production."* The pieces it assembles for you are the hard ones, durable session state, sandbox isolation, and a deploy target, built on three Vercel primitives:

| eve concept | Vercel primitive | What it buys |
|---|---|---|
| Durable sessions | Vercel Workflows | State and progress survive failures, restarts, and a human approval that takes three days |
| Sandbox | Vercel Sandbox | Isolated code/file/shell execution per agent |
| Deploy target | Vercel Functions | The compiled agent runs as a serverless function |

We did not want to take "durable" on faith, so we built a test designed to break it. An agent writes a random marker, `PURPLE-42-<rand>`, to `/workspace/state.txt` inside its sandbox. Then we **kill the dev server entirely**: not a graceful restart, a different process ID. A second process starts and recalls the value using the same `continuationToken`. Two things have to be true for that to work, and both were: eve persisted the session state across a full process death, and the custom sandbox backend reconnected to the *same* microVM rather than booting a fresh one.

The mechanism is worth seeing, because it is where durability stops being a marketing word:

```typescript
// agent/sandbox/sandbox.ts

// On dispose the VM is paused, not killed, so the next turn reconnects to the
// same VM with /workspace intact — even across a full process restart, because
// eve persists the reconnect metadata in durable session state.
export default defineSandbox({
  backend: superserveBackend({ fromTemplate: "superserve/base", timeoutSeconds: 3600 }),
});
```

Under the hood, `dispose()` calls `sandbox.pause()` rather than `kill`, `captureState()` returns a `{ superserveSandboxId }` that eve persists, and the next `create()` sees that id and calls `Sandbox.connect()` instead of creating a new VM. This is the single hardest thing to build correctly in a production agent — a session that can stop, wait three days for a human to click approve, and resume on a different machine as if no time had passed. eve's bet is that most teams should not build it at all. They should inherit it from the framework. That bet is sound, and the proof ran on our own hardware.

![A durable session timeline where a turn parks at a human-approval gate, persists to a workflow store, then resumes on a different machine with the same sandbox reconnected, the approval gate marked in red](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/durable-session-resume.jpg)

[@pkorac](https://x.com/pkorac/status/2067954274412228663), coming out of Ship, framed the consequence as a unit-of-deployment shift:

> Hyped and inspired coming from Vercel Ship 2026. Their new OSS Eve framework will change how easy it is to build/iterate/monitor agents. Are we going from micro-services to micro-agents?
>
> — [@pkorac](https://x.com/pkorac/status/2067954274412228663), June 19, 2026

"Micro-services to micro-agents" is the right frame for what Vercel is selling: the same operational ergonomics it gave serverless functions, applied to autonomous agents.

# The tension nobody puts on the landing page

Here is the part the launch posts do not dwell on, and the part that decides whether eve survives contact with production. eve is a **stateful** abstraction (sessions, budgets, file artifacts, approval grants) running on a **stateless** target. Vercel Functions are per-request lambdas: a fresh process, no shared memory, a read-only filesystem outside `/tmp`. Several things that feel natural to write in an agent quietly break against that model, and we did not theorize this. We hit all three by writing the obvious code.

**The budget cap that becomes per-request.** Our production agents reach live external tools through a monid client with a spending guard — a per-process USD cap and a cost ledger that logs every paid call. The obvious implementation is a module-scoped counter:

```typescript
let _spent = 0;
const BUDGET_USD = 5;
// before each paid call:
if (_spent + price > BUDGET_USD) throw new Error("budget exceeded");
_spent += price;
```

On a long-lived server this works. On Vercel, every invocation is a new process, so `_spent` resets to zero each time — the cap silently becomes *per-request*, not global. Worse, within a single process the check-then-act sequence is a race: two parallel paid calls can each read budget room before either increments. Our review filed this as COST-001, a P1. The fix is real engineering the framework does not do for you: a concurrency queue that serializes reserve-and-reconcile so check-then-act cannot interleave, and a budget that lives in durable session state rather than a module variable.

**The artifact write that hits a read-only disk.** Two of our shared tools, `write_report` and `record_decision`, originally wrote under `process.cwd()`. On Lambda that path is `/var/task`, which is read-only, so every write threw in production while passing locally. The fix (REL-001) was a single chokepoint helper, `artifactsRoot()`, that returns `os.tmpdir()` when `VERCEL === "1"` and the working directory otherwise, one change that corrected all 50 catalog agents at once.

**The ledger that silently disappears.** The cost ledger wrote to a workspace path that does not exist on a read-only function filesystem, so deployed agents could spend real money with **no record at all** (COST-003). The default had to move to `os.tmpdir()`.

None of this is a flaw in eve. It is the inherent cost of putting a stateful agent on a stateless target, and it is exactly what eve's durable primitives exist to solve, *if you use them.* The budget guard belongs in durable session state, not a module variable. The artifact write belongs in a persistent store, not the working directory. The lesson for anyone building on eve is concrete: **treat every piece of state that must survive a turn as something the framework persists, never something the process holds.** The frameworks that win the production agent era will be the ones that make the durable path the path of least resistance. The open question for eve is whether its defaults push you there, and our honest finding is that today they do not. We found every one of these by writing the natural code first.

![A serverless function boundary where a module-scoped counter resets to zero on each invocation while a durable-state budget persists across them, two parallel calls racing the check-then-act gate, the race marked in red](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/stateful-on-stateless.jpg)

# The dual-track model: portability is possible, but you build it

The sharpest thing we learned is not in any launch post. We wanted the *same* agent code to run two ways, locally against OpenRouter with a self-hosted microVM sandbox, and on Vercel against its AI Gateway with the platform sandbox, without editing a line between them. eve allows it, but it does not hand it to you. We built a resolver:

```typescript
export function isVercelRuntime(env = process.env) { return Boolean(env.VERCEL); }

export function resolveModel(options = {}, env = process.env) {
  if (isVercelRuntime(env)) {
    const fromEnv = env.EVE_VERCEL_MODEL?.trim();
    return options.vercelModel ?? (fromEnv || "openai/gpt-5.4-mini"); // a string → AI Gateway + OIDC
  }
  const labId = options.labModel ?? env.OPENROUTER_MODEL;
  return orModel(labId);                                              // an AI-SDK LanguageModel object
}
```

The insight is in the type that comes back. **On Vercel, `model` is a plain `provider/model` string** that eve routes through Vercel's AI Gateway authenticated by **OIDC** — no API keys live on Vercel at all. **Locally, `model` is an AI-SDK `LanguageModel` object** built against OpenRouter's OpenAI-compatible endpoint. The sandbox resolves the same way: a configured self-hosted backend when an API key is present, and eve's default Vercel Sandbox on deploy.

That resolver is the whole portability argument in one file. eve *can* run anywhere — but the keyless, zero-config deploy story that makes it magical is specifically the Vercel path. Going elsewhere means rebuilding the parts Vercel gives you for free. That is not a complaint; it is the precise shape of the tradeoff, and it sets up the comparison everyone is already having.

# Connect and Passport: the parts that aren't the framework

eve did not launch alone. Vercel paired it with two products that address the questions every serious agent deployment eventually hits — *how does an agent get permission to act on a user's behalf, and how does an enterprise stay in control of what employees build?*

**Connect** is runtime OAuth. Instead of storing a provider's API keys in the agent's environment, the agent requests permission at runtime and receives a short-lived, scoped token. [@hugorcd](https://x.com/hugorcd/status/2067971734683386189) captured why this is new:

> Agents that can request OAuth permissions at runtime and wait indefinitely for approval. This wasn't really possible before. Now it's straightforward with Vercel's stack … Connect mints short-lived tokens on demand. No storing provider secrets.
>
> — [@hugorcd](https://x.com/hugorcd/status/2067971734683386189), June 19, 2026

The security model goes a step further than "don't store secrets." Vercel CTO Malte Ubl, quoted from Ship, described the isolation:

> The actual sandbox does not get the credential. It's actually in this case using OIDC tokens, but it doesn't even get the OIDC token.
>
> — Malte Ubl, via [@insecureagents](https://x.com/insecureagents/status/2068400779199684826), June 20, 2026

The sandbox where untrusted model-directed code runs never sees the credential at all. That is the right boundary: the blast radius of a prompt-injected agent is bounded by tokens it was never handed. It matters because we ran into the same threat from the other side — our own `fetch_live_json` tool is a server-side request forgery primitive if you let a model choose arbitrary URLs, so we had to harden it with an HTTPS-only check and a blocklist for private, loopback, and cloud-metadata addresses (`169.254.169.254`, `metadata.google.internal`, RFC1918). Connect is Vercel's platform-level answer to the same class of problem: the credential is the thing you most want the model never to touch.

**Passport** is the governance side. As [The Register reported](https://www.theregister.com/devops/2026/06/19/vercel-debuts-eve-open-source-agent-framework-tries-to-fix-shadow-ai-with-passport/5258726), Passport gives enterprises control over the AI-built apps their employees create — the "shadow AI" problem of a workforce spinning up agents and internal tools faster than IT can track them. eve is the framework; Passport is the admission that a framework that makes agents trivial to build also makes them trivial to build *ungoverned*, and someone has to own that.

![A credential flowing through Connect into a scoped short-lived token, with the sandbox boundary drawn so the raw secret never crosses it, the boundary marked in red](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/connect-credential-boundary.jpg)

# Connections: the file that is an external server

The directory vocabulary grew a sixth load-bearing entry that the launch demos underplay: `agent/connections/`. A connection wires the agent into a server you did *not* author — an MCP server like Linear or GitHub, or any HTTP API with an OpenAPI document — and eve handles the parts you would otherwise hand-roll: discovering the remote tools, surfacing them to the model, and brokering auth. As with everything else in eve, the filename is the identity: `agent/connections/linear.ts` registers as `"linear"`.

```typescript
// agent/connections/linear.ts

export default defineMcpClientConnection({
  url: "https://mcp.linear.app/sse",
  description: "Linear workspace: issues, projects, cycles, and comments.",
  auth: { getToken: async () => ({ token: process.env.LINEAR_API_TOKEN! }) },
  tools: { allow: ["search_issues", "get_issue"] }, // narrow the surface
  approval: once(),                                   // human-in-the-loop for the rest
});
```

The detail that matters is the same credential-isolation principle Malte Ubl described, enforced at the API: **the model never sees a connection's URL or token.** It discovers tools through a built-in `connection_search` and calls them by a qualified `connection__tool` name (`linear__search_issues`), while eve resolves and caches the token per step so it never lands in conversation history. A `defineOpenAPIConnection` does the same trick for any OpenAPI 3.x document, turning each operation into one connection tool. This is the structural answer to a problem our own SSRF-prone `fetch_live_json` tool ran into the hard way: the safest credential is one the model-directed code can never name.

![An eve connection where the model reaches an external MCP or OpenAPI server only through connection_search and qualified tool names, with a credential boundary line keeping the URL and token hidden from the model, the boundary marked in red](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/connections-model-blind.jpg)

# The breaking change that proved the warning

When we first built on eve, a tool that needed an external OAuth credential declared a top-level `auth` field. By the time we re-checked, that field was gone. **eve 0.13.0 removed top-level `auth` from `defineTool()`** and moved credential resolution to the call site — you ask for a token inline, exactly where you use it:

```typescript
// agent/tools/sync_ticket.ts — the post-0.13 inline-auth shape

const githubAuth = connect("github/myagent");
const linearAuth = connect("linear/myagent");

export default defineTool({
  description: "Sync GitHub context into Linear.",
  inputSchema: z.object({ issueId: z.string() }),
  async execute({ issueId }, ctx) {
    const { token: gh } = await ctx.getToken(githubAuth);
    const repo = await fetch("https://api.github.com/user/repos", {
      headers: { authorization: `Bearer ${gh}` },
    });
    if (repo.status === 401) ctx.requireAuth(githubAuth); // re-drive the sign-in
    const { token: lin } = await ctx.getToken(linearAuth);
    return updateLinearIssue(issueId, lin, await repo.json());
  },
});
```

The new shape is genuinely better. A single tool can now hold two credentials without contorting through one shared `auth` slot, `connect()` routes the sign-in through Vercel Connect so the raw secret stays out of the sandbox, and `ctx.requireAuth()` lets a tool re-drive an OAuth flow the moment a downstream service returns a `401`. But it is also a clean illustration of the launch-post warning that *APIs may change before GA.* That was not boilerplate. In the week after launch, eve went from **0.11 to 0.13.3** — a load-bearing tool-auth field removed, Connections reshaped, conversation compaction rewritten, the Slack channel hardened with Block Kit rendering and OIDC, and `eve init` taught to detect a coding agent on your `PATH` (Claude Code, Codex, and Cursor among them) and launch its REPL instead of always handing off to `eve dev`. The convention — agent as directory — has not budged. The surface bolted onto it is still moving under your feet, and a team that pinned an example from launch week is already on a deprecated path.

![A before-and-after of eve's tool auth: a top-level auth field on the left, inline ctx.getToken and ctx.requireAuth calls inside execute on the right, joined by a migration arrow marked in red, with a version timeline from 0.11 to 0.13.3 below](/post-images/2026-06-21-vercel-eve-agent-framework-directory-of-files/auth-field-removed.jpg)

# Fan-out: many agents, many sandboxes

One pattern we built that the launch demos skip is horizontal fan-out — running independent jobs in parallel, each in its own isolated microVM. The tool is ordinary eve, and the concurrency is ordinary `Promise.all`:

```typescript
export const swarmRunTool = defineTool({
  description: "Run independent Python jobs in parallel, each in its own isolated sandbox.",
  inputSchema: z.object({
    jobs: z.array(z.object({
      name: z.string().min(1),
      code: z.string().min(1).describe("Self-contained Python that prints its result"),
    })).min(1).max(6),
  }),
  async execute({ jobs }) {
    const results = await Promise.all(jobs.map(async (job) => {
      const sandbox = await Sandbox.create({ fromTemplate: "python-ml", timeoutSeconds: 300 });
      try {
        await sandbox.files.write("/workspace/job.py", job.code);
        const r = await sandbox.commands.run("python3 /workspace/job.py", { timeoutMs: 60000 });
        return { name: job.name, exitCode: r.exitCode, stdout: r.stdout.trim() };
      } finally { await sandbox.kill().catch(() => {}); }
    }));
    return { jobCount: jobs.length, results };
  },
});
```

A real run spun up three distinct microVMs and returned in roughly 1.2 seconds. But fan-out is also where the stateless tension bites a second time. Our durable-resume design *pauses* VMs instead of killing them so a session can reconnect — and a CI script that wiped local session state on each boot meant every run created a new VM and orphaned the old one. Within a couple of runs across 60 agents, the team's microVM quota filled. The fix was a cleanup drain, but the lesson generalizes: durable-resume semantics and ephemeral CI runs pull in opposite directions, and the framework will happily let you build a quota leak.

# eve vs Flue: deploy gravity vs portability

eve did not arrive into an empty category. Six weeks earlier, the Astro team's [Flue](/posts/2026-05-02-flue-agent-harness-framework/) had already named the agent harness as a framework target — and the two now define the poles of the TypeScript agent-framework debate.

| | **eve** (Vercel) | **Flue** (Astro team) |
|---|---|---|
| Core idea | An agent is a directory of files | The harness is the framework |
| Backer | Vercel (Guillermo Rauch) | Fred Schott / Astro |
| Deploy model | Vercel Functions + Sandbox | Node, Cloudflare, CI, Daytona, Render |
| LLM routing | AI Gateway (OIDC, no keys on Vercel) | Provider-agnostic strings |
| Maturity (June 24) | 1 week old, ~2,450 stars, 0.13.3 | 4 months old, ~6,500 stars, 1.0 Beta |
| Headline pitch | Scaffold to a running agent in a minute | Write once, deploy anywhere, any LLM |

The honest contrast is **deploy gravity versus portability**, and our dual-track resolver is the evidence. eve's killer feature is that on Vercel the deploy story vanishes: OIDC means no API keys to manage, the sandbox and workflow engine are already wired in, and you get from scaffold to a running agent faster than anywhere else. Flue's killer feature is that your agent code does not care where it runs. These are the same tradeoff viewed from two ends — eve optimizes the first hour, Flue optimizes the exit. We felt it directly: the moment we wanted eve agents to run off-Vercel, we were rebuilding the model routing and sandbox provisioning that the platform otherwise hands you. That is the portability bill, and you pay it later.

They are not mutually exclusive. shadcn's **agentcn**, launched June 20, builds on both:

> Introducing agentcn 🤖 by @shadcnlabs — Built on Eve by @vercel and @flueai — Zero config, one command setup. @shadcn/ui compatible … 10+ production-ready agent recipes.
>
> — [@alaymanguy](https://x.com/alaymanguy/status/2068382433599439282), June 20, 2026

When the most influential component-library author in React treats two competing frameworks as interchangeable backends, the signal is that the *category* has been settled before either framework has won it. The agent-as-files convention is now the consensus shape. eve and Flue are arguing over whose runtime it sits on.

# What eve means for the next twelve months

Strip the launch peg and there is still a durable claim here, which is the test for whether this is news or something more. The claim is this: **the unit of backend deployment is shifting from the service to the agent**, and the framework layer is consolidating around a filesystem convention the way the frontend did a decade ago. Vercel did not invent that idea — Flue named it first, the Claude Code skill format seeded it, the harness discourse has been building for a year. What Vercel added is distribution. When the company that defined the modern frontend deploy story tells millions of developers that an agent is just a directory you push, the convention stops being a clever framework choice and starts being the default mental model.

The risks are real, and we found them by building rather than reading. eve is a week old and shipping breaking changes at a real clip — the jump from 0.11 to 0.13.3 in that week removed a load-bearing tool-auth field — and the docs say plainly that *APIs may change before GA.* That velocity has an upside worth naming: this is not a research toy. [@VaibhavSisinty](https://x.com/VaibhavSisinty/status/2067266949390983413) caught what Vercel actually shipped:

> Vercel cooked something genuinely special here. They open-sourced the exact framework they use to run 100+ AI agents internally.
>
> — [@VaibhavSisinty](https://x.com/VaibhavSisinty/status/2067266949390983413), June 17, 2026

A framework battle-tested on a company's own production agent fleet churns precisely because it is being used hard. The deploy-gravity critique, though, is not theoretical: our own dual-track resolver is the measure of exactly how much you rebuild to leave. And the stateful-on-stateless tension is the one that will bite teams quietly. Every safety mechanism we wrote the obvious way (the budget cap, the artifact write, the cost ledger) broke against the serverless model and passed every local test before it did. The framework's defaults, not its demos, will determine whether teams ship correct agents or learn the per-request-budget lesson in an incident review.

But the direction is not in doubt. For a builder deciding where to put the next agent, the choice between eve and Flue is now a genuine architecture decision rather than a bet on whether the category exists. If your deployment lives on Vercel and you want the fastest path from idea to a durable, governed, running agent, eve is the shortest line anyone has drawn — and the durability is real, we killed a process to prove it. If portability across runtimes is the thing you cannot give up, Flue is built for exactly that, and eve will make you build it yourself. Either way, the agent-as-a-directory bet has the two heaviest names in TypeScript web infrastructure behind it now. The convention they are converging on is the one worth learning before the next ten thousand agents get built on top of it — and worth stress-testing before you trust it with a budget.

## Sources

- [Vercel — Introducing eve](https://vercel.com/blog/introducing-eve)
- [eve documentation (eve.dev)](https://eve.dev/docs/introduction)
- [eve — Connections (MCP + OpenAPI)](https://eve.dev/docs/connections)
- [eve — Auth and route protection (ctx.getToken / requireAuth)](https://eve.dev/docs/guides/auth-and-route-protection)
- [vercel/eve (GitHub)](https://github.com/vercel/eve)
- [vercel/eve — CHANGELOG (0.11 → 0.13)](https://github.com/vercel/eve/blob/main/packages/eve/CHANGELOG.md)
- [eve on npm](https://www.npmjs.com/package/eve)
- [The Register — Vercel debuts eve, tries to fix shadow AI with Passport](https://www.theregister.com/devops/2026/06/19/vercel-debuts-eve-open-source-agent-framework-tries-to-fix-shadow-ai-with-passport/5258726)
- [The New Stack — Vercel launches eve](https://thenewstack.io/vercel-launches-eve-an-open-source-framework-that-treats-agents-as-directories/)
- [Flue — the harness-first rival](https://flueframework.com)
- [@vercel — eve launch](https://x.com/vercel/status/2067180054979936413)
- [@hugorcd — runtime OAuth with Connect](https://x.com/hugorcd/status/2067971734683386189)
- [@insecureagents — Malte Ubl on credential isolation](https://x.com/insecureagents/status/2068400779199684826)
- [@pkorac — micro-services to micro-agents](https://x.com/pkorac/status/2067954274412228663)
- [@alaymanguy — agentcn on Eve and Flue](https://x.com/alaymanguy/status/2068382433599439282)
- [@VaibhavSisinty — the framework Vercel runs 100+ agents on internally](https://x.com/VaibhavSisinty/status/2067266949390983413)

---

Canonical: https://www.thedeepfeed.ai/posts/2026-06-21-vercel-eve-agent-framework-directory-of-files/
Site: https://www.thedeepfeed.ai
Full corpus: https://www.thedeepfeed.ai/llms-full.txt