The Harness Gets a Literature: What the June 2026 Research Wave Adds to Practitioner Harness Engineering

In Brief

• A June 2026 arXiv wave gives the agent harness a four-condition constitutive definition — from a single-author conceptual paper, not yet peer-reviewed, that the community may or may not adopt.
• Two benchmark papers isolate the harness contribution from the model contribution, the measurement gap the April patterns scout left open, reporting a 23.8-point spread across harnesses on a fixed model pool and a 54-point adapter swing on a single backbone.
• Four papers make the harness the object of an optimization loop and report headline gains of 7 to 21 points attributed to scaffolding rather than weights, but every result is a fresh preprint on a coding, tool-use, or long-context benchmark, and at least one cannot yet be reproduced.
• A skeptic paper separates “the harness updated itself” from “the update actually helped,” and finds the second far less reliable than the first, with the benefit following an inverted-U in model strength.
• The transfer that holds up in production is the eval discipline around the optimizers — predict each edit’s effect, hold model and tasks fixed, gate on a held-out set — not the auto-optimizer itself, and none of it should touch a permission model.

Why This Matters

For two months the agent harness (the prompts, tools, memory, and control flow that wrap a model into a coding agent) has been a named practitioner discipline without a literature. A June 2026 arXiv wave changed that. Teams have an academic vocabulary to defend harness decisions in design review, and factorial evidence for a bet tracked here since April: the harness you own is a first-class performance lever, not a detail behind the model you rent. The same wave’s self-evolving-harness claims need the skeptic’s read before they touch production.

Key Findings

The figures the findings below turn on, with what each paper held fixed:

The harness now has a constitutive definition, and it excludes things people call harnesses

The word “harness” has been doing too much work. It names the whole product (Claude Code, Codex CLI), the evaluation scaffold that runs an agent against tasks (the SWE-bench harness), and — sloppily — anything adjacent: a framework, an SDK, an IDE plugin, an orchestrator. Sanderson Oliveira de Macedo’s What makes a harness a harness (arXiv:2606.10106, submitted 2026-06-08) is the first attempt to fix the referent with a definition that works “as an instrument, one that includes and excludes cases consistently.”

The constitutive definition, verbatim: “An agent harness is the runtime engineering layer that wraps one or more language models and turns them into an agent able to accomplish tasks over an external environment, by coupling to the model: (i) an agent loop that interleaves reasoning, action, and observation; (ii) a tool interface that lets the model perceive and alter the environment; (iii) context management that decides what enters and leaves the model’s window; and (iv) control mechanisms, that is, limits, verification, and deterministic actions, that make the execution more trustworthy, auditable, and contained” (arXiv:2606.10106).

Those four couplings (the paper labels them T1 through T4) become a runtime inclusion/exclusion test. The paper draws the boundary explicitly against the things harness gets conflated with:

• An agent framework “composes agents; the loop, tools, context, and control belong to the harness it coordinates, not to the framework itself” — the framework is one level up.
• An agent SDK “offers blocks; assembles no loop at runtime” — it’s parts, not a running agent.
• An IDE plugin that autocompletes “suggests code from the cursor without altering the repository or closing a loop.”
• An eval harness “runs commands and applies patches, but measures from outside, after execution” — it observes the agent, it isn’t the agent’s runtime.
• An orchestrator “chains fixed steps; selection is not observation-driven and the loop is not adaptive” — its branching is predetermined, not chosen from observation (arXiv:2606.10106).

The deliberate exclusion that lands hardest: inline autocomplete (the Copilot ghost-text surface) is not a harness, because it neither alters the repository nor runs a reasoning loop.

This maps cleanly onto the practitioner mental model the April patterns scout sourced from Böckeler and Rombaut — the loop, the tools, context management, control. But it does one thing the practitioner essays did not: it gives you a falsifiable test. That matters in design review. “Is our orchestration layer a harness or a framework?” stops being a vocabulary argument and becomes a question you can answer against four conditions.

The paper’s research agenda is organized around four design-tension axes that read as a checklist for any harness build: autonomy vs. control, broad vs. curated context, generalist vs. specialized harnesses, and open permission vs. containment. Every one of those is a decision the April scouts treated as a divergent design area. The definitional paper reframes them as the axes along which the discipline’s open problems live.

