Vercel shipped eve around mid-June with a slogan that is easy to mock and hard to dismiss: like Next.js, for agents. The actual bet is narrower. An agent is a directory. Tools are files. The system prompt lives in `instructions.md`. Sessions are durable. The filesystem is the authoring UI.
I care about this less as a launch and more as a packaging question. We have spent a year stuffing agent behavior into chat transcripts, YAML blobs, and "platform configs" that only render inside someone's dashboard. Putting the agent in the repo — as paths a PR can diff — is either the right correction or a new kind of ceremony. Probably both, depending on the team.
What the tree is claiming
A typical eve layout looks like an opinionated Nest of folders under `agent/`:
- `agent.ts` — model and runtime knobs
- `instructions.md` — always-on system prompt
- `tools/` — typed functions the model can call
- `skills/` — procedures loaded on demand
- `channels/` — Slack, Discord, HTTP, and friends
- `schedules/` — cron-shaped autonomy
- `subagents/` — child agents as nested packages
- `sandbox/` — workspace seed and isolation choices
eve walks that tree and wires the runtime. Drop `post_chart.ts` in `tools/`, write who the agent is in Markdown, and the framework claims the plumbing. Durable execution, sandbox, approvals, and evals sit underneath so you are not starting from a naked model loop.
This is not the OpenAI Agents SDK sandbox story. That line is about owning the execution runtime and isolation for coding agents. eve's pitch is convention: the directory *is* the product surface, the way `app/` taught a generation of Next.js developers where pages go.
When directory-shaped agents help
Team ownership gets clearer. The billing agent is a folder with a CODEOWNERS entry. The support agent is another. You stop arguing about which Notion page is canonical.
Prompts become reviewable. A change to `instructions.md` shows up in the PR next to the tool that gained `network` access. That is a healthier review than "the system prompt changed in the hosted UI last Thursday."
Tools as files force a little discipline. A tool is a module with a schema and an `execute`. It can be tested. It can be grepped. It can be deleted when unused instead of lingering as a zombie capability in a mega-prompt.
Onboarding improves for the same reason `create-next-app` worked: new engineers can open the tree and guess where to put a Slack channel or a weekly schedule. Guessability is underrated infrastructure.
I would start here if the agent is long-lived, multi-tool, and owned by more than one person. Support bots, internal ops agents, scheduled report agents — the boring production kind — benefit from a reviewable layout more than from a clever graph DSL.
When it becomes ceremony
Not every agent wants a cathedral of folders. A one-off migration helper that runs in a sandbox for an afternoon does not need `channels/`, `schedules/`, and nested subagents. If your team spends more time renaming directories to please the framework than shipping tools, the convention is costing you.
Platform gravity is real. eve is open source, works with many models and MCP servers, and still lives comfortably next to Vercel's deploy, sandbox, and workflow defaults. That is fine if you are already there. It is a tax if your runtime is elsewhere and every "just works" path assumes their session API, their continuation token, their deploy story. Directory conventions travel; operational defaults stick.
There is also the false comfort of structure. A clean tree can hide a vague `instructions.md` and tools with open network. Filesystem shape is not a security review. Permissions, approval points, and budget still need an explicit contract — the boring one I want versioned before any framework.
How I would evaluate it on a real team
Steal the shape before you marry the runtime. Even if you stay on a thinner loop, organizing `instructions`, `tools`, and `skills` as files in the repo is a good habit. Put evals next to the agent the way you put tests next to a route.
If you adopt eve, treat `instructions.md` and `tools/` like production code: PR review, CODEOWNERS, no silent prompt edits in a dashboard. Use durable sessions for work that waits on humans or spans deploys. Skip the full tree for agents that are closer to a script with one tool.
Watch for lock-in in the resume and channel layers, not in the Markdown. Prompts move. Session semantics and deploy assumptions do not.
eve is right that agents needed a default project layout the way web apps did. The mistake would be treating "Next.js for agents" as a reason to stop asking who owns the permissions, what survives a crash, and whether the directory is helping the team — or just giving the framework more rooms to rearrange.