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

An introduction to Exo, a fully recursive AI agent harnessing a novel three-layer architecture (Executor, Harness, Sandbox) designed for autonomous self-improvement. It delves into how Exo surpasses current agent limitations by allowing the agent to edit its own code and policy at runtime, ensuring protected state and isolated execution, and discusses practical implications and the underlying systems philosophy enabling this paradigm shift.

5 min read
Exo: Harnesses should see their own code and logs — Alex Krentsel
source: https://www.youtube.com/watch?v=5lFD-34dhqE

Alex Cransel, a PhD candidate from UC Berkeley, introduces Exo, a novel AI agent designed for full recursive self-improvement. Exo’s core thesis is to “collapse the loop,” meaning the system itself is responsible for optimizing and improving its own operation rather than relying on an external observer. This is achieved by allowing the agent to safely edit all aspects of itself at runtime, from prompts and memory to tooling and even its fundamental harness policy.

Cransel critiques existing agent systems like OpenClaw, noting their adaptability is often limited to predefined extension points—such as memory management, adding skills, or tools—and frequently requires human intervention. While these systems offer extensibility and a form of self-improvement through memory updates, they do not permit the agent to modify its underlying architecture or core policy. Exo, in contrast, aims to make all components of an agent improvable, including how context is assembled, prompts are constructed, compaction strategies, tools, skills, and the agent’s fundamental code. He defines an agent as an LLM call wrapped in machinery for context construction and action execution, with “policy” encompassing all decisions related to context assembly and action.

Exo’s architecture is opinionated and partitions an agent into three distinct, important layers:

  1. Exo Harness: This layer is stateful and designed to hold all protected state, including conversation history, sensitive secrets (like API keys), and environmental artifacts or snapshots. Crucially, it isolates this state from the agent’s direct manipulation, enhancing security and preventing unintended data loss or leakage.
  2. Executor: This layer is entirely stateless and contains all policy decisions. This includes logic for assembling the LLM call, managing prompts, applying compaction, defining available skills and tools, and dictating how the agent decides its actions.
  3. Sandbox: This is the isolated environment where actual actions, such as executing bash commands, take place. It is distinct from the policy process, which can run elsewhere.

This decomposition offers several benefits: isolated execution, protected state, and a stateless Executor layer that is safe for self-evolution. The Exo Harness also provides snapshot mechanisms, allowing the agent to capture the state of the sandbox environment and perform rollbacks if proposed changes lead to errors.

The recursive self-improvement mechanism works by mounting the Executor’s own code within the Sandbox. This allows the agent to see, edit, and rebuild its own code at runtime. A “guardian process” within the Exo Harness manages this rebuilding, enabling mid-run swaps and providing a “soaking” mechanism where, after being rebuilt, the new Executor runs for one step. If it breaks, it’s automatically rolled back to the previous stable state. This enables the agent to autonomously build new tools, write new skills, or adjust any aspect of its context assembly and policy.

Cransel also addresses specific architectural considerations:

  • Teleportation: While less critical for single-agent, local tasks, teleportation (the ability to move agent state and execution environments) becomes vital for scaling, such as managing thousands of parallel agent conversations for different users or offloading computationally intensive sandboxes to the cloud.
  • Sub-agents: The spawning and management of sub-agents are considered policy decisions residing in the Executor. While not natively implemented in Exo’s initial build, the architecture fully supports their creation as a code-defined policy.
  • Secret Store: The explicit secret store within the Exo Harness is critical for security, preventing LLMs from directly accessing or exfiltrating sensitive credentials.
  • Real-time Agents: This domain requires rethinking how agents handle interruptible work and signaling, potentially involving pub/sub buses or robust signal passing mechanisms for background tasks, moving beyond the current non-interruptible nature of many agent threads.
  • ACP (Agent Communication Protocol): While not yet integrated, the idea of standardizing communication between coding agents is acknowledged as a potential future area, though Cransel notes the trade-off with lowest common denominator issues.

The project is a collaboration between Alex Cransel (systems researcher at Berkeley), Martin Casado (VC, systems thinker), and Ankur Goyal (Brain Trust, systems thinker). Cransel, coming from a strict systems background (SDN, formal verification), emphasizes that architecture-enforced properties are more robust for AI safety and reliability than relying on LLM alignment alone.

In practice, Exo has demonstrated self-improvement, notably in cost optimization. By having access to conversation history annotated with costs, Exo was able to analyze its own operational expenses. In one instance, it autonomously re-architected its Discord adapter to reduce the cost of LLM calls by 96% by intelligently scoping the context included. This highlights the “evaluator problem”—the need for a clear, aligned evaluation function to prevent reward hacking. Cransel agrees that a robust eval framework is necessary to ensure self-improvements do not degrade performance.

Cransel argues that recursive self-improvement is uniquely possible now because of a fundamental shift in the AI landscape. Previously, improving LLMs involved iterating on model weights—a process (like gradient descent) that is not in the same medium as the model’s output and cannot be self-applied by the LLM itself due to scale and context limitations. However, with the focus shifting to agent harnesses, the medium of improvement (code) is the same as the LLM’s output. LLMs are increasingly proficient at writing and modifying code. This direct correspondence creates a powerful “flywheel” effect, enabling the agent to literally produce and execute the changes to itself. This concept resonates with programming paradigms like Lisp, where the language can manipulate its own structures.

Exo’s GitHub (github.com/exoharness/exo) and Discord community are open for contributions and discussion, fostering an early community around this evolving field.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

Evolution of agentic surfaces — Gagan Bhat & Isabella Kai He, Anthropic

Evolution of agentic surfaces — Gagan Bhat & Isabella Kai He, Anthropic

Anthropic's Gagan Bhat and Isabella Kai He discuss how agent harnesses must evolve rapidly to keep pace with fast-improving LLMs. They introduce Claude Managed Agents, an architecture that decouples the agent's 'brain' (reasoning) from its 'hands' (tool execution) to address issues like stale assumptions, latency, and reliability. This approach enables dynamic adaptation, secure tool execution, and features like 'dreaming' for self-improving agents and 'outcomes' for goal-oriented task completion, ultimately aiming to close the gap between model capabilities and product offerings.

When to Build Your Own Agent Harness | Harrison Chase, LangChain

When to Build Your Own Agent Harness | Harrison Chase, LangChain

Harrison Chase, co-founder of LangChain, delves into the critical role of the 'harness' in LLM agents, explaining how it orchestrates models and context. He covers customizing harnesses with middleware and sub-agents, the trade-offs between off-the-shelf and custom solutions for in- and out-of-distribution tasks, and the importance of evaluations and observability for continuous agent improvement. The discussion culminates in the 'data flywheel' concept and the `LangSmith Engine` for automating agent intelligence through iterative refinement.