Imagine you're a restaurant manager who started with one all-purpose recipe card for every dish. Pasta, sushi, barbecue — same card. It works, barely. Then you start writing specialized recipe cards for each cuisine, and when a new fusion dish comes in, you inherit from the closest existing card and tweak. That's the structural move here: object-oriented inheritance applied not to software, but to agent harnesses — the executable code wrapping a language model that specifies its prompts, tools, and control flow. The committed claim: a single global harness (the recipe-card-for-everything approach) is fundamentally limited for heterogeneous agent tasks, and an OO-style class hierarchy of specialized harnesses — evolved automatically during training and selected by a learned router at inference — can beat monolithic and prior optimization approaches by up to 15 absolute percentage points. This is not a new model architecture or a new training procedure for the LLM itself. It's a meta-optimization of the scaffolding around the model. The architecture is evolutionary search over code. An "evolution agent" (itself an LLM) examines execution traces — where the base harness succeeded and failed — and proposes new subclass harnesses that inherit from the base or from each other, overriding specific methods. This is literal OOP: Python classes with inheritance and method overriding, not a metaphor. During training, you accumulate a family tree of harness classes. At test time, a "harness router" (trained on routing lessons from the evolution phase) picks the right harness for each incoming task. The key structural choice is inheritance over flat specialization: new harnesses don't start from scratch, they extend what already works. The ladder comparison is the important part. The paper evaluates on three long-horizon benchmarks: WorkArena (business workflows), GAIA (workspace tasks), and BFCL (tool use). The base harness is their starting point; the best competing method appears to be prompt optimization baselines. OO-Harness claims up to 15% absolute improvement over the base across these benchmarks. What the abstract does NOT tell you is how this compares to the current best reported numbers on these exact benchmarks by other groups — the comparison appears to be against the authors' own base and selected optimization methods, not necessarily the global SOTA leaderboard entries. This matters. The integrity picture is mixed in the ways typical of agent-benchmark papers. The benchmarks themselves (WorkArena, GAIA, BFCL) are recognized community benchmarks, which is good. But the validation is same-team: the authors designed the evolution framework, ran it, and evaluated it. There's no indication of pre-registration or held-out benchmark selection. The ablation studies (examining contributions of core components) are a positive sign — they at least try to isolate what's load-bearing. But we're still in the regime where the people building the system are grading its homework. The milestone question is where to look next. The paper demonstrates the approach on three benchmarks with 15% headroom over base. The natural next number is: does this hold when the base harness is already strong? If your starting harness achieves 80%+ on a benchmark, does OO-Harness still find 15 points? Or does the gain compress to 2-3 points? The real unlock would be demonstrating that OO-Harness scales with task heterogeneity — that as the task distribution gets messier (real enterprise workflows, not curated benchmarks), the hierarchy grows deeper and the gains widen rather than plateau. The obvious experiment not run: applying OO-Harness to the strongest publicly available agent systems (e.g., those topping the GAIA leaderboard) rather than the authors' own base harness. The honest read is probably (a) — integrating into another group's codebase is engineering-heavy and the paper already had enough moving parts — but possibility (c) is also plausible: keeping the strongest-base-plus-OO-Harness result for a follow-up that would be a leaderboard-topping submission.