qntx/ovo: an embeddable multi-agent runtime kernel for Rust

The gap ovo fills: an agent loop you embed, not a binary you run

Most agent tooling ships as an application. You install it, point it at an API key and a working directory, and it decides its own loop. Ovo goes the other way. The README calls it an "Embeddable multi-agent runtime kernel", and the workspace layout backs that up: the default member is crates/ovo, with ovo-runtime, ovo-agent, ovo-workflow, ovo-toolkit, ovo-state and ovo-sandbox split into separate crates. The unit of delivery is a library you link into a host program you already own.

That shapes who it is for. If you are writing a Rust service that must run model-driven turns inside your own process, with your own approval UI, your own storage decisions and your own sandbox policy, ovo supplies the turn machinery and gets out of the way. If you want an end-user agent, you are not the audience. The README never describes a shipped CLI, a server binary or a config file for running agents; the entry points it documents are constructors you call from Rust.

The project is also explicit that 0.9.x is pre-stability. The README states that breaking changes land without compatibility layers. That is a design position, not an accident, and it should decide your adoption timing more than any feature list.

Two modes in one kernel: dynamic spawn and journaled Rhai workflow

The README describes the kernel as dual-mode. One mode is dynamic spawn, where turns are driven at runtime and the host decides what happens next. The other is a journaled Rhai workflow, where the sequence of steps is written in Rhai and recorded, so a run can be replayed or resumed from the journal. Rhai appears in the workspace dependencies at version 1.25.1 with the std, sync and serde features enabled, which is consistent with scripts being embedded in the same process as the runtime.

The practical consequence is that the two modes have different failure characteristics. A dynamic turn is as reproducible as the model and the tools it calls. A journaled workflow has a durable record of what already ran, which is what you want when a long sequence touches the filesystem or the network and a restart should not redo completed steps. The README does not document a rollback procedure, and it does not describe how the journal is compacted or pruned. ovo-compaction exists as a crate in the workspace, but the README does not explain its role, so treat journal growth as something you will need to measure yourself.

Around the loop sit the supporting crates. ovo-llm covers model access, ovo-tools covers tool definitions, ovo-state covers persistence and ovo-obs covers observability. The README does not enumerate what each one exposes; the workspace Cargo.toml is the honest source for that. What the README does make clear is that these are not all compiled by default, which is the subject of the next section.

Installing ovo and running a first host turn

Ovo is published on crates.io and the README notes it was formerly published as machi. The workspace pins version 0.9.1 across every internal crate. Adding it with the default feature set is the smallest step, and the README is blunt about what that gets you: the default features are runtime and workflow, which compile the kernel and the workflow engine and link ovo-sandbox for TrustedExecution, but do not compile the toolkit.

cargo add ovo

If you want the cwd-jailed filesystem and shell tools, you need the toolkit feature. The README warns that --all-features is not full, and that full is not an OS sandbox. Feature selection here is not cosmetic; it changes which crates compile and which capabilities exist at runtime.

cargo add ovo --features toolkit

A production turn is built from a sampler, a sandbox backend and a jail directory. The README gives this shape for the host constructor, with the note that platform_sandbox() should not be treated as turnkey.

use std::sync::Arc;
use ovo::{AlwaysDeny, TurnOptions, sandboxed_host};

let host = sandboxed_host(sampler, backend, jail)?;
let opts = TurnOptions::for_host(Arc::new(AlwaysDeny)); // replace with UI gate

On Linux the OS backend is not a library call alone. The README says to ship ovo-landlock in the same directory as the host binary, set OVO_LANDLOCK_HELPER, or put it on PATH. The install command it gives is:

cargo install ovo-sandbox --features landlock --bin ovo-landlock

The README adds that cargo add ovo does not install the helper. On macOS the seatbelt feature drives /usr/bin/sandbox-exec. In both cases the backend is a value you construct and pass in, not something the kernel discovers for you.

The sandbox boundary is a contract you have to satisfy

This is where ovo asks the most of an embedder, and where a casual evaluation will go wrong. The README states that platform_sandbox() can return Failed when the sandbox is only a library dependency, either because seatbelt or landlock is missing or because the helper was not resolved. There is no NoSandbox fallback. If the backend fails, you do not silently get an unsandboxed run; you get a failure you must handle.

