Most of what we write about Everruns describes the server: durable execution, persistent state, multi-day runs that survive crashes. That is the headline workload, and it is the reason the platform exists.

But the runtime that powers all of that is a library first. The server is one embedder. There is nothing stopping you from being another.

[`everruns-runtime`](https://crates.io/crates/everruns-runtime) is a Rust crate. You can pull it into a Cargo project, register the capabilities and tools you want, point it at a model provider, and run an agent loop entirely in-process. No server, no network hop, no separate deployment. The same code that drives long-running cloud workflows also drives a single binary on your laptop.

We have been using this pattern internally to prototype tools. To make it concrete, we shipped a worked example: a terminal coding agent built on the runtime as a standalone Cargo project, the same way any external embedder would consume it.

The code lives at [`everruns/everruns/examples/coding-cli`](https://github.com/everruns/everruns/tree/main/examples/coding-cli).

## What the example is

The coding CLI is a minimal agent that runs in your terminal. You give it a prompt, it reads and edits files in the current workspace, runs shell commands when it needs to, searches the web, and asks for approval before doing anything destructive. It logs every event to a JSONL file, so closing the terminal and reopening it later resumes the same session.

None of that is novel as a product. There are many coding agents in the wild. The interesting part is how little code it takes to assemble one when the runtime does the heavy lifting.

The whole project is a few hundred lines of Rust on top of the runtime crate. The Cargo manifest depends on `everruns-runtime` like any third-party library. There is no fork, no internal API, no hidden surface. What is published is what is used.

![Terminal screenshot of the Everruns coding CLI: a chat transcript shows the agent picking up a workspace, listing the registered tools, and responding to a prompt about dependency status.](./ercode.png)

## What embedding actually looks like

The setup chain lives in `src/runtime.rs` and follows a single shape: register a filesystem, register capabilities, pick a driver, run the loop.

![Embedding architecture: your application sits on top of the everruns-runtime crate, which provides four subsystems — capabilities, filesystem stack with policy decorators, model driver, and append-only event log — connecting out to shell, workspace files, the model provider, and a local JSONL session file.](/blog/embedding-the-runtime-architecture.svg)

**Filesystem stack.** The agent registers a `SessionFileSystemFactory` that builds a `RealDiskFileStore` rooted at the workspace, then wraps it with two policy decorators from the runtime: `WriteBlocklistFileStore`, which refuses to touch `.git/`, `node_modules/`, and similar directories, and `ApprovalGatingFileStore`, which routes destructive writes through an approval gate before they hit disk. Both decorators are part of `everruns-runtime`. The example does not reimplement them; it composes them.

**Capabilities.** The agent enables a handful of runtime-provided [capabilities](https://docs.everruns.com/features/capabilities/) — filesystem tools, instruction reloading from `AGENTS.md`, tool output persistence, skills discovery, prompt caching, loop detection, DuckDuckGo search, web fetching — and adds one of its own: a `CodingBashCapability` that exposes a real shell against the workspace, gated by the same approval mechanism as the filesystem decorator. The approval gate is shared, so a single user decision covers both surfaces.

**Driver selection.** The runtime supports multiple model providers behind a common interface. The example reads environment variables and picks Anthropic, OpenAI, or the offline `llmsim` driver for local development. Swapping providers is a configuration change, not a code change.

**Session persistence.** Every tool call, every model response, every state transition is appended to a JSONL log. On resume, the runtime replays the log and reconstructs state. This is the same durability primitive the server uses, working unchanged in a process that lives and dies with a terminal window.

That is the whole shape. Filesystem, capabilities, driver, loop. Everything else — the TUI, the approval prompts, the keybindings — is application code that the runtime does not care about.

## Why embed at all

Server-mode Everruns is the right answer when an agent needs to outlive the process that started it: a research task that runs for two days, a backend workflow that has to survive a Kubernetes rollout, a fleet of long-running jobs sharing state. Durability across machines is exactly the problem the server is built for.

In-process embedding answers a different question. It is what you reach for when you want the same runtime guarantees — structured tool calls, capability composition, event-sourced state, model abstraction — without standing up infrastructure to get them.

A few cases where this matters:

- **Local developer tools.** Coding agents, repo assistants, build helpers, lint fixers. These run on a developer's machine, against a single workspace, with credentials that already live in the shell. A server would be infrastructure overhead for no benefit.
- **Private harnesses.** Internal teams that want a coding or analysis agent shaped exactly the way they work — their tools, their approval policies, their model choice — and do not want to wait for someone else's product roadmap to get there.
- **Air-gapped or regulated environments.** Anywhere the data cannot leave the machine, and "call out to a hosted service" is not on the table. The runtime is a library; the library runs wherever Rust runs.
- **Edge of a larger system.** A long-running workflow on the server can hand off a short, interactive task to a local agent that uses the same runtime, the same capability contracts, and the same event format. The pieces compose.

The point is not that embedding replaces the server. It is that the same runtime fits both shapes, and the boundary between "local tool" and "platform" gets thinner when the layer underneath is the same.

## What this means for what you build

If you have ever wanted a coding agent that does exactly what you want, with the safety policies you trust, against the model you pay for, on a machine you control — embedding `everruns-runtime` is the short path to that. The coding CLI example is not a product. It is a starting point you can fork and shape.

The capability surface is composable. The filesystem decorators are composable. The driver layer is pluggable. The event log is the same one the server uses, which means an agent you build today on your laptop can graduate to a durable workflow on the server tomorrow without rewriting its tools or its prompts.

The runtime is MIT-licensed. The example is in the same repository as the runtime itself, so it tracks the public API exactly. Clone it, run it, change it.

- Coding CLI example: [`everruns/everruns/examples/coding-cli`](https://github.com/everruns/everruns/tree/main/examples/coding-cli)
- Runtime crate on crates.io: [`everruns-runtime`](https://crates.io/crates/everruns-runtime)
- Runtime source and the rest of the platform: [`github.com/everruns/everruns`](https://github.com/everruns/everruns)
- Documentation, including the [capabilities reference](https://docs.everruns.com/features/capabilities/): [`docs.everruns.com`](https://docs.everruns.com/)

If you build something on top of the runtime — local, private, or otherwise — we would like to hear about it. [contact@everruns.com](mailto:contact@everruns.com).