eve keeps agent capabilities in a fixed tree with one required file, and ships its documentation inside the npm package

The repository description says the project's name twice

The one-line description recorded for this repository is:

The Framework for Building Agents, followed by the project's name, followed by the project's name again, followed by the rest of the sentence.

So the summary a reader sees in a search result, in a package listing or in their own tool's repository picker begins with a duplicated word. It is the first thing anybody meets.

The package manifest does not have it. The root manifest describes itself as a monorepo for the project, calling it a filesystem-first framework for durable backend agents on the vendor's platform. So the clean sentence and the broken one live in the two places a reader is most likely to look, and only the clean one is in the file you would edit to fix the other.

Everything else about the project's presentation is unusually disciplined. The header is a centred logo with a dark-mode variant, four badge links, and a one-line description that says the thing is filesystem-first and explains the phrase in the next sentence: core agent capabilities live in conventional locations so projects are easier to inspect, extend and operate.

That sentence is the thesis, and everything else in the README is an illustration of it.

The scaffold installs from a moving tag and writes a model identifier into your project

The quick start is one command, and three things about it are worth naming.

npx eve@latest init my-agent

First, the tag. The command installs from a moving tag rather than a version, so a project scaffolded today and one scaffolded next month get different code with no record of what either was. For an initialiser that is a common and defensible choice, and for a project that will live for months it means the first commit of your repository does not identify your starting point.

Second, the scope. The command creates the directory, installs the dependencies, initialises Git, and starts an interactive terminal interface. So one command writes files, runs an install, creates a repository and blocks on a user interface.

Third, what it writes. The generated agent is given a specific model identifier with a high reasoning setting. The README then documents the override, and its interaction is the part that is easy to get wrong: passing a model without a reasoning flag uses the provider's default reasoning instead, and passing the reasoning flag sets it explicitly. So there are two independent flags with a three-way outcome, and the default is neither of the two values a reader would guess.

Adding the framework to an existing project is the same command with a path, which is the least surprising part of the section.

The package ships its documentation so a coding agent can read it locally

There is a note in the quick start that says more about the project's design than anything else in the file.

It says the package includes its full documentation, so coding agents can read it locally from a path inside the installed package's documentation directory.

That is a deliberate decision, and an unusual one. The documentation is not only on a website; it is inside the tarball that the package manager puts on disk. An agent working in a project that depends on the framework can read the manual the way it would read the project's own source, with no network call and no documentation site in the loop.

It also means that a reader has two copies of the documentation at different versions: the site they browse and the one their editor can see. Those can disagree, and nothing in the file says which is authoritative or how they are kept in step.

The repository backs the same instinct elsewhere. Alongside the packages and the applications there is a skills directory at the root, an agent instruction file, a copy for a specific assistant product, a directory for another, an editor configuration directory, a research directory, and a script that installs Git hooks on prepare.

So the project is built on the assumption that something is reading the repository, and it has arranged for that reader to find what it needs.

One required file, five optional directories, and a beta notice at the bottom

The filesystem is the authoring interface, and the tree in the README is annotated with what is required and what is not.

my-agent/
└── agent/
    ├── agent.ts            # Optional: model and runtime config
    ├── instructions.md     # Required: the always-on system prompt
    ├── tools/              # Optional: typed functions the model can call
    ├── skills/             # Optional: procedures loaded on demand
    ├── channels/           # Optional: message channels (HTTP, Slack, Discord)
    └── schedules/          # Optional: recurring cron jobs

Exactly one of the six is required, and it is a Markdown file holding the system prompt. Everything else is a directory or a config file, and each has a distinct load semantics: tools are typed functions the model can call, skills are procedures loaded on demand, channels are message transports, and schedules are recurring jobs.

That the prompt is the only mandatory artefact is the design in one line. There is no manifest, no registry file and no serialisation format; a project is a prompt plus whatever directories it needs, and a directory the author did not create is simply a feature that is off.

The most recent releases are release candidates: [email protected] on 2026-10-31 and [email protected] on 2026-11-02.

Four guard scripts and three documentation checkers stand in front of a merge

The root manifest has more verification commands than a project of this size usually carries, and two of them are called guards.

There is a script that guards test fixtures and a script that guards invariants, each a single node script with a matching file. There is a script that checks template compatibility. And there are three separate documentation checkers, run as one command, for documentation itself, for code snippets inside documentation, and for the component markup in it. Three checkers for one output directory means the project has found three distinct ways its documentation breaks, which is a reasonable thing to have discovered and a slightly surprising thing to read about.

The dependency surface gets the same treatment. A command lints for version mismatches across the workspace, another fixes mismatches and reformats the manifests, and a configuration file at the root tunes both. So a monorepo whose packages have to agree on versions is checked in three places: the tool, the config and the lockfile.

Formatting and linting use a third-party tool each, with a configuration file apiece, and the lint script runs with a fix flag rather than reporting. That means a lint failure is a rewritten file, not a message, which is worth knowing about before running it.

The build commands are wired to a task runner, turbo.

The integration suite deliberately runs in two phases

The test script is a chain that starts with the unit tests.

The release target is similarly careful. It builds, then runs scripts/assert-changeset-publish-packages.mjs, and only then runs scripts/publish-packages.mjs. So a problem the assertion catches stops the release before anything is published.

The root build only covers packages, and the release step writes one more file than you would expect

Two build details describe the monorepo's shape better than its directory listing does.

First, the root build command filters to the packages directory and nothing else. So the applications in this repository, whatever they are, are not built by the root build script. They are built by something else, or by their own scripts, and the one command a new contributor reaches for does not produce them.

The rest of the tree explains the scope. There are package and application directories, a documentation directory, a research directory, a skills directory, an end-to-end directory, and a scripts directory. Configuration for the hosting provider appears twice at the root, once as an ignore file and once as a file naming who may approve a deployment. A runtime version is pinned in its own file, and a copy exists for an editor.

Governance is in the same shape as the tooling: a developer certificate of origin, a codeowners file, a code of conduct, a security policy, a notice file and a licence, alongside an agent instruction file and a copy for a specific assistant product.

Editorial conclusion

eve fits a team that wants an agent's prompt, tools, procedures, channels and schedules to be ordinary files in a repository rather than configuration inside a runtime. Three things to know before you build on it. The framework's newest releases are release candidates such as [email protected]. The scaffolding command installs from a moving tag and writes a specific model identifier into your project, so two projects scaffolded a week apart are not the same project. And the runtime's own guard scripts check fixtures and invariants, which is a good sign about the framework and a sign that the framework is opinionated enough to need them.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes