Raven (EverMind-AI) review: a terminal-first agent harness with local tracing and EverOS memory

What Raven solves, and who it is actually for

Most agent CLIs treat each session as disposable. You paste context, the model answers, the process exits, and nothing carries forward. Raven is built around the opposite assumption: that the useful part of an agent is what it remembers and what it can prove it did.

The README describes the current public release as an open-source, self-improving Agent Harness that brings terminal-first execution, local tracing, long-term memory, skills, evaluation and reusable workflows into one system for long-running AI work. That list is the product definition. The intended user is a developer who already has an LLM provider key and wants an agent that runs on their own machine, keeps state between sessions, and can be inspected after the fact rather than trusted blindly.

Two boundaries matter before you install anything. First, the project labels itself pre-alpha and warns that interfaces and configuration may change quickly. Second, the README is explicit that The Harness of Harnesses, the multi-agent network described at the top of the page, is a next-version direction and not a capability of the current public release. The benchmark table on that page comes from an internal research prototype. If you are evaluating Raven for a production workflow, treat those numbers as a statement about where the project is heading, not about the artifact you download today.

How Raven is put together: CLI, gateway, local trace store

The repository layout shows a Python package under raven/ plus separate top-level directories for evolver/, agents/, bridge/, ui-tui/, ui-web/ and rpc-schema/. The Python side is a Typer application: pyproject.toml pins typer, litellm, pydantic and everos[multimodal]==1.2.3 as direct dependencies, which tells you the shape of the runtime. litellm handles provider calls, so the model you pick during onboarding is routed through a common interface rather than a provider-specific SDK.

Tracing is the part worth understanding before you decide whether you like the design. According to the README, each session.turn becomes a trace tree containing the work beneath it: LLM calls with model, token usage, cost, latency and errors; tool inputs and outputs; subagent runs with parent-child relationships; skill reads and injections; memory recall, storage, extraction and consolidation; and large prompts and results stored out of line as artifacts. Spans are written locally to ~/.raven/traces/logs/audit-spans.log. Nothing in that description involves a hosted trace service.

The Dockerfile explains a constraint that shapes deployment. The engine binds its HTTP surface to 127.0.0.1, so a reverse proxy in a second container has no address to reach it on. The image therefore ships nginx beside the engine in the same network namespace rather than as a separate service. The build file says splitting them would need a bind address the engine does not offer yet. That is an honest note in a build file, and it also tells you the gateway is not designed to be exposed directly.

Installing Raven and running a first session

The README gives a one-line installer for Linux, macOS and WSL2. It pipes a remote script into bash, so read it first if your environment requires that.

curl -fsSL https://raven.evermind.ai/install.sh | bash

Native Windows PowerShell uses a separate script. The README notes that PowerShell 5.1 may reject the redirect and gives a direct raw URL as the fallback.

irm https://raven.evermind.ai/install.ps1 | iex

After installation there is no separate configuration step to memorise. Running the binary with no arguments starts onboarding and then opens the TUI in the same session.

raven

The wizard is bilingual and covers six areas: LLM provider and model, sandbox or execution location, chat channels, EverOS long-term memory, Deep Research, and cold-start import from other AI tools. Provider setup includes an in-step connectivity check, and the optional steps can be skipped and configured later. The README states the wizard writes to ~/.raven/config.json without requiring manual edits. To reconfigure later, run raven onboard explicitly.

If setup is incomplete, the documented recovery command is raven doctor.

raven doctor

Deep Research is a separate switch. The README shows enabling it and reading back the current configuration.

raven deep-research enable
raven deep-research get

Once configured, Raven can invoke a deep_research tool when a task needs more than a quick lookup. The README says interactive surfaces ask before a paid, minute-scale run whether to use Deep Research or regular search. Completed results are archived under <workspace>/deep_research/.

Tracing, and the environment variables that control it

Tracing is on by default and the README states it is designed never to interrupt Raven's control flow. You open the local dashboard with one command.

raven tracing

Two environment variables change its behaviour. RAVEN_TRACING_DIR moves the state directory away from the default. RAVEN_TRACING=0 disables recording entirely. If you are running Raven on a machine with a small disk or you do not want tool inputs and outputs persisted, the second variable is the documented off switch, and it is worth setting deliberately rather than discovering the log later.

The span schema follows what the README calls a small, versioned semantic contract, documented in docs/TRACING_STANDARD_API.md, which covers span names, attributes, artifact behaviour and extension rules. That document is the place to look if you want to build your own consumer over the span log rather than use the bundled dashboard.

One consequence of the design deserves stating plainly. Because large prompts and results are stored as out-of-line artifacts, the audit log alone is not a complete record; you need the artifact directory alongside it. Anyone archiving traces for compliance should archive both, and the README does not describe a retention or pruning policy for either.

Where Raven is the wrong tool

The pre-alpha label is not boilerplate. Interfaces and configuration may change quickly, per the README, and the release cadence shows it: v0.1.11, v0.1.12 and v0.1.13 landed within roughly two weeks of each other. If you need a frozen CLI contract that a CI pipeline depends on, this is the wrong moment to build on Raven.

The Windows story is partial. The README offers a native PowerShell installer, but the primary install instructions are scoped to Linux, macOS or WSL2, and the documented fallback exists because PowerShell 5.1 may reject the redirect. If your team standardises on Windows without WSL2, you are on the less-travelled path.

The research results need care too. The efficiency, self-evolution and proactivity figures on the README page come from an internal research prototype evaluated across 22 Agent benchmark tasks. The README itself says these results do not mean the current public release already supports the Harness of Harnesses network, and that model, task set and evaluation protocol all affect outcomes. There is no published evaluation of the shipped v0.1.13 release in the repository documentation.

Finally, the gateway has a deployment boundary. Because the engine binds to 127.0.0.1, the shipped Docker image runs nginx in the same network namespace instead of as a separate service. If you wanted to place Raven behind your own ingress in a second container, the Dockerfile says the engine does not yet offer the bind address that would require.

How Raven differs from a general-purpose agent framework

The closest comparison is a general-purpose agent framework such as LangChain or a graph-based orchestrator like LangGraph. Those give you libraries and abstractions and leave the runtime, the memory store and the observability stack to you. Raven ships the opposite: an opinionated binary with a TUI, a gateway, a bundled memory layer through EverOS, and a trace store on disk. The difference is not features, it is who owns the wiring.

That trade is visible in the dependency list. everos[multimodal]==1.2.3 is pinned exactly, not ranged, and pyproject.toml carries a comment explaining that tiktoken is pinned directly so the EverOS extractor keeps working if upstream litellm ever drops it. A framework lets you swap the memory backend; Raven fixes it and pins it. For someone who wants memory that works out of the box, that is the point. For someone who already has a vector store and an extraction pipeline, it is a constraint.

The second difference is the trace model. Framework observability usually means exporting spans to a hosted service or a self-hosted collector. Raven writes spans to a local log and serves a dashboard from the same binary. If your organisation has a policy against sending prompt content to third-party trace backends, that default is the reason to look at Raven rather than a framework with a hosted tracing integration.

Licence, upgrades and the cost of staying current

Raven is Apache-2.0. The pyproject.toml declares the licence and lists LICENSE, LICENSES/*.txt and NOTICES.md as licence files, and the repository also carries a NOTICES.md at the top level. Apache-2.0 includes a patent grant and requires attribution and notice retention when you redistribute. If you plan to ship Raven inside a product, read NOTICES.md and the LICENSES/ directory yourself rather than relying on a summary; this is not legal advice.

Upgrades are manual by design. The README states Raven does not update automatically and gives two commands: raven upgrade --check to see what is available, and raven upgrade to apply it. The README also states that upgrades preserve configuration, sessions and memory. That claim is the one to verify against your own setup before you rely on it, because the pre-alpha warning about changing interfaces sits right next to it.

The ongoing cost is mostly attention. A project releasing three patch versions in two weeks will occasionally change a config key or a CLI surface, and the README does not document a rollback path for a failed upgrade. If you pin Raven for a team, pin the version and keep the config under version control so a change to ~/.raven/config.json is visible in a diff.

Editorial conclusion

Adopt Raven if you want a terminal-first agent whose memory, skills and traces all stay on your own machine, and you can live with a pre-alpha that changes interfaces quickly. Skip it if you need a stable API, a supported Windows path outside WSL2, or benchmark numbers that describe the shipped release rather than an internal prototype. Before committing, run raven doctor after onboarding, check ~/.raven/config.json to confirm which provider and sandbox were written, and open raven tracing once to see whether the span log at ~/.raven/traces/logs/audit-spans.log is actually being written on your machine.

Frequently asked questions

Official sources

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