One caveat, stated plainly: this is a single-author conceptual paper, fresh to arXiv and not yet peer-reviewed. Its contribution is a definition, not an empirical result. Definitions are adopted by usage, not proven by experiment. Read it as a well-argued candidate vocabulary the community may or may not converge on, not a settled standard.

Two papers isolate the harness from the model, closing the measurement gap the April scout flagged

The April patterns scout’s third open question was blunt: “There is no standard benchmark for harness quality independent of model quality. SWE-bench conflates both.” Two June-adjacent papers attack exactly that conflation, and they are the wave’s most directly actionable items.

Harness-Bench (Yao et al., arXiv:2605.27922, 2026-05-27) runs a full factorial design (six configurable harnesses across eight API model backends on a shared 106-task sandboxed set, 5,194 execution trajectories) specifically to measure the harness and model contributions separately rather than as one entangled “resolved rate.” The headline for practitioners is the size of the harness-only effect: among configurable harnesses on the same tasks and the same model pool, the paper reports a 23.8-point spread between the best and worst harness (NanoBot at 76.2% vs. OpenClaw at 52.4%). Its second finding is the one to internalize: “stronger model backends tend to achieve higher mean scores while exhibiting lower cross-harness variance” — i.e., the weaker your model, the more your harness decides your outcome. The paper frames the harness, in its own abstract, as “the system layer that manages context, tools, state, constraints, permissions, tracing, and recovery” (arXiv:2605.27922).

Its factorial result restates the April thesis as a measured one: agent performance turns on the base model and on that layer alike (arXiv:2605.27922).

Claw-SWE-Bench (Zheng et al., arXiv:2606.12344, 2026-06-10) comes at fairness from the other direction. It is a 350-instance, 8-language, 43-repository SWE-bench-style benchmark whose real contribution is an adapter protocol — “a fixed prompt, runtime budget, workspace contract, patch extraction procedure, and evaluator” — that makes heterogeneous harnesses comparable under matched conditions.

(OpenClaw here is the open-source personal-agent project from Peter Steinberger — the Markdown-skills, memory-on-disk agent, distinct from “OpenClaw-style,” which the paper uses as a shorthand for the broad general-agent harness shape these benchmarks target.) The number that should stop a practitioner: OpenClaw with a minimal direct-diff adapter scores 19.1% Pass@1, and the full adapter reaches 73.4% — “with the same GLM 5.1 backbone” (arXiv:2606.12344).

Same model, same tasks: a 54-point swing produced by the full adapter protocol — fixed prompt, runtime budget, workspace contract, patch extraction, and evaluator — rather than a minimal direct-diff adapter. The adapter is a harness concern in the purest sense, and a swing this size rivals what switching the model entirely buys on this benchmark.

Read together, these two are the empirical backbone of a claim the April scouts could only source from Böckeler’s framework, Rombaut’s taxonomy, and a single Devin datapoint: that the harness rivals model choice as a performance lever, and is the one you actually control. The magnitudes are comparable — Claw-SWE-Bench measured a 27.4-point harness effect against a 29.4-point model effect under fixed conditions — but only the harness is yours to tune.

The practitioner action is concrete. A bare SWE-bench number bundles three causally distinct things: the model, the harness, and the task set. Hold two fixed and vary one. Both papers are templates for doing that internally.

Four papers make the harness the object of an optimization loop

The April production scout covered LangChain’s “harness hill-climbing” — evals as training data for the harness rather than the model, with each iteration running autonomously and a human reviewing the result rather than proposing it. The June wave takes that loop into the literature and pushes it further: measured under controlled conditions, in one case without labels, and in two cases with the harness modifying itself from inside the agent’s own loop. Four papers stake out the design space, and the differences between them are the practitioner-relevant part.

HarnessX (Chen et al., arXiv:2606.14249, 2026-06-12) is the widest in scope of the four: a “foundry for composable, adaptive, and evolvable agent harnesses” that assembles typed primitives via a substitution algebra and evolves them with AEGIS, a “trace-driven multi-agent evolution engine.”

