Exo agent harness architecture

@martin_casado Wow! Somehow I am not surprised by this. If anyone is interested, I wrote about exo and why it might be a bigger deal than it seems here: x.com/omarsar0/statu… elvis @omarsar0 Solving recursive self-improvement with a harness. The big question with the agent harnesses I use is: how does it support RSI and compound on every iteration? What capabilities do I need to own the harness? What are the best solutions right now? Something important to understand when using harnesses. Once an agent starts rewriting its own prompts, tools, and memory, you need durable state underneath it that the agent cannot modify, plus a way to roll a run back to an earlier checkpoint. exo is a new open-source agent harness built to solve exactly that. It splits an agent into three layers. 1) The exoharness stores everything durable. Conversation history is an append-only event log the agent cannot alter, and it holds artifacts, secrets, and sandbox lifecycle alongside it. 2) The executor decides how the agent behaves. It assembles the prompt, calls the model, dispatches tools, and manages memory. The agent can rewrite any of that, and you can swap the executor for another harness. 3) The sandbox runs the important work. Packages, files, and commands execute in an isolated machine you can snapshot and rewind. You can do many things with that setup. - Fork a conversation from any event and run two versions of the same task - Roll back to the event right before an agent broke itself - Resume a conversation weeks later with its full history and its own mount - Read which commands actually ran from tool_requested and tool_result Agents will keep taking on more of their own configuration, and that raises the bar for the harness underneath them. It reaches a point where an event log, forking, and rollback are must-haves. 🔗 View Quoted Tweet 💬 2 🔄 2 ❤️ 13 👀 4876 📊 5 ⚡