exo: a Rust agent harness that rewrites its own prompts, tools and policies at runtime

The problem exo targets: agents that can only edit their memory

Most agent frameworks let the model write to a memory store or generate a new skill file. The README draws that line explicitly, saying that while most agents can do some form of self improvement, such as updating memory or creating skills, exo is fully recursive in that it can clone or operate on any aspect of itself, from prompts, to memory, tooling, or even basic harness policy itself. The stated problem is not that agents lack tools. It is that the parts of the system deciding how tools get called, what the system prompt says, and what the harness permits are fixed by the developer at build time, so a smarter model arriving later inherits a ceiling it cannot raise. exo is aimed at people building long-lived agents who accept that the harness should be a mutable artifact rather than a frozen dependency. The README frames the audience in terms of two use cases: building the agent you like with what it calls maximal Bitter Lesson alignment, and letting models solve complex problems by iterating on system level properties. It cites agents that learned to play games, cost-optimize themselves, and build complex systems, and states that in each case the agents had to modify themselves heavily beyond memory. Treat those as the maintainers' claims about their own work, not as independently reproduced results.

What recursion actually covers, and the one thing it does not

The scope of self-modification is the whole point, so it is worth being precise about it. According to the README, the agent has full visibility into both its code and its runtime logs, and that visibility is what allows it to improve every aspect of itself, clone itself, and manage a lineage of clones. The editable surface named in the text is prompts, memory, tooling, and harness policy. Cloning is described as a first-class operation, and the README goes further, saying exo can manage a lineage of clones, which implies more than one agent instance with some shared ancestry. The single hard boundary is the event log. The README states that the only thing it cannot muck with is an event log which provides a canonical history of what it's tried, and gives the reason: to prevent getting stuck in recursive loops. That is a narrow but load-bearing constraint. An agent that can rewrite its own policy and prompts has no stable ground to compare against unless something outside its write path records attempts. Whether that boundary holds in practice is the first thing a prospective user should check, because the README asserts the property without describing the enforcement mechanism.

Getting it running: setup.sh, exo.sh and the template flag

Installation is a two-command sequence from the README. The first downloads and runs the setup script: curl -fsSL https://raw.githubusercontent.com/exoharness/exo/main/setup.sh -o setup.sh followed by bash setup.sh. The README notes that exo requires git and Docker, that the setup script offers to install them if missing, and that it installs pinned node, pnpm, and rust toolchains automatically via mise. The script then builds exo, which the README warns may take a few minutes, prompts for an API key and names, and prints the command to start the agent. An OpenAI or OpenRouter API key is required for agent use. Day-to-day control runs through ./exo.sh in the repo root. With no arguments it starts the full stack (Docker sandbox, ExoChat) and opens the CLI chat interface. The documented subcommands are list, to list agents and conversations; stop-all, to stop the scheduler and adapter runners while preserving state; fresh, to rebuild and delete all agents and conversations; setup-profile, to update your local profile; and --help. The README gives a clear rule for choosing between them: use stop-all to shut exo down, plain ./exo.sh to bring it back with all state intact, and fresh when you want to throw everything away. A --template flag selects the environment. The default is canonical, described as a Docker sandbox with the repo mounted at /workspace/exo and ExoChat for remote access. dev sets up IRC and Discord instead of ExoChat. minimal is a bare REPL with no Docker defaults or adapter setup. That last option matters: the sandbox is the containment layer, so minimal removes it.

Event stream and logs: the visibility surface you debug against

Because the agent rewrites itself, the observable record of what it did is the main tool you have. The README documents a durable event stream followed from a separate terminal with pnpm events:tail. It shows recent messages, tool calls and results, and turn boundaries, then continues following new events. It defaults to the exo-agent agent and dev conversation, and accepts different slugs plus a history depth: pnpm events:tail exo-agent dev --history 50 for more backfill, or --history 0 for new events only. Ctrl-C stops following. Scheduler and adapter services log separately on the host, at .exo/exo-scheduler.log for scheduled task execution and .exo/exo-adapters.log for adapter startup, delivery, and failures, both followed with tail -F. The split is sensible for a system with background work: the event stream is the agent's own narrative, while the two log files cover the machinery that fires tasks and delivers messages to external chat services. The README does not document an event schema, retention policy, or rotation for these files, so plan to inspect the format yourself before you build any tooling on top of it. The turn boundary markers in the tail output are the most useful part for auditing self-edits, since they let you bracket a change to prompts or policy between two points in the stream.

A concrete end-to-end check, and what it exercises