Across five benchmarks (ALFWorld, GAIA, WebShop, τ³-Bench, SWE-bench Verified) it reports an average gain of +14.5% (up to +44.0%), “with gains largest where baselines are lowest” — the same weak-model-benefits-most pattern Harness-Bench observed, now from the optimization side. Its thesis sentence is the wave’s manifesto: “agent progress need not come from model scaling alone: composing and evolving runtime interfaces from execution feedback is an actionable and complementary lever” (arXiv:2606.14249).

Note the hedge that matters operationally: the codebase is promised for a “future release,” so this is a results claim you cannot yet reproduce.

Evolving Agents in the Dark (Pan et al., arXiv:2606.05922, 2026-06-04, revised 06-10) is the one to watch, because it removes the dependency that makes hill-climbing expensive: ground-truth labels. Its Retrospective Harness Optimization (RHO) is “a self-supervised method that optimizes the agent harness using only past trajectories” — it selects a coreset of hard past tasks, re-solves them in parallel, and uses self-validation, self-consistency, and the agent’s “own pairwise self-preference” to pick a harness update with no external grader.

The reported result: “a single optimization round improves the pass rate on SWE-Bench Pro from 59% to 78% without any external grading” (arXiv:2606.05922). If that generalizes, it matters more than the raw number. The binding constraint on the LangChain methodology was always the labeled eval set; a label-free loop is what lets continuous harness optimization run unattended. It does not make it cheap: the paper claims no efficiency advantage, and its own accounting puts RHO’s optimization-phase compute in the same order of magnitude as the trajectory-only baselines it compares against.

Agentic Harness Engineering (AHE) (Lin et al., arXiv:2604.25850, 2026-04-28, rev. 05-18) is the one of the four shaped most like production, and the one whose framing transfers cleanly. It drives evolution from three observability pillars — component, experience, and decision observability — and makes every harness edit a prediction checked against the outcome: “Together, these pillars turn every edit into a falsifiable contract, so harness evolution proceeds autonomously without collapsing into trial-and-error.”

Over ten iterations it lifts pass@1 on Terminal-Bench 2 from 69.7% to 77.0%, surpassing the human-designed Codex baseline at 71.9% (arXiv:2604.25850). That last clause is the headline: an auto-evolved harness beating a hand-built production one on a terminal benchmark, in roughly ten rounds.

Self-Harness (Zhang et al., arXiv:2606.09498, 2026-06-08) draws the cleanest architectural line in the set. Its three-stage loop — weakness mining from execution traces, harness proposal, validation by regression test — is, by its own framing, “unlike recent approaches that use stronger external agents to improve the harnesses of weaker ones”; it “seeks to internalize this improvement loop” so the agent edits its own harness from its own failure evidence (arXiv:2606.09498).

On a Terminal-Bench-2.0 subset it reports held-out gains across three open models (MiniMax M2.5 40.5%→61.9%, Qwen3.5-35B-A3B 23.8%→38.1%, GLM-5 42.9%→57.1%) — the held-out part is what argues the optimization generalized past the failures it trained on rather than memorizing them.

The architectural fork to name for anyone evaluating these: external-optimizer designs (HarnessX, AHE) put the optimizer in a separate agent from the one being improved — a stronger model in HarnessX’s case, the same backbone split into distinct analyzer and editor roles in AHE’s; self-improving designs (Self-Harness, RHO) close the loop inside the same agent.

The first is easier to make work and harder to deploy (you need the optimizer agent on hand at optimization time — a stronger model, in HarnessX’s case). The second is the one that scales to “the agent tunes itself in your environment overnight,” and also the one with the larger surface for self-deception, since the agent grades its own homework.

The skeptic’s paper: “the harness updated itself” is not “the update helped”

The single most important paper for a practitioner deciding whether to adopt any of this is the one that pushes back. Harness Updating Is Not Harness Benefit (Lin et al., arXiv:2605.30621, 2026-05-28) disentangles two capabilities that the optimistic papers bundle: harness-updating (can the system generate a persistent, plausible modification to prompts, skills, memory, tools?) and harness-benefit (does that modification actually raise task performance?). The two come apart.

Its first finding undercuts the intuition that a smarter model writes better harness updates: “harness-updating is flat in base capability: models from different capability tiers produce harness updates that lead to surprisingly similar gains” (arXiv:2605.30621) — a small open model produces updates competitive with a frontier model’s.