Approval policy is a second, independent layer. TurnOptions::for_host(gate) sets ApprovalPolicy::Destructive and takes a caller-supplied gate. TurnOptions::default() is AutoApprove, and the README marks it as not a production default, suitable for tests or an offline TurnRuntime. InProcessHost::new defaults to AlwaysDeny with a budget of 128 and does not install an OS backend at all. So the safe-looking constructor denies everything until you wire an approval UI, while the convenient constructor approves everything. Neither is a finished production posture on its own.

The README also draws a line between TrustedExecution and isolation. trusted_toolkit(jail, TrustedExecution) is described as an explicit opt-out of process isolation. That is a deliberate escape hatch, and the naming makes the trade-off legible, but it means the toolkit feature alone does not buy you a boundary. The boundary comes from the backend, and the backend comes from the host.

Where ovo is the wrong choice

If you need a sandbox that works out of the box, ovo is not it. The README says so directly: platform_sandbox() is not out-of-the-box, and there is no NoSandbox fallback. A team expecting cargo add ovo to yield a contained agent will instead find a Failed backend and a compile-time feature matrix to work through.

If you need API stability, 0.9.x is the wrong branch. The README states the GitHub non-prerelease 0.9.1 is not 1.0 and that breaking changes land without compatibility layers. Pinning is possible, but the upgrade path is your problem, not the project's.

The release history reinforces this. v0.8.0 and v0.8.1 landed on the same day in February 2026, and v0.9.1 followed in August 2026. A minor-version bump carrying breaking changes is normal here, so a version constraint in Cargo.toml is a promise the project has not made.

Finally, if your agents are not written in Rust, the embedding story does not apply. The documented integration surface is Rust constructors and feature flags. The repository topics mention a2a, mcp, x402 and zkvm, but the README does not document those integrations, so they should not be part of your decision until the docs cover them.

How ovo differs from a general-purpose agent framework

The closest comparison is a general-purpose agent framework such as LangChain-style libraries, or a Rust-native orchestration crate. Those typically give you a graph or chain abstraction above the model call, and they leave process isolation to whatever runs the code. Ovo inverts the emphasis: the kernel owns the turn, the journal and the tool execution boundary, and the sandbox backend is a first-class constructor argument rather than an afterthought.

The trade-off is real. A framework that abstracts over many providers and languages will get you to a working prototype faster, and it will not ask you to install a helper binary next to your executable or to pick between seatbelt and landlock. Ovo asks for that because it treats the OS boundary as part of the runtime contract. If your agent never executes untrusted code, that contract is cost without benefit, and a lighter orchestration layer is the better fit. If it does execute code, the contract is the point.

The second difference is the journal. A workflow written in Rhai and recorded is a different proposition from a chain that re-runs from the top on failure. The README does not promise exactly-once semantics, and it does not document replay tooling, so the journal is a capability to verify rather than a guarantee to rely on.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-09, which is within the last two weeks of the project's public history. Releases are infrequent and uneven: v0.8.0 and v0.8.1 both landed on 2026-02-24, and v0.9.1 arrived on 2026-08-21. That cadence suggests bursts of work rather than a steady release train, and the README's pre-stability warning means each burst can move the API.

Upgrade cost is therefore dominated by API churn, not by dependency drift. The workspace pins edition 2024 and a rust-toolchain.toml exists at the repository root, so the compiler version is part of the contract. The Makefile shows the project's own gates: cargo check --workspace --all-features, cargo +nightly clippy with -D warnings, cargo deny check and cargo +nightly fmt. Running the same commands against your fork is the cheapest way to see what a version bump breaks, since --all-features is what the project itself compiles.

Licensing is dual: Apache-2.0 or MIT, at your option, with contributions dual-licensed under the same terms unless stated otherwise. The crates.io badge in the README also shows MIT/Apache-2.0, while the repository metadata field lists Apache-2.0. Both licence files, LICENSE-APACHE and LICENSE-MIT, are present at the root. If your organisation treats MIT and Apache-2.0 differently, for example around patent grants, confirm which one you are relying on before shipping. That is a question for your own counsel, not something the README answers.

Editorial conclusion

Embed ovo if you are building a Rust host that needs an agent turn loop plus a real OS sandbox boundary and you can absorb pre-1.0 breakage. Do not adopt it if you want a runnable agent binary, a stable API, or a sandbox that works straight after cargo add. Before wiring anything, check that platform_sandbox() resolves on your target, that ovo-landlock is installed on Linux and OVO_LANDLOCK_HELPER is set, and that your approval gate replaces AlwaysDeny rather than sitting behind it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. qntx/ovo on GitHub
4. README
5. Releases