I'll admit it — when I first saw "Vercel releases an agent framework" hit GitHub, I rolled my eyes. For me, Another one? We've got LangChain at 140K stars, AutoGen, CrewAI, every AI startup and their dog shipping an agent SDK. The space is crowded.
But then I actually looked at eve. And I spent the weekend building with it. And honestly? This thing is different in ways that matter more than you'd expect from a v0.19 release that's barely three weeks old.
Here's the thing Vercel seems to understand that most agent frameworks don't: developers don't want a framework. They want conventions.
The Filesystem-First Bet
📸 📸 Unsplash
Pop open an eve project and here's what you see:
my-agent/
└── agent/
├── agent.ts # Optional: model and runtime config
├── instructions.md # Required: the always-on system prompt
├── tools/ # Typed functions the model can call
│ └── get_weather.ts
├── skills/ # Procedures loaded on demand
│ └── plan_a_trip.md
├── channels/ # Message channels (HTTP, Slack, Discord)
│ └── slack.ts
└── schedules/ # Recurring cron jobs
└── weekly_recap.ts
That's it. That's the whole mental model. Your agent is a folder, your system prompt is a markdown file, your tools are TypeScript files, your sub-agents are more markdown files in skills/.
This is brilliantly boring design. And I mean that as the highest compliment.
LangChain makes you think about chains, runnables, callbacks, output parsers, memory stores, vector stores, and about seventeen abstractions before you can say "hello world." CrewAI wants you to define roles, tasks, crews, and processes. AutoGen gives you a programming model that's basically its own little universe.
eve says: just put files in folders. We already know how to do that.
The One-Dependency Punchline
📸 📸 Unsplash
Here's what stopped me cold: eve has exactly one runtime dependency. nitro. That's it.
Not LangChain. Not Express. Not Fastify. One dependency — Vercel's own serverless runtime — and the whole framework is built on top of it.
Let that sink in compared to the alternatives:
| Framework | Runtime Dependencies | Mental Model |
|---|---|---|
| LangChain | 15+ (lc, openai, chroma, pinecone, etc.) | Chains + Runnables + Callbacks |
| CrewAI | 8+ (langchain, openai, chromadb, etc.) | Roles + Tasks + Crews |
| AutoGen | 10+ (openai, pydantic, aiohttp, etc.) | Agent + GroupChat + Orchestration |
| eve | 1 (nitro) | Files + Conventions |
I've been building with LangChain since the early days, and I can tell you — keeping up with their abstraction changes is a part-time job. One week it's LLMChain, next week it's RunnableSequence, then it's LangGraph. The goalposts keep moving because LangChain is trying to be everything for everyone.
eve takes the opposite approach: define the smallest possible surface area, then get out of the way.
Markdown as the Agent Interface
The most unconventional choice in eve is making instructions.md the heart of your agent. Not a config file. Not a YAML manifest. A markdown file.
This seems trivial until you actually work with it. Here's what happens:
- Your system prompt lives naturally. You diff it, review it, branch it, merge it — just like any other file.
- Non-technical team members can read and edit it. It's markdown.
- You can generate it programmatically. Want to inject context from a database? Write a script that produces
instructions.md. - The agent's personality, constraints, and knowledge are right there in plain text, not buried in some config object.
I tried this with a real use case — a support agent that triages GitHub issues. In LangChain, I'd need a chain with a prompt template, an output parser, maybe a memory store, and a tool registry. In eve, I wrote a instructions.md that says "You triage GitHub issues. Here's the priority matrix. Use the tools in tools/ to read issue details and add labels." Then I wrote two TypeScript functions in tools/: one to get issue details, one to add labels.
Total time from zero to working: about an hour. Most of that was reading the docs (which, by the way, ship inside node_modules/eve/docs — a nice touch).
The Skills System — Sub-Agents Without the Ceremony
One feature that deserves more attention: skills/. These are markdown files that define sub-tasks your agent can load on demand.
Here's the use case that made it click for me. Say you're building a research agent. Your main instructions.md says "You're a research assistant." Then you drop in: Right?
-
skills/deep_dive.md— "When asked to research a topic deeply, follow this methodology..." -
skills/summarize.md— "When asked basically, use this format..." -
skills/compare.md— "When asked to compare, structure your response as..." Make sense?
Each skill is a self-contained prompt fragment that the model loads when it decides the situation calls for it. No tool registration, no function calling boilerplate. Just markdown files in a folder.
This is the same insight that makes LangChain's "few-shot prompt templates" powerful, but without the abstraction layer. The filesystem is the registry.
The Vercel Moat Question
Now for the honest critique — because any honest review needs one.
eve is deeply tied to Vercel's system. The nitro dependency means you're deploying on Vercel's runtime. The channels system (HTTP, Slack, Discord) works great out of the box, but you're committing to Vercel's infrastructure.
Want to run your agent locally as a long-running process? Possible, but not the primary design target. Want to deploy to AWS Lambda or your own Kubernetes cluster? You'll be fighting the grain.
This is the classic Vercel playbook. Same as Next.js — give you an amazing developer experience on their platform, make it just barely possible to self-host, and trust that the DX wins. For many teams, it works. For others, the lock-in is a real cost.
I think for agents specifically, this trade-off makes more sense than it did for Next.js. Agent infrastructure is genuinely complex — you need sandboxed execution, state management, observability, and channel integrations. Having a platform opinion on how those work is useful, not just vendor lock-in.
What 726,862 Downloads in 30 Days Tells Us
eve hit 726,862 NPM downloads in its first partial month. That's not just hype — that's developers actively trying it. Compare that to where LangChain was at the same point in its lifecycle, and it's clear there's real hunger for something simpler.
I think that hunger comes from a specific place: agent fatigue. We've had three years of increasingly complex agent frameworks, each promising to solve the "agent coordination problem" with more abstractions. What developers have learned is: Make sense?
- Agents are mostly prompts with function calls
- State management is the hard part, not orchestration
- Most "agent frameworks" solve problems you don't have yet
Vercel's bet with eve is that if you strip away everything except the filesystem conventions and the runtime, what's left is actually what most people need.
Disclosure: Some of the links in this article are affiliate links. If you purchase through them, I may earn a commission at no extra cost to you. I only recommend products I genuinely find useful.
The Bottom Line
Is eve ready to replace LangChain for production workloads? Not yet. It's v0.19, it's got 164 open issues, and the documentation — while well-written — is still growing. The enterprise features (RBAC, secrets management, advanced monitoring) aren't there.
But here's what I think: eve isn't competing with LangChain on features. It's competing on philosophy. And the philosophy is compelling enough that it might shift what developers expect from an agent framework.
If you're building agents today and you're tired of fighting abstractions, give eve a weekend of your time. Clone the repo, run npx eve@latest init my-agent, and see how it feels. I think you'll be surprised at how much you can build with nothing more than markdown files and a few TypeScript functions.
The framework space needed a shake-up. Vercel just delivered one.
Top comments (0)