Its second finding is the inverted-U: harness-benefit is non-monotonic in model strength, with mid-tier models gaining the most and the strongest models gaining less than the middle. The practical recommendation the authors draw is the opposite of the self-evolving hype: invest capability in the task-solving agent and in instruction-following / harness-invocation, not in an ever-fancier evolution mechanism.

This is the direct counterweight to the optimization-loop finding above, and it lines up with the broader practitioner caution on self-improvement. Xinming Tu’s essay on self-evolving agents warns that “harness optimization can overfit to yesterday’s tasks” and that systems “need evaluation sets that represent the future operating distribution, not just the past transcript” (xinmingtu.cn) — which is precisely the failure mode a label-free, self-preference loop like RHO is most exposed to.

The well-known constraint behind all of this: self-improvement is reliable only where outcomes are objectively verifiable. Coding has that signal (tests pass or they don’t), which is exactly why every result in this wave is reported on a benchmark with objectively verifiable outcomes — coding, tool-use, or long-context reasoning — and not on open-ended work.

Recursion enters the harness, and it is the production pattern dressed as a primitive

Recursive Agent Harnesses (Lumer et al., arXiv:2606.13643, 2026-06-11) names a pattern practitioners have been shipping and gives it a controlled measurement. The Recursive Agent Harness (RAH) makes the recursive unit “a full agent harness with filesystem tools, code execution, and planning rather than a model call with no tools” — a parent agent inspects the task, then “generates and runs an executable script that spawns subagent harnesses in parallel for fine-grained workloads and uses structured function calls for small subtasks.”

The paper is explicit that this is the academic study of a deployed thing: “Anthropic’s dynamic workflows let a coding agent write a script that orchestrates subagents at scale”, and RAH formalizes that as the code-first complement to recursive language models (arXiv:2606.13643).

The controlled number is clean because the model is held fixed: with the GPT-5 backbone matched to the published Codex and RLM baselines, RAH improves the Codex coding-agent baseline from 71.75% to 81.36% on Oolong-Synthetic (199 samples, 13 context buckets up to 4M tokens), and the paper attributes that gain to the harness rather than the model; with a stronger Claude Sonnet 4.5 backbone the same design reaches 89.77% (arXiv:2606.13643).

The authors are unusually candid about limits:

• evaluation is confined to one synthetic long-context benchmark;
• there are no ablations on recursion depth or entries-per-subagent;
• on a small number of instances the parent answers directly without writing a spawning script, collapsing RAH to a single coding agent — cases that concentrate at longer context lengths;
• the token/latency profile for the GPT-5 run is uninstrumented.

That last gap is the one that bites in production. Spawning subagent harnesses (not subagent model calls) is where the paper says the cost scales, and a paper that doesn’t report tokens is leaving out the number that decides whether the pattern pays for itself once every branch bills at API rates.

Where the research diverges from production practice

The useful thing to extract from a research wave is where it does not match how teams actually build — that gap is where the transfer requires judgment, not copying.

The benchmarks are coding, tool-use, and long-context; production harness pain is increasingly elsewhere. Every result in this wave lands on a verifiable benchmark (SWE-bench Pro, Terminal-Bench, Oolong-Synthetic, GAIA, τ³-Bench), because self-improvement needs a clean signal. But the harness decisions that hurt most in production — credential isolation, sandbox containment, permission gating, the harness-escape attack surface — have no benchmark in this wave at all.

The definitional paper names “open permission vs. containment” as a design axis; none of the optimization papers optimize for it. An auto-evolved harness optimizes the dimension it can measure, and security is the dimension it can’t. Do not let a self-tuning loop touch your permission model.

“The harness improves itself” is a results claim, not yet a deployable component. HarnessX’s code is a future release; RAH’s cost profile is uninstrumented; RHO’s label-free loop is one paper old. The skeptic paper is the live constraint: harness-benefit is unreliable and uneven across model tiers.

The transferable artifact from this cluster is the eval discipline the optimizers are built on, not the auto-optimizer itself. AHE’s “every edit is a falsifiable contract” and Self-Harness’s “regression-test the proposal” are practices a team can adopt today without any self-modifying machinery: when you change your harness, predict the effect, hold model and tasks fixed, and gate the change on a held-out set. That is the durable lesson, and it’s the same one the April production scout drew from LangChain’s hill-climbing, now with five more papers behind it.

