The Google Developers Blog published a piece on harness engineering on September 2, written by Shir Meir Lador. The article's definition of a harness is blunt: everything deterministic wrapped around the LLM — the orchestration layer, the execution sandbox, state persistence, validation tools — all of it counts.
The piece opens with a striking comparison: an experimental OpenAI product with zero lines of hand-written code, built and shipped as an internal test version by three engineers relying entirely on model-generated code. The question the author draws from it isn't about model capability — it's about the structure that keeps the model inside a controllable process.
The Reins, the Blinkers, and the Track
The article reaches for a horse-racing metaphor: the model is the horse, and the harness is the track, the blinkers, and the reins — the parts that keep it running in one direction.
"The harness is composed of all the deterministic components that wrap the LLM."
That definition relocates a chunk of work that used to be filed under "prompt engineering." There are really only two ways to constrain a model's behavior: write it into the prompt, or write it into the code around the model. The first relies on the model choosing to comply, and needs retuning every time the model changes; the second is a hard constraint that survives model upgrades untouched. Most teams building agent products over the past year have tried both, and paid for both. Tell the model in the prompt "don't modify the test files," and by the thirtieth turn of a long context, it starts going selectively blind to that instruction.
Three Design Principles
Strict boundaries. Lock the agent inside a sandbox so it never gets near production data. In the article's demo, the agent can only write files inside a ./sandbox directory — any operation that steps outside it simply never executes.
A repair loop. Errors shouldn't get thrown straight at a human. When a test run fails, the harness feeds the clean log back to the model so it can fix its own mistake. ADK 2.0's answer here is a graph-based workflow — the validation step is itself a routing node in the graph, and a failed run automatically routes control flow back to the generation node, with no need to hand-write retry logic in the orchestration code.
Progressively discoverable repo structure. Don't dump a several-thousand-line instruction file on the agent all at once. Organize the repository so the agent can work its way in layer by layer, discovering context as it needs it.
The companion Antigravity SDK handles the local-environment side: it marks out workspace boundaries and provides memory persistence. Put the two tools together and they cover both where the agent runs and how it gets back on track when it runs wrong.
A Five-Round Cap and a Kill Switch
The demo runs the self-healing loop through a full cycle: the agent writes code inside the restricted sandbox, tests run automatically, the test fails, the log feeds back, the agent revises, and it runs again. The cap is set at five rounds; hit the limit and the harness cuts the loop off — the author calls it a kill switch.
That five is the most practical number in the whole piece. The typical failure mode of a self-healing loop is the model bouncing back and forth between two broken states, burning tokens every round without converging. A hard cap is an upfront admission that the model sometimes can't fix the problem, and it hands the issue back to a human sooner rather than later. Without that switch, a loop that's gone off the rails can burn through a budget overnight with nobody watching.
Compare this against the agent frameworks that were popular in the first half of this year, and the shift in emphasis is obvious. Earlier frameworks talked mostly about orchestration — how to chain multiple agents together, how to divide labor, how to pass messages. What's being discussed now is validation and boundaries: where execution happens, how errors flow back, and when to stop. The former answers "can it run at all"; the latter answers "can you trust it to run on a real project."
For teams building in China, the two specific tools — ADK 2.0 and the Antigravity SDK — may not be directly usable, but the three principles transfer cleanly. Sandboxing, repair loops, and progressive context are things any homegrown coding agent has to deal with sooner or later; the only question is whether you design for them upfront or patch them in after the agent has deleted your test files once.
Sources: Google Developers Blog, CocoLoop, ADK and Antigravity SDK project documentation; the harness definition, the three design principles, and the five-round cap were checked against the original article, while the zero-lines-of-code and three-engineers figures are cited from the article's own account.