Eve validates the shape. Now pick your runtime. | Dawn Blog<br>MenuMenuClose<br>Site<br>Docs<br>Blog<br>Brand<br>GitHub ↗<br>$ pnpm create dawn-ai-appCopy

Published<br>Jun 18, 2026

Reading time<br>8 min

Tags<br>philosophyagents

Author<br>Brian Love

Yesterday Vercel shipped eve, an open-source framework for building agents.

I have spent a fair amount of time with the launch material, and I want to say the obvious thing first: it looks great.

An agent in eve is a directory of files. Instructions live in instructions.md. The model lives in agent.ts. Tools, skills, subagents, channels, and schedules are files and folders you add as you grow. The launch demo even runs on Claude Opus 4.8.

If you have read anything I have written about Dawn, you can probably guess my reaction. This is not a threat. This is validation.

Why this is good news

I built Dawn on one bet: an agent application needs application structure, not just a runtime.

That bet only pays off if it is actually correct. It is easy to convince yourself that the shape in your head is the right one. It is much more convincing when an independent team, at Vercel's level, ships the same idea on the same day you would have argued for it.

Two teams, working separately, landed on agents-as-directories. When that happens, the shape is not a matter of taste anymore. It is a signal.

So I am glad eve exists. Competition is good. It moves the whole space toward conventions, and conventions are what let the rest of us stop hand-wiring the same registries over and over.

Where eve and Dawn agree

The overlap is striking. Here is the shared thesis, as plainly as I can state it:

An agent, or a route, is a folder.

Tools are files next to the thing that uses them.

Instructions and skills are markdown.

Subagents, planning, and human-in-the-loop compose through the tree, not through hidden setup code.

You can open the file tree and get a useful read on the application.

Both frameworks believe the structure should do work. You can move a folder, delete it, review it in a pull request, and answer "what can this agent do?" from disk. That is the part that matters, and eve clearly gets it.

An honest side-by-side

Where the two diverge is worth being precise about, including where eve is ahead. Here is the capability matrix as I read it today, June 2026.

CapabilityeveDawntr]:border-t [&>tr]:border-divider">Agent unitDirectory of filesRoute folder under src/app/Instructionsinstructions.mdsystemPrompt + AGENTS.md memoryToolsFiles in the agent directoryRoute-local tools/, input types inferred from TypeScriptPlanning / skillsMarkdown filesplan.md + skills//SKILL.mdSubagentsBuilt inBuilt in (subagents/ or descriptor)Human-in-the-loopBuilt-in approvalsPermission gate + Agent Protocol resumeDurable executionBuilt inSQLite checkpointer; threads survive restartSandboxed computeFirst-class adapter (Vercel Sandbox / Docker / microsandbox / just-bash)Path-jailed ctx.fs guardrail; real isolation on the roadmapChannelsSlack, Discord, GitHubNone built in; you wire your own over the HTTP APIObservabilityOpenTelemetry tracingLangSmith tracing (automatic via LangGraph)EvalsBuilt indawn eval, replay and live modes, co-located per routeRuntimeVercelLangGraph.jsDeployvercel deploy, unchanged projectdawn build → langgraph.json → LangSmithLicenseApache 2.0MIT

A table flattens nuance, so let me expand the rows that actually matter.

File conventions. Nearly the same philosophy, with small shape differences. eve uses agent.ts plus instructions.md at the root of an agent directory. Dawn uses a route folder under src/app/ with an index.ts descriptor, route-local tools/, state.ts, and markdown for memory, planning, and skills. If you are comfortable in one, you will be comfortable in the other. The one Dawn detail I would point to is that a tool's input type comes from the TypeScript function signature, not a hand-written schema, so the type is the contract the model sees.

Sandboxed compute. This is where eve leads today, and I am not going to pretend otherwise. eve ships sandboxed compute as a first-class capability, with an adapter that runs on Vercel Sandbox when deployed and on Docker, microsandbox, or just-bash locally. Dawn does not have that yet. What Dawn gives a tool today is a permission-gated, path-jailed, timeout-capped ctx.fs handle, and I am careful to call that what it is: a guardrail, not a security sandbox. That is true today. Real isolation is on the Dawn roadmap as a pluggable execution backend, so you can bring Docker, a microVM, or a hosted sandbox without coupling your agent to one of them. For now, if sandboxed compute is load-bearing for you, eve ships it and Dawn does not yet.

Channels. eve ships Slack, Discord, and GitHub as built-in surfaces. Dawn does not. Dawn is a headless runtime that exposes the Agent Protocol over HTTP, and you bring the surface: a chat UI, a Slack bot, a cron job, whatever points at the API. That is more wiring up front and more freedom after. If you want a Slack...