The community list is still catching up to the literature. The practitioner consolidation point is the awesome-harness-engineering list, organized into twelve production categories from Agent Loop through Human-in-the-Loop (github.com/ai-boost). It cites Anthropic’s postmortems, Microsoft’s SRE case study, and the foundational essays. As of mid-June it has begun absorbing the definitional work (the constitutive-definition paper now appears under its Foundations section), but the June benchmark and self-evolving-harness papers have not yet landed in it.

That lag is itself the state of play: practice is ahead of the literature on what to build, and the literature is now ahead of practice on how to measure what’s built. The synthesis — practitioner categories plus the benchmark methodology to evaluate them — is the thing neither side has finished assembling.

Practical Implications

1. Adopt the four-condition test as a design-review instrument. The next time a component is described as “our harness,” check it against the definitional paper’s four couplings — agent loop, tool interface, context management, control mechanisms (arXiv:2606.10106). Fail any one and it is not a harness under this definition; which neighbor it is comes from the paper’s boundary table, not from the single failed condition — all five neighbors fail the loop condition, an orchestrator also fails context management, and a missing control mechanism marks what the paper calls a demo without guarantee that trusts the model’s word. This kills a recurring vocabulary argument and forces clarity about which layer owns which responsibility, which is exactly where multi-team agent projects blur.

2. Stop reading bare SWE-bench numbers as harness evidence. A resolved rate conflates the model, the harness, and the task set. When you evaluate a harness change, copy the Harness-Bench / Claw-SWE-Bench discipline: hold the model and tasks fixed, vary only the harness, and read the delta. The 23.8-point cross-harness gap on a fixed model pool (arXiv:2605.27922) and the 54-point adapter swing on a single backbone (arXiv:2606.12344) are the evidence that this is where your controllable gains live.

3. Invest your harness effort disproportionately on weaker/cheaper models. Both the benchmark papers and the optimization papers converge on the same asymmetry: harness effects shrink as the model gets stronger, and grow as it gets weaker (arXiv:2605.27922, arXiv:2606.14249). If your economics push you toward open or smaller models — and the June metering change pushes a lot of teams that way — the harness is where you recover the capability gap. On a frontier model the same effort buys less.

4. Take the eval discipline from the self-evolving papers; leave the auto-optimizer. “Every harness edit is a falsifiable contract” (arXiv:2604.25850) and “regression-test every proposal on held-out tasks” (arXiv:2606.09498) are adoptable now, by hand, with no self-modifying code. They’re also the guardrails that make an auto-optimizer safe later. Build the eval harness and the held-out discipline first; a self-tuning loop without them overfits to yesterday’s transcript, which the skeptic paper and Tu’s essay both warn is the default failure (arXiv:2605.30621, xinmingtu.cn).

5. If you pilot a self-evolving loop, fence it away from security and instrument cost. Confine self-optimization to dimensions with a clean verifiable signal (task success, tool-selection accuracy) and explicitly exclude permission gates, credential handling, and sandbox policy — the harness layers with no benchmark and a real blast radius. Before you adopt recursive subagent spawning, instrument tokens and latency yourself; the RAH result is real but its cost is the one number the paper omits, and the paper says only that cost scales with the number of subagent harnesses spawned (arXiv:2606.13643).

6. Treat label-free harness optimization as the development to watch. RHO’s claim — a meaningful single-round gain with no external grader (arXiv:2606.05922) — is the one that, if it holds, removes the labeling wall on continuous harness tuning. It’s one preprint old and self-preference is exactly where reward-hacking hides, so don’t build on it yet. But it’s the result whose replication would change the economics of the whole hill-climbing loop, and it earns a quarterly re-check.

Open Questions

1. Does the constitutive definition get adopted, or fork? A single-author definition only becomes a standard if the community uses it. The competing risk is that vendors and other papers each keep their own boundary, and “harness” stays polysemous despite a good candidate definition existing. Watch whether the benchmark papers and the next survey cite 2606.10106’s four conditions or quietly reinvent them.

2. Do the self-evolving gains survive replication and a non-coding domain? Every headline number here is a fresh, un-peer-reviewed preprint on a verifiable coding/tool-use benchmark, and at least one (HarnessX) can’t yet be reproduced without released code. The skeptic paper already shows the benefit is uneven across model tiers. Which of these gains hold up under independent replication, and which evaporate off the benchmark distribution?

