2 posts tagged with "harness-engineering"

Gartner recorded a 1,445% increase in multi-agent consulting requests last year. In the same period, 40% of multi-agent pilots died within six months.

That gap is the thing worth understanding.

I've been building with agents long enough to know that most framework selection conversations start in the wrong place. Engineers ask "which framework?" when the prior question — do we need multi-agent at all? — hasn't been answered. The data on that prior question is more interesting than most of the framework benchmarks.

Two things landed in the same week and pointed at the same idea.

Martin Fowler named Harness Engineering as the core software engineering work of the AI era at FOSE Europe — specifically the Guide/Sensor model: Guides as feedforward constraints that tell an agent what to do, Sensors as feedback detectors that tell the system when it's drifting. He added an observation worth pinning: token consumption is a proxy metric for harness quality. A better-designed harness means a cheaper, more reliable agent.

Then Lilian Weng published Harness Engineering for Self-Improvement — a systematic review of 35 papers on agent harness engineering, with a thesis that goes beyond reliability: the harness isn't just the thing that makes an agent work. It's the infrastructure through which the agent continuously improves itself.

A friend has been telling me for months that a particular company's bet on the future of software development is: systems that automatically optimize their own code and architecture. Fowler said what we should build now. Weng said what comes after. These three converged into the same question, so I'm trying to map the whole space.

This post maps Evolutionary Search — why it's the natural next step for harness engineering, what the paper landscape looks like organized by evolutionary depth, and where the hard problems actually live. The taxonomy here draws heavily on Weng's framework; I've reorganized it by depth of what gets evolved.