โ—€ Back to posts
Post ยท Jul 08, 2026

Two Ways to Harness AI

On July 4th, Lilian Weng published "Harness Engineering for Self-Improvement" โ€” a 31-minute survey of the research frontier on agent harnesses: the scaffolding systems that surround base models and determine how they plan, act, memorize, and improve. It is one of the clearest treatments of what the deployed AI stack actually looks like beneath the model weights.

The name caught my attention. We have been building something called Harness too.

The overlap is not a coincidence. It is a signal.


The layer Weng is writing about

Weng's central claim is that the harness โ€” the system surrounding a base model that orchestrates execution, calls tools, manages context, stores artifacts, and evaluates results โ€” is as important to AI capability as the raw model itself. She frames it as the gap between a base model and a deployed system, and argues that harness engineering is the near-term practical path toward recursive self-improvement (RSI).

She organizes current research around three foundational design patterns: workflow automation (goal-oriented loops that plan, execute, observe, and iterate until a goal is met), file system as persistent memory (keeping durable state in files rather than in an ever-growing context window), and sub-agents and backend jobs (parallel execution with explicit process management and log-based recovery).

The optimization progression she traces runs: instruction prompts โ†’ structured context โ†’ workflow โ†’ harness code โ†’ optimizer code. The frontier work is at the latter end โ€” systems that optimize their own scaffolding.

Agentic Context Engineering (ACE; Zhang et al., 2025) treats context as an evolving playbook of structured bullets rather than a growing prompt blob. Meta Context Engineering (MCE; Ye et al., 2026) goes further, separating how to manage context from what is in it, evolving both in a bi-level optimization loop. Meta-Harness (Lee et al., 2026) moves to the layer beneath: the optimized object is the harness code itself โ€” a coding agent that writes and evaluates better harnesses.

At the limit, STOP โ€” the Self-Taught Optimizer (Zelikman et al., 2023) โ€” showed that a strong model can recursively improve the improver function itself. The cautionary finding: it worked with GPT-4 but degraded with weaker models. Harness self-improvement requires sufficient base model capability to exploit its own scaffolding.

Weng's central challenge: as agents become more capable, the harness design space becomes enormous and increasingly automated. Human engineers can no longer hand-craft optimal scaffolding. The harness itself must become the optimization target.

This is a capability problem. It is a capability problem around the model.


The layer we're building at

BoldBlack's Harness operates at the boundary between your application and the LLM provider โ€” not inside the agent's execution loop, but around it. Every prompt and response flows through a policy engine. Rules are declared in YAML, version-controlled, scoped to users, roles, and environments. Outputs are filtered before users see them. Every decision is logged and auditable.

Where Weng is asking "how do we make the model's harness improve itself?", we are asking "how do we make the model's behavior safe to deploy, regardless of how it was orchestrated?"

These are different problems. They are also deeply related.


The gap between them is where incidents live

Here is what the research literature does not fully address: the problems enterprises actually face do not usually begin with suboptimal harness design. They begin when an LLM deployed in a production system says something it should not, leaks data from another tenant's session, or produces a response that a reasonable legal or compliance team would classify as a liability.

Weng's research improves an agent's capability to operate and self-improve. It does not, by design, answer the question: who audits what the harness did, why, and when?

That is not a criticism of the research agenda. It is a description of a different layer of the stack โ€” one that enterprise teams are responsible for whether or not they have PhDs.


Where the two approaches converge

Some of the most interesting work Weng covers points directly toward the governance layer.

The emphasis on file system as persistent memory โ€” storing execution logs, rollout trajectories, and decision records as inspectable files โ€” is, at its core, an audit trail architecture. Weng notes it explicitly as a recovery mechanism: if subagent outputs only live in a transient context, they become hidden. If stored as files and logs, the model can recover from interruptions and reason over its own execution history. That same log is what a compliance team needs to answer: what did this system decide, and why?

Permission controls are listed alongside memory and workflow as a foundational harness design concern. Weng treats them as part of the orchestration layer. We implement them as the first line of defense at the application boundary โ€” but they address the same invariant: not every tool call an agent can make is one it should make.

And the newest work she covers โ€” observability-driven harness evolution (Lin et al., 2026) โ€” makes this explicit: you can only improve a harness you can inspect. Observability is not just a debugging feature. It is a prerequisite for both self-improvement and governance.

The research is converging on the infrastructure. We are building that infrastructure.


What this means for enterprise AI teams

If you are deploying LLMs in production today, your governance challenge is not primarily about building better self-improving scaffolding. It is about ensuring the agents you have โ€” whatever their internal orchestration โ€” operate within defined boundaries, produce auditable decisions, and do not expose you to regulatory or security risk.

That is what Harness is for.

The capability layer and the governance layer need each other. As harnesses become more self-optimizing, the outputs they produce become more powerful and harder to predict in their failure modes. Better scaffolding is not a substitute for external controls. It raises the stakes for having them.


Follow the work