eve

You will like the first hour. One command scaffolds the project, installs what it needs and drops you into a session, which is the smoothest start on this board and the deciding trait for a weekend project, because the thing that kills a framework evaluation is spending Saturday on configuration.

What you should know before you commit is that this builds conversational agents with channels and schedules, not something that edits your code. Pick it for an internal bot with real structure. Pick Mastra when the agent has to work inside a repository.

Read the capability list rather than the description. Nothing here runs a command, drives a page, edits across files or connects to an external tool server, which means every integration beyond the shipped channels is code you write yourself against an interface three months old. A framework that young with a surface that narrow is not a foundation, it is a starting point that will move under you.

What it does right: conventional locations mean a new engineer finds the system prompt, the tools and the schedules without reading a configuration reference first.

1. Putting the system prompt, the typed tool modules, the on-demand skills and the schedules at fixed locations makes the whole configuration diffable and reviewable, which is the strongest property here and an underrated one. 2. Skills load on demand rather than all at once, which bounds context growth by design. 3. Models are named by identifiers belonging to one routing service, so the abstraction is portable and the addressing is not.

No benchmark is published for a framework this new. The observation: convention over configuration is an old idea and it has aged better than most in this category.

The commercial logic is clean and barely disguised. A permissively licensed framework costs the parent nothing, arrives with an audience already assembled, and addresses models through the parent's own routing product, so every agent built on it defaults to metered inference on the parent's invoice. Five thousand stars in a quarter is what corporate distribution buys.

There is no acquirer, because the parent is a public-market story of its own. Position: the framework is safe to use and the routing dependency is the actual product, so price the switching cost before you standardise on it.

One sentence on the demo: it answered in a chat channel on a schedule, competently. What that makes it, for us, is an internal automation platform rather than an engineering tool, and the budget lands as metered inference on a routing account rather than a seat price I can multiply. There is no identity integration, no audit surface and no policy layer, so all three become work for whoever owns the deployment. Nothing here plugs into our pipelines.

Onboarding is a day for a TypeScript engineer. Not yet, as an engineering standard.

Files on disk is the right instinct. The prompt, the tools and the schedules are all things I can edit, diff and keep in my own repository, with a permissive licence over the lot, and scaffolding is one command with no account required to start.

Then the leash appears. Models are named by a routing service's identifiers, so getting to my own hardware means routing around the framework's own abstraction, and there is no tool-server client, so nothing I already run attaches. Convention over configuration is fine when the conventions are mine. Half of these belong to a vendor.