Vercel Wants to Be 'Next.js for Agents' With a Framework Called eve. Before You Adopt Another Agent Framework, Count How Many You've Already Abandoned.
Vercel launched an open-source agent framework called eve that treats every agent as a directory of files and bundles the infrastructure to run it in production. The pitch, straight from Vercel, is "Next.js for agents," and it ships as part of a broader Agent Stack. The abstraction is genuinely clean: agents as directories is a nice mental model, and Vercel is very good at making the path from idea to deployed thing short.
It's also the latest entry in a list that's gotten long. If you've been building with agents for the last year and a half, you've probably already tried two or three frameworks that promised to be the one, and at least one of them is now dead weight in a repo you don't open anymore. Before eve becomes the fourth, it's worth being honest about what adopting an agent framework actually costs a team of one.
What eve is, and why it's attractive
eve's core idea is that an agent is a directory: files that describe its tools, its instructions, its wiring, deployable as a unit. Around that, Vercel provides the runtime and the production infrastructure: the part that's normally tedious to stand up yourself. For someone already living inside Vercel and Next.js, the gravity is obvious. The deploy story is the one you already know, the primitives line up with how you build everything else, and you can go from "I want an agent" to "it's running" without leaving the ecosystem.
That's a real value proposition, and I don't want to wave it away. The reason "Next.js for agents" lands as a pitch is that Next.js genuinely did make a category of work faster for a lot of people. If eve does the same for agents and you're a Vercel shop, the weeks it saves are not imaginary.
The cost nobody prices in
Here's what adopting an agent framework actually buys you, beyond the speed. You buy into its mental model: its idea of what an agent is, how state flows, how tools get registered, where the boundaries sit. And you usually buy a degree of hosting gravity, because the framework that makes deployment magical tends to make it magical on the vendor's platform specifically.
Both of those are fine right up until the framework gets deprecated, out-shipped by the next one, or quietly stops getting attention because the company's priorities moved. Then you're holding a migration. And migrating off an agent framework is worse than migrating a web framework, because the framework didn't just structure your routes: it structured your agent's whole control flow, the part that's hardest to port. The convenience you bought on day one is the tendon you have to cut on the day you leave.
I've lived the smaller version of this with web frameworks for a decade, and the agent-framework version is moving faster. The release cadence in this space is frantic. A framework that's the obvious choice today can be yesterday's choice in two quarters, and the half-life of "the agent framework everyone's using" is short enough that betting your core architecture on any single one is a bet against the base rate.
Keep your core thin
The move that's served me through every framework cycle is the same one here: keep the load-bearing part of your system thin and yours. An agent, stripped to its bones, is a loop: a model call, a set of tools it can invoke, and somewhere to put the work that needs to run in the background. That loop is maybe a few hundred lines you fully understand and fully own. It depends on nothing that can be deprecated out from under you, because you wrote it.
Then treat frameworks as borrowable, not foundational. eve has good ideas: agents-as-directories is worth stealing as a way to organize your own code whether or not you import the framework. Take the idea, take a utility or two if they're genuinely lifting weight, and keep them at arm's length from the core loop that defines your product. If eve turns out to be the durable winner, you've lost nothing by being able to adopt it deeper later. If it doesn't, your business didn't have its spine welded to a framework that stopped shipping.
Concretely, for a solo dev: write the orchestration loop yourself, wrap the model and tool calls behind your own thin interface so you can swap providers, and use a plain queue for background work rather than a framework-specific abstraction. It's slightly more code up front. It's dramatically less code the day you need to move.
The honest take
If you're already all-in on Vercel and Next.js and you have no intention of leaving, the calculus flips, and I'd be lying if I told you to hand-roll everything on principle. eve's gravity is a feature when you were never going to fight it: the integration with the rest of your stack might genuinely save you weeks, and "lock-in to the platform I already chose forever" is a cost you already paid. For that operator, adopt it and enjoy the speed.
For everyone else, the pattern is the thing to internalize, not eve specifically. Agent-framework churn is the new JavaScript-framework churn, except the migration tax is higher because the framework owns your control flow, not just your file structure. So count the frameworks you've already abandoned before you adopt the next one. Keep your core thin enough that the answer to "what happens when this one dies" is "I delete a wrapper," not "I rewrite my product." Borrow eve's best ideas. Don't marry it.
Author
Lukas
@lukcombinator