Towards a Harness That Can Do Anything

For several years, I have been preoccupied with a single objective: liberating Large Language Models (LLMs) from the confines of the chat interface. By observing various attempts—and analyzing their successes and failures—I have developed a specific philosophy on the ideal architecture for an agentic "harness."

Below are my current reflections and the framework I have been developing.

Core Architectural Pillars

To build a truly capable harness, we must prioritize the following:

• Absolute Transparency: Every action must be visible. This allows the Agent to perform self-development, execute self-healing, or provide a clear trail for postmortem audits.
• Resilience: The system must ensure fragile robust survival across errors and updates, preventing memory degradation or corruption over time.
• Reliability: As LLM intelligence scales, the harness itself will naturally become more dependable.
• Cognitive Optimization: The primary challenge is minimizing the "cognitive load" placed on the model. We can express this as: $\text{Cognitive Load} \approx \sum (\text{Input Tokens} + \text{Contextual Noise})$

Preliminary Truths

Through years of iteration, these fundamental realizations have emerged:

• Goal vs. Process: The LLM should decide which goal to pursue, but the actual deliberation process toward that goal should be structured as a series of well-defined steps.
• Dynamic Context: The core system prompt must remain lean. The LLM should dynamically select and load specific "skills" into its context only when needed at runtime.

---

Don't Play the Odds, Play the Bot

A superior harness leverages the LLM's a priori knowledge. Because training sets are heavily saturated with coding and systems administration data, the LLM is already "fluent" in these environments.

The Strategy: Instead of forcing a bot to learn a novel, proprietary environment—which wastes precious tokens—place it in an environment it already understands.

Efficiency Gains

• Avoid Waste: Do not spend context window space on trivialities like file traversal or discovery.
• Background Heavy-Lifting: The harness should feel "light" to the LLM while performing complex operations in the background, such as:
  • Sanitization and failsafes.
  • Sanity checks.
  • Comprehensive logging.

---

Auditability, Logging, and Self-Healing

Failure is inevitable. The key is how the system recovers. I categorize failures into two distinct tiers:

To facilitate self-healing, an Agent requires two critical components: high-fidelity logging and explicit error messaging.

---

A Unified Data Layer: The Unix Hypothesis

Many of our current "Agent" problems are simply old "User" problems rebranded. This leads to my central hypothesis: The Unix/Linux environment is the ideal candidate for an Agentic harness.

While I am not a Unix scholar, a decade of studying its design reveals a beautiful mapping to our current needs. I view Unix not as a direct blueprint, but as a motivating analogy.

The Unix Philosophy $\rightarrow$ Agentic Design

The creed of Ritchie and Thompson provides a perfect framework:

1. Write programs that do one thing and do it well.
2. Build afresh rather than adding bloated features to old programs.
3. Expect the output of one program to be the input of another.
4. Use text streams as the universal interface.

Current harnesses are often too complex and ill-defined, leaving the Agent without true agency. By applying these principles, we can derive a new standard:

• Modular Tools: Create transparent tools that perform a single task and fail loudly.
• The Hierarchy: $\text{Skills} \rightarrow \text{Workflows} \rightarrow \text{Tools} \rightarrow \text{Connectors}$.
• Home Court Advantage: Since LLMs excel at processing text streams, this interface is their natural strength.

---

Ambiance: Implementing the "Everything is a File" Model

LLMs, like humans, find plaintext easier to manage than complex JSON wrangling or massive curl commands. Therefore, the harness should act as a translator, cleaning external data into plaintext before it reaches the model.

The Virtual File System (VFS)

By utilizing the Filesystem Hierarchy Standard (FHS), we can organize data in a way that feels intuitive to an LLM.

This structure allows both the developer and the Agent to use standard utilities for auditing: grep, find, which, rg, and fzf.

The "Kernel" and Execution

The interaction model determines when the Agent acts. A current industry standard, OpenClaw, utilizes a hybrid approach:

1. Event-Driven: Responding to pushed messages.
2. Heartbeat: A fixed-interval turn (e.g., every 30 minutes) to evaluate the state of the world.

The challenge arises when dealing with non-pushed updates, such as a file change...