Exo: A Recursive Self-Improving Agent Harness
Exo is an agent + harness architecture that is fully recursive, able to safely edit all aspects of itself at runtime to get better at your tasks.
At a glance
- What is it?
- Exo is an agent harness written in Rust and TypeScript that gives an AI agent full visibility into its own code and runtime logs, letting it modify prompts, tools, memory, and core harness policies at runtime. It is designed as the minimal framework for recursive self-improvement, using a durable event log as the one component the agent cannot alter.
- Who is it for?
- Exo is the right tool for engineers who want to build long-lived agents that can evolve their own capabilities beyond memory and skill updates, and who are comfortable running Rust and Docker locally. The setup script handles dependencies, but the framework assumes engineering familiarity.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The Problem Exo Is Designed to Solve
Most agent frameworks let an agent update its memory or create new skills, but the core harness, the policy rules, tool definitions, and execution model, remains fixed at build time. Exo's central claim, stated directly in the README, is that it 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 README distinguishes Exo from tools like OpenClaw, Pi, or Hermes, which it describes as supporting tools, tasks, and integrations. What Exo adds is full visibility into both its code and runtime logs, allowing incremental improvement of every aspect of itself rather than just memory and skill layers.
The use cases the README describes include agents that learn to play games by modifying themselves heavily, agents that cost-optimise their own operations, and agents that build complex systems. All required self-modification beyond the memory layer.
Architecture: Event Log, Templates, and the Docker Sandbox
Exo has a small number of core components. The event log is the one component the agent cannot modify: it provides a canonical history of what the agent has attempted, preventing recursive loops. Every message, tool call, result, and turn boundary is written to this log.
Agents run in a Docker sandbox by default. The canonical template mounts the repository at `/workspace/exo`, starts the Docker sandbox, and launches ExoChat for remote web access. Two alternative templates are available: `dev`, which sets up IRC and Discord instead of ExoChat, and `minimal`, a bare REPL with no Docker defaults.
The scheduler and adapter services run alongside the agent. Adapters handle delivery channels: Discord, Slack, WhatsApp, Signal, and IRC are supported out of the box, configured by asking the agent to set them up. Scheduled tasks run through the scheduler service. Separate log files at `.exo/exo-scheduler.log` and `.exo/exo-adapters.log` track these services independently from the main event stream.
Installing and Starting Exo
Exo requires git and Docker. The README states the setup script offers to install them if missing, and installs pinned Node.js, pnpm, and Rust toolchains automatically via mise. To install:
curl -fsSL https://raw.githubusercontent.com/exoharness/exo/main/setup.sh -o setup.sh
bash setup.shThe setup script prompts for an OpenAI or OpenRouter API key, your name, and your agent's name. It then gives you the command to start Exo. After the first install, use `./exo.sh` to operate the agent:
./exo.sh
./exo.sh list
./exo.sh stop-all
./exo.sh fresh
./exo.sh setup-profile
./exo.sh --helpThe most common day-to-day commands are `stop-all` to shut down the scheduler and adapters (state is preserved) and plain `./exo.sh` to bring it back. The `fresh` command rebuilds and deletes all agent and conversation state, starting clean. The `.env.example` file at the root shows which API keys are supported: OPENAI_API_KEY, OPENROUTER_API_KEY, and ANTHROPIC_API_KEY, among others.
Observing What the Agent Is Doing
To follow the agent's activity in real time, the README instructs running the event tail from a second terminal:
pnpm events:tailThis streams recent messages, tool calls and results, and turn boundaries, then continues following new events. By default it tails the `exo-agent` agent and `dev` conversation. The README shows options for targeting different agents or controlling how much history is shown.
The event log and host-side logs remain available across ordinary restarts. Running `./exo.sh fresh` deletes agent and conversation state, so anything useful for debugging should be preserved before using that command.
A good first test the README suggests is asking the agent to install python3 and curl in the sandbox, then schedule a recurring task. This exercises the sandbox, tool calling, and the task scheduler in a single interaction.
Self-Modification and the Limits of Recursion
The README describes Exo as "fully recursive" in contrast to agents that can only update memory or create new skills. The agent can modify its own prompts, tool definitions, memory, and harness policy. It can also clone itself and manage a lineage of clones.
The safety mechanism is the event log. The README describes it as "a canonical history of what it's tried to prevent getting stuck in recursive loops." This is the one component the agent is not permitted to alter.
The README is candid that self-modification is done "incrementally and (mostly) safely." The parenthetical "mostly" signals a real constraint: there is no formal proof of safety, only the event log as a circuit breaker and the incremental design philosophy. The README also notes that understanding the internal components (event log, agent loop, tool dispatch, scheduler) makes it easier to guide the agent's self-evolution effectively, even if using Exo does not require knowing those internals.
Comparison With Conventional Agent Frameworks
The README cites OpenClaw, Pi, and Hermes as comparable tools that implement tools, tasks, and integrations similar to what Exo provides. The key difference Exo describes is its full visibility into its own code and logs: most agent frameworks expose a fixed API surface to the agent, while Exo mounts the repository at `/workspace/exo`, giving the agent read and write access to its own implementation.
In practice, this means Exo is designed for building agents that are expected to run for extended periods and evolve their capabilities. A conventional agent framework is better suited when you need a predictable, stable agent behaviour and do not want the agent modifying its own operation.
Exo's Rust core handles the execution environment, sandbox management, and event logging. The TypeScript layer handles the chat interfaces, adapters, and scheduling. The package.json shows direct dependencies on the Anthropic Claude Agent SDK alongside OpenAI and OpenRouter clients.
Repository Activity and License
The repository is not archived. The last push was on 2026-09-27. There are no GitHub releases; the version in Cargo.toml is 0.1.0, indicating the project is still in early development. The Rust workspace requires Rust edition 2024 and a minimum of rust-version 1.95, which requires a recent Rust toolchain.
Exo is licensed under MIT. The `.env.example` file at the root shows support for Braintrust, OpenAI, OpenRouter, Anthropic, and Cursor API keys. Firecracker microVM support is referenced in the Makefile with `restart-firecracker-lima` and `clean-firecracker-microvms` targets for environments that use Lima VMs. The Cargo.toml workspace includes crates for the CLI, executor, managed agents, MCP server, and Firecracker protocol and guest, reflecting the scope of the system.
Editorial conclusion
Exo is the right tool for engineers who want to build long-lived agents that can evolve their own capabilities beyond memory and skill updates, and who are comfortable running Rust and Docker locally. The setup script handles dependencies, but the framework assumes engineering familiarity. Teams with large Python-based agent infrastructure will find the Rust core difficult to extend without adopting the TypeScript and Rust toolchain. Verify your OpenAI or OpenRouter API key is available before running setup.sh, as that is a required first-run input.
Frequently asked questions
What is Exo for AI?
Exo is an agent harness that gives an AI agent full visibility into its own code and runtime logs, allowing it to modify prompts, tools, memory, and harness policies at runtime. The README positions it as a minimal framework for recursive self-improvement, where the agent can incrementally evolve every aspect of itself.
How do I install Exo?
Download and run the setup script with curl and bash. The script installs dependencies automatically via mise, then prompts for an API key and agent name. After setup, the `./exo.sh` script in the repository root starts and manages the agent.
What is Exo software?
Exo is a Rust and TypeScript framework for running long-lived AI agents that can modify themselves at runtime. It includes a Docker sandbox, a chat interface called ExoChat, a scheduler for recurring tasks, and adapters for messaging platforms including Discord, Slack, WhatsApp, and Signal.
What is the Exo Project?
The Exo Project at exoharness/exo is an open-source effort to build the minimal framework for recursive self-improvement in AI agents. Its central design principle is that the agent should have full access to its own code and logs, with only the event log kept immutable to prevent recursive loops.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/exoharness-exo)