The README offers a specific prompt as a good end-to-end test: install python3 and curl in the sandbox using apt-get without sudo, then schedule a task to run every minute that grabs news headlines from the BBC RSS feed, printing only headlines not printed before, and printing them in the chat. That single prompt touches four subsystems at once. It exercises the sandbox's package installation path, the task scheduler's recurring execution, the agent's ability to hold state across runs so it can suppress duplicate headlines, and the delivery path back to the interface you are watching. If any of those are broken you will find out quickly, which is why it is a better first run than asking the agent to refactor something. It also gives you a reason to open a second terminal and run pnpm events:tail while the scheduled task fires, so you can see the tool calls and turn boundaries for a recurring job rather than a single interactive exchange. The README does not state what the expected output looks like or how long the first scheduled run takes to appear, so treat the absence of headlines in the first minute as inconclusive rather than as a failure.

Where the design is thin: sandbox escape, event-log enforcement, and release discipline

The README is explicit that the event log is the only thing the agent cannot modify, and it is equally explicit that everything else is fair game, including harness policy. That is a large surface with a single guardrail, and the README does not describe how the event log is protected, whether it is append-only at the filesystem level, written by a separate process, or held outside the sandbox. If you are evaluating exo for anything where an unexpected self-edit has consequences, that enforcement detail is the thing to read the source for, because the architectural claim is stated without its mechanism. The sandbox is the second boundary, and it is optional. The canonical template runs a Docker sandbox with the repo mounted at /workspace/exo, while the minimal template has no Docker defaults. Mounting the repository into the sandbox means the agent has access to its own source tree by design, which is the feature, but it also means the containment question is about what else the container can reach rather than about whether the code is visible. Third, there are no releases in the supplied material, and the repository is not archived. With no versioned releases to pin, you are tracking main. For a project whose selling point is that the agent edits itself, an unpinned dependency is a real operational cost, not a formality.

How exo differs from a conventional tool-using agent framework

The README positions exo against harnesses it names as OpenClaw, Pi and Hermes, describing it as a complete AI agent harness supporting tools, tasks and integrations similar to those, with the difference being full visibility into code and runtime logs. That comparison is worth taking at face value rather than as a ranking, because the architectures differ in kind, not degree. A conventional framework such as LangChain or the OpenAI Agents SDK ships a library whose control flow lives in your repository: you define the tools, you write the system prompt, you decide when memory is written, and upgrading the framework means changing a version in your manifest. exo inverts that. The prompts, memory, tooling and harness policy are inside the agent's own editable surface, so the artifact that changes between runs is the harness, not just the conversation state. The practical consequence is that reproducing a run requires capturing the harness configuration at that moment, which is what the event log is for. The cost is that you cannot reason about exo's behaviour from its source alone the way you can with a fixed library, because the running system may no longer match the checkout. That trade is the entire product. If you want deterministic behaviour from a pinned dependency, a conventional framework is the better fit, and the README's own framing supports that reading.

Licence, maintenance and what to verify before you commit

exo is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive in the ordinary sense, and it matters here for a specific reason: if the agent edits its own source, the resulting derivative is still governed by MIT, so you keep the same obligations you started with. This is not legal advice; read the LICENSE file in the repository for the operative text. On maintenance, the material shows an active repository, not archived, with a recent push and CI and integration test workflows configured in GitHub Actions. There are no retrieved releases, so there is no changelog or semantic version to track and no upgrade path documented beyond ./exo.sh fresh, which the README describes as rebuilding and deleting all agents and conversations. That command is the honest upgrade story for a self-modifying system: state that was evolved by a previous harness may not survive a rebuild, and the README does not claim it will. Before adopting, verify the event log's enforcement yourself in the source, confirm setup.sh completes with Docker and git present, and check whether the canonical template's Docker sandbox is compatible with the network access and credentials your agent will need.

Editorial conclusion

Adopt exo if you are building a long-lived agent and you want the harness itself to be editable by the model rather than frozen in your repo, and if you are comfortable running it inside the Docker sandbox the canonical template provides. Do not adopt it if you want a stable, pinned agent runtime with a conventional release cadence, or if you cannot accept an agent that modifies its own prompts and policy between runs. Before committing, verify three things yourself: that setup.sh completes on your machine with Docker and git present, that pnpm events:tail shows the turn boundaries you expect, and that the event log is genuinely outside the agent's write path, since the README states that is the one thing it cannot alter.

Official sources

1. exoharness/exo on GitHub
2. Issues
3. License: MIT
4. Project website
5. README