3. What is the actual cost of recursive harness spawning? RAH’s accuracy gain is clean; its token and latency profile is uninstrumented. The paper reports that cost scales with the subagents spawned and that each one re-reading the shared context is the dominant recurring cost, but it does not measure how a subagent harness compares with a subagent model call — and post-meter every branch is its own invoice. Until someone reports tokens-per-task, the pattern’s production economics are unknown.

4. Can harness security become a measurable dimension? The optimization papers improve what they can benchmark, and there is no benchmark in this wave for credential isolation, containment, or permission-gate accuracy. Without one, self-evolving harnesses will systematically optimize away from security because it’s the dimension they can’t score. Does a harness-security benchmark emerge to close that gap?

5. Where does the external-optimizer vs. self-improving fork settle? External-optimizer designs are easier to make work but need a separate optimizer agent at optimization time; self-improving designs scale to overnight self-tuning but carry the larger self-deception surface. Production teams will pick one architecture. Which one wins likely depends on whether label-free self-validation (RHO) proves trustworthy or proves to be reward-hacking with extra steps.

Since publication

• 2026-09-01 — All three of the harness-optimization papers above have been revised on arXiv since the June versions these figures come from: HarnessX (2606.14249) posted v3 on July 23, 2026, Self-Harness (2606.09498) posted v3 on August 20, 2026, and Evolving Agents in the Dark / RHO (2606.05922) posted v3 on August 29, 2026. The HarnessX and Self-Harness results quoted in this piece are from v1, and the RHO results from the June 10 v2 revision the piece cites; readers comparing against the current versions should expect the numbers to have moved.

Sources

1. Oliveira de Macedo, S. “What makes a harness a harness: necessary and sufficient conditions for an agent harness.” arXiv:2606.10106, June 8, 2026
2. Lumer, E., Sen, S., Paul, K., Subbiah, V.K. “Recursive Agent Harnesses.” arXiv:2606.13643, June 11, 2026
3. Chen, T. et al. “HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry.” arXiv:2606.14249, June 12, 2026
4. Pan, W. et al. “Evolving Agents in the Dark: Retrospective Harness Optimization via Self-Preference.” arXiv:2606.05922, June 4, 2026 (rev. June 10)
5. Lin, M. et al. “Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents.” arXiv:2605.30621, May 28, 2026
6. Lin, J. et al. “Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses.” arXiv:2604.25850, April 28, 2026 (rev. May 18)
7. Zhang, H. et al. “Self-Harness: Harnesses That Improve Themselves.” arXiv:2606.09498, June 8, 2026
8. Zheng, M. et al. “Claw-SWE-Bench: A Benchmark for Evaluating OpenClaw-style Agent Harnesses on Coding Tasks.” arXiv:2606.12344, June 10, 2026
9. Yao, Y. et al. “Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows.” arXiv:2605.27922, May 27, 2026
10. Tu, X. “The What & When of Self-Evolving Agents.” xinmingtu.cn, 2026
11. ai-boost. “awesome-harness-engineering: Awesome list for AI agent harness engineering.” GitHub, 2026
12. SWE-bench. “SWE-bench: Can Language Models Resolve Real-world GitHub Issues?” GitHub
13. Böckeler, B. “Harness engineering for coding agent users.” martinfowler.com, April 2, 2026
14. Rombaut, B. “Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures.” arXiv:2604.03515, April 3, 2026
15. LangChain. “Better Harness: A Recipe for Harness Hill-Climbing with Evals.” blog.langchain.com, April 2026
16. Prior Scout: “Harness Engineering Patterns: From Mental Model to Implementation.” archive/scouts/2026-04-06-harness-engineering-patterns.md, April 6, 2026
17. Prior Scout: “Harness Engineering in Production — Frontier Evidence and the Lock-In Critique.” archive/scouts/2026-04-12-harness-engineering-production-scale.md, April 12, 2026
18. Prior Scout: “Harness-Escape Patterns — ExploitGym, Ona, Cymulate, and Antigravity Compared.” archive/scouts/2026-05-18-harness-escape-patterns-2026-05.md, May 18, 2026