# Exo: Harnesses should see their own code and logs — Alex Krentsel

## Executive summary

Exo is presented as a novel agent harness designed for fully recursive self-improvement (RSI). Unlike previous agents that only allow modification in specific areas (like memory or skills), Exo's architecture enables the agent to safely and incrementally modify all aspects of itself—including its own code, context construction policy, and tools—at runtime. This is achieved by decomposing the agent into three isolated layers: the Executor (policy/decision-making), the Exo Harness (state management/secrets), and the Sandbox (isolated execution environment). The system's ability to operate in this same medium as its output code is argued to be the key differentiator enabling true RSI.

## Key takeaways

- Shift from Model Weights to Agent Harnesses: The industry focus is shifting from improving LLM model weights (the 'brain') to optimizing the agent harness and tooling ('the body'). The harness provides critical structure, allowing for improvements in efficiency, cost reduction, and task performance.
- Full Recursive Self-Improvement (RSI): Exo is designed to be fully recursive, meaning it can operate on any aspect of itself—from prompts or memory to the basic harness policy. This capability allows the system to improve its own architecture and logic without external human intervention.
- Architectural Separation for Safety: The agent is decomposed into three distinct layers: the Executor (stateless policy), the Exo Harness (state/secrets), and the Sandbox (isolated execution). This separation ensures that self-modification can occur safely, preventing data leaks or loss of history.
- Cost Optimization via Self-Improvement: Exo demonstrated the ability to autonomously rearchitect its own Discord adapter at runtime, scoping down context assembly from across multiple threads. This resulted in a verified 96% decrease in API call costs.

## Technical details

- Agent Definition and Policy: An agent is defined as an LLM call wrapped in machinery that constructs context. The 'Policy' encompasses all decisions regarding context assembly (e.g., using the last 10 messages vs. a summary of 90), tools, and skills.
- Exo Architecture Components: The architecture splits an agent into: 1) **Executor**: Contains all policy logic (stateless). 2) **Exo Harness**: Maintains protected state, conversation history, and secrets. 3) **Sandbox**: The isolated environment where actions are executed (e.g., running a bash command).
- Self-Modification Mechanism: Exo achieves self-improvement by mounting its own code for the Executor within the Sandbox. A special guardian process allows the Executor to be rebuilt mid-step, with automatic rollback mechanisms ensuring stability.
- State and Compute Separation: The separation of state (Exo Harness) from compute/policy (Executor + Sandbox) is crucial for making the agent 'teleportable' and resumable across different environments or services.

## Practical implications

- Enables the creation of highly autonomous, self-optimizing systems that can adapt their own internal logic and tooling.
- Provides a robust mechanism for cost control by allowing agents to autonomously optimize context assembly (e.g., reducing API token usage).
- The modular architecture facilitates scaling by enabling 'teleportation' of agent sandboxes across different compute environments (local machine to cloud provider like Daytona).

## Topics

AI Agents, Recursive Self-Improvement (RSI), System Architecture, LLM Orchestration, State Management, Software Engineering Principles, OpenClaw, Sky Discover, GitHub Repository (Exo)

Source: https://www.youtube.com/watch?v=5lFD-34dhqE