Exo is a new open-source agent runtime, and an accompanying arXiv paper, built around one idea: let the agent read and rewrite its own harness while it works. The paper, "Exo: An Architecture for Self-Improving Systems at Runtime", was submitted on October 30, 2026 by Alexander Krentsel, Sylvia Ratnasamy, Ion Stoica, Martin Casado and Ankur Goyal. The code lives in the exoharness/exo repository under an MIT license.
The authors report that in their tests this cut model cost by 12 to 82 percent against fixed baselines, with similar task completion. Those are the authors' own numbers on their own benchmarks, so read them as promising, not settled. The README also warns that it is under construction.
TL;DR
| Question | Answer |
|---|---|
| What is it? | A runtime where the agent can edit its own harness code, behind a small protected layer |
| Who built it? | Krentsel, Ratnasamy, Stoica, Casado and Goyal (arXiv 2611.00463) |
| License | MIT (repository) |
| Supported harnesses | Codex, Claude Code and Pi out of the box, plus custom |
| Headline result | Model cost down 12 to 82 percent in some tests, completion matched |
| Biggest caveat | Authors' own benchmarks; README "under construction"; install docs incomplete |
| Repo traction | About 1.6k stars and 127 forks when we checked |
Agents that act on your behalf need rules. See how explainx helps secure your agents →
What problem does Exo solve?
An agent harness is the code around a model: how it plans, calls tools, compacts memory and recovers from errors. Our agent harness guide covers the basics. The paper's starting point is that hand-designing harnesses is hard, and automated optimization needs representative datasets and expensive runs.
Exo's answer is to "collapse the optimization loop into task execution," in the paper's words as summarized in the abstract. Instead of a separate offline tuning phase, the agent improves its harness as it does real work. That connects to earlier work we covered, including Self-Harness and Microsoft Research's harness policy optimization.
How Exo is built
According to the paper summary and the README, Exo separates the system into layers:
- A protected layer that records execution history and controls which policies are activated. It is minimal on purpose. The one thing the agent cannot modify is the event log that records its history.
- An executor holding the policy and logic that the agent may edit.
- A sandbox where the code runs. Its own source code is mounted in the sandbox, so the agent can see its code and runtime logs.
The harness then changes through inspectable code edits, not hidden weight updates. A human can read each edit.
The README describes the project as a self-hostable, model- and vendor-neutral alternative to hosted agent APIs. You define an agent in a markdown file, and Exo hosts it behind an API with durable conversations, sandboxes, credentials and network controls. It supports credential substitution and granular network policies, so an agent can reach protected resources without holding raw keys. For a related design, see the minimal Pi harness guide and the Pi 1 durable harness release.
What the paper reports
All figures below are from the authors' abstract.
| Test | Result |
|---|---|
| Open-world game, standalone runs | Model cost down 12 to 53 percent versus Codex and Pi, matching completion |
| Open-world game, transfer runs | Model cost down 45 to 82 percent, matching completion |
| AppWorld and SREGym (versus same start without editing) | Held-out model cost down 35 to 61 percent, comparable correctness |
| AppWorld | Mean task time down 13 percent |
| SREGym | Median diagnosis time down 35 percent |
| Continual Learning Bench (coding) | Model cost including learning down 14 percent; both policies resolved every issue |
Two points deserve attention. First, the coding benchmark shows the smallest gain, 14 percent, and the baseline already solved everything. Second, "transfer runs" show the largest gains, which suggests that edits learned in one run can help another. We have not seen independent replication, and the paper does not claim a universal speedup.
How is Exo different from offline harness tuning?
Most harness-improvement work we have covered runs in two phases. First you collect a dataset of tasks. Then an optimizer proposes harness changes, scores them and keeps the best. That works, but it needs representative data and many paid runs before the first real user benefits.
Exo moves the loop into the live run. The agent does the task, sees its own code and logs, and edits the policy part of the harness as it goes. Three differences follow:
- No separate training set. The task itself is the signal. The paper's "transfer runs" then test whether edits carry over to a new run.
- Edits are readable code. Because the harness changes through inspectable code edits, a reviewer can diff them. That is a different safety story from changing model weights.
- Cost shows up early. The gains the authors report are model cost and time, not only accuracy. An agent that stops repeating expensive calls saves money on the next run.
The trade-off is control. In an offline setup you choose when a change ships. In a runtime setup you need a rule for when an edit is allowed to take effect. In Exo, that is the job of the protected layer, which controls which policies are activated.
Questions builders are likely to ask
Does it replace Claude Code or Codex? No. The README lists them as supported harnesses. Exo sits around the harness as the hosting and self-editing layer.
Can I keep my credentials out of the agent? The README highlights credential substitution and granular network policies, so the agent can reach protected resources without handling the raw secret. Test this in your own setup.
Is it production ready? The README says it is under construction and that installation instructions are still being written. Treat it as a research release.
Will the savings hold for my tasks? Unknown. The reported gains vary a lot, from 14 percent on a coding benchmark to as much as 82 percent in the game transfer runs.
What Exo does not prove
- No third-party replication yet. The paper is days old.
- Cost is not quality. The authors say completion rates matched, but your tasks may differ.
- Self-editing widens the attack surface. A harness that can change its own policy needs strong sandboxing and review. The README's own wording that it can "safely edit all aspects of itself" is a claim from the project, and the page offers few details.
- Immature docs. The README says installation instructions are still being written and that some documented features are still being implemented.
- Forks exist. Several mirrors carry the same description under other accounts. We used the exoharness repository, which looked the most current, but we could not confirm which one is canonical. Check the paper's links before you install anything.
How to try Exo safely
- Clone the repository in a throwaway VM or container, not on a laptop with real credentials.
- Follow the quickstart in the README: define an agent in a markdown file that names a harness such as
codex, store a model key withexo vault secret create global --preset openai, then runexo run your-agent.md --prompt "...". Leave out--promptto open a REPL. - Turn on tight network policies so the agent can reach only the hosts it needs.
- After each session, read the edits the agent made to its harness. Treat them like a pull request from a stranger.
- Compare cost and completion against the same task with a fixed harness.
Why this matters for builders
Harness engineering is where much of today's agent quality comes from, as we explained in our loop engineering guide. If agents can tune that layer themselves, teams may spend less time hand-tuning prompts and tool wrappers, and more time on evaluation and guardrails. A similar direction shows up in Sakana's open-source agentic scientist.
The cost lesson is also practical. The biggest savings come from the agent learning what to skip: fewer wasted model calls on repeated work. Even if you never run Exo, the pattern is worth copying. Log what your agent does, find repeated expensive steps and encode them as cheap code.
The risk lesson is just as clear. A system that edits its own policy must have a part it cannot touch. Exo's event log, which the agent cannot modify, is that part. If you build your own self-improving agent, decide what is immutable before you let it edit anything else. For runtime protection around agents that run code and use credentials, AgentBeam, from the explainx.ai team, is an agent security platform that stops AI agents before they take dangerous actions.
What to watch next
- Independent replications on AppWorld, SREGym and your own tasks.
- Completed installation docs and a stable release of the repository.
- Security reviews of the protected layer and its policy-activation controls.
- Whether major harnesses (Codex, Claude Code, Pi) add native support for runtime self-editing.
Related reading
- What is an agent harness? A complete guide
- Self-Harness: agents that improve themselves
- Microsoft Research harness policy optimization
- Pi: the minimal agent harness
- Pi 1 durable minimal harness
- Loop engineering for coding agents
Details are accurate as of November 5, 2026, from the arXiv abstract and the repository README. Results are the authors' own and have not been independently replicated.