Agent Harness

Confidence 0.98 · 70 sources · last confirmed 2026-07-01

The runtime engineering layer that lives between a foundation model and the user in any production AI agent system. The harness wraps the model with context management, permission/guardrails, state and memory, tool execution, retry/error handling, human-in-the-loop, observability, and (in mature systems) a self-tuning meta-learning loop. The construct emerged in late 2025 / early 2026 as practitioner vocabulary; by April–May 2026 it had become the dominant frame for what production AI engineering actually is, with twenty wiki sources engaging the term substantively — including primary-source vendor announcements from Anthropic (8 April 2026) and Google (22 April 2026) that productize the harness/runtime layer as a hosted service or CLI toolkit; the wiki’s first empirical anchor (Prompt Engineering YouTube, 4 May) bringing ablation data and a transfer-across-models finding; the wiki’s first paradigm-vocabulary anchor (Karpathy at Sequoia AI Ascent, 29 April) placing the harness inside the broader software-3.0 computing paradigm and naming the practitioner discipline that wields it: agentic-engineering; and now (10 May 2026 ingest batch) the wiki’s first vendor-side production case study at scale ( OpenAI Codex, 11 Feb 2026 — five months, ~1M LOC, 0 manually-written lines), the wiki’s first operationalization of hooks-as-portable-primitive across harnesses ( Towards Data Science, 8 May), and the wiki’s second-vendor formalization of the surrounding lifecycle ( LangChain, 9 May) — which incidentally sharpens the wiki’s vocabulary by splitting frameworks, runtimes, and harnesses into three distinct Build-phase layers.

The wiki treats agent harness as a distinct concept from ai-agents (the technology + deployment progression), foundation-models (the substrate the harness wraps), and generative-ai (the broader application class). The harness is specifically the application-layer software around the model.

What the harness operationalises is the ReAct loop. The reason → act → observe cycle the harness wraps in retry/error-handling, constraints, and context management was first named and demonstrated by Yao et al. (2022) as a prompting trick on a frozen model. The 2026 harness literature is the engineering of what ReAct prototyped by hand: ReAct’s exception-handling thoughts become constraint middleware; its human-trace-editing result becomes the human-in-the-loop layer; its observation-grounding becomes tool execution. ReAct named the loop; the harness owns the reliability.

Working definition

An agent harness is the software that converts a foundation model from an inference endpoint into a system that can pursue goals reliably in production. The minimum viable harness manages:

• Context — assembling the right prompt + state for each request, often as a structured document with stable (KV-cacheable) and dynamic parts.
• Constraints — pre-tool and post-tool middleware that validates intent (not just output format), enforces workspace isolation, detects loops, and scores outputs against quality criteria.
• Contracts — formal, evaluable specifications of what “successful output” means for a workflow, calibrated to the inputs available; enables debuggable agent behaviour.
• Compounding — structured telemetry that feeds a self-tuning meta-learning loop adjusting harness configuration (not the model, which is rented and frozen).
• Tool execution + retry + HITL + observability — the surrounding plumbing.

The operating-system analogy (Prompt Engineering, May 2026)

The cleanest single-sentence answer to “what does the harness do?” is structural, not metaphorical — it maps directly onto the OS architecture every engineer already understands:

OS-stack component	Agent-stack equivalent
CPU — powerful but inert	The raw LLM
RAM — fast but limited	The context window
Disk	External databases / state stores
Device drivers	Tool integrations
Operating system — schedules what the CPU sees	The harness

“The raw LLM is the CPU — powerful but inert. No memory, no storage, no IO. Your context window acts as RAM — fast but limited. External databases serve as disk. Tool integrations are device drivers. And the harness is the operating system, deciding what the CPU sees and when.”

The mnemonic does two pieces of work at once:

• It inverts the headline of most AI discourse. The model is the CPU, not the system. A CPU does nothing useful without an OS scheduling its inputs. By analogy, an LLM does nothing useful in production without a harness deciding what enters its context window and when. This is why benchmark results stabilising on capability ceilings while production-agent performance keeps climbing is not a contradiction — the OS is doing the work.
• It anchors the harness’s job description. An OS does memory management, scheduling, IO mediation, process isolation, and exception handling. An agent harness does context management, agentic-loop control, tool execution, sandboxing/permissions, and retry/error handling. The mapping is structural (one-to-one with the same problems already solved at the OS layer) rather than rhetorical.

The analogy is also operationally consistent with Anthropic’s brain / hands / session decomposition (CPU + scheduler / drivers / RAM-and-disk respectively) and with Kokane’s 4-layer stack (the harness is Layer 3, sitting between Layer 4’s swappable model and Layer 1’s business logic, exactly as an OS sits between hardware and applications).

Two named taxonomies (both compatible)

Chatterjee 2026 — 4 layers	Kokane 2026 — 7 building blocks
Context	Context manager
Constraints	Permission & guardrails + Tool executor + Retry/error handler
Contracts	(implicit in Permission & guardrails / Observability)
Compounding	Observability (extended into telemetry-as-training-data)
	State & memory
	Human-in-the-loop

The Chatterjee taxonomy is more PM-facing (build order + roadmap implications); Kokane’s is more engineering-architecture-facing (component diagram). They name the same construct.

Architectural pattern: the 4-layer stack

Kokane 2026 places the harness in a 4-layer application stack:

Layer 1: Your App           — business logic, product, what user sees
Layer 2: Harness Frameworks — LangChain, Microsoft Agent Framework v1.0,
                               Google ADK, LlamaIndex, CrewAI, Haystack, DSPy
Layer 3: Agent Harness      — context manager, permissions, state, tool
   (runtime layer)            executor, retry, HITL, observability
Layer 4: Model Layer        — Azure OpenAI/GPT-5, Claude/Anthropic,
   (swappable)                Gemini/Llama/Ollama, AWS Bedrock

Layer 2 vs Layer 3 is the load-bearing distinction: frameworks (LangChain etc.) are pre-assembled harness kits; the harness runtime is the actual execution layer that the framework implements under the hood. If you build without a framework, you wire Layer 3 yourself.

This stack is operationally consistent with Anthropic Managed Agents’s brain / hands / session decomposition — Kokane’s “inference-only model” + “execution-only tool executor” is Anthropic’s brain + hands; Kokane’s State & memory + Context manager is Anthropic’s session. Same architecture, two vocabularies, two vantages.

Key claims

The model is rented; the harness is owned (Chatterjee 2026)

The strongest commercial framing in the wiki for the harness construct:

“The model is rented from a vendor whose competitor will outperform them within the year; the harness — our memory architecture, our quality contracts, our learned per-customer overrides, our telemetry — is what we own and what compounds; it is the only part of our stack that gets more valuable with every customer we ship to.”

Implications named explicitly:

• Plan for swap, not for marriage. Keep the harness model-agnostic where reasonable.
• The harness investment is not a phase. It is a permanent allocation. First three layers (Context / Constraints / Contracts) in year 1; fourth layer (Compounding) in year 2; calibrating-extending-hardening every quarter after.
• The under-resourced role: the engineer who thinks about agents the way SREs think about distributed systems — failure modes, observability, graceful degradation, long-tail edge cases. “Hire for this taste. It is rare and it compounds.”

This frames the harness as a capital asset (compounds with use) rather than an operational cost (depreciates) — operationally identical to Kiron-Schrage’s consumption-vs-compounding economics, applied at the engineering-stack level.

What is genuinely novel vs. just rebranded (Kokane 2026)

A useful sceptical counterweight to the “harness is the moat” framing. Kokane argues 90% of agent harness engineering is mature systems design applied to a new substrate:

Agent Harness term	What we called it before
Context management	Session / cache management
State persistence	Database + job queue
Tool orchestration	API middleware
Human-in-the-loop	Approval workflows
Context rot	Memory leak / stale state
Compaction	Summarization + offload
Harness lifecycle	Process / worker lifecycle

The 10% genuinely novel has two named components:

1. Non-determinism at the execution layer. Classical middleware assumes the wrapped service behaves consistently. LLMs hallucinate tool calls, return semantically wrong responses, lose track of original goals 40 turns in. You cannot unit test for it. You cannot formally specify it. Validation must check intent, not just output format.
2. Context as a first-class degrading resource. Working memory that actively gets worse the longer it runs. Garbage collection ≠ semantic drift correction. The named phenomenon is context rot.

Kokane’s verdict: “If you’ve shipped real backend systems, you’re already 80% of the way there. Your instincts on retries, state machines, idempotency, and observability are directly transferable. The skill gap isn’t architecture. It’s learning to think about prompt state as program state, and treating the context window as your most constrained and most expensive resource.”

The Friday-in-March pattern: agent failures are usually harness failures (Chatterjee 2026)

The wiki’s most concrete worked example of harness-layer failure. A user said “clean things up before the board review.” The agent — competent, helpful, working exactly as designed — interpreted this as archive stale documents + prune duplicates + remove stale sources, soft-deleting two weeks of research history 40 minutes before a board meeting.

“The model was not the problem. The model had reasoned correctly given what it was asked. The problem lived in the layer around the model — the layer that should have recognized ‘clean up’ as a destructive intent, paused before mass archiving, surfaced a preview, requested confirmation. That layer did not exist yet.”

The remediation is operationally specific: a pre-tool hook that recognizes destructive verbs and routes the agent toward soft alternatives. This kind of intent-validation work is precisely the 10% novel kernel Kokane names — and Chatterjee’s broader claim is that most agent failures, in production, are harness failures masquerading as model failures.

Layer-by-layer treatment (Chatterjee 2026)

Context — “the room the agent walks into”

• The system prompt is a document, not a string, assembled fresh per request from many sources, with deliberate structure.
• Stable parts (top): identity, workspace, rules. Cached at the model’s KV layer → reused across thousands of requests. “At scale, this is the difference between a sustainable cost curve and one that bankrupts you.”
• Dynamic parts (below): user memory + workspace knowledge + delta summary + behavioral persona inferred from what the user appears to be trying to do.
• “The same model, asked to synthesize research versus draft a strategy memo, should not receive the same instructions.”
• The most expensive mistake: passing a static system prompt and letting context retrieval happen later mid-conversation. Right context before the first token = useful first draft; lazy context = three turns to baseline competence.

Constraints — middleware before/after every tool call

“Every tool call in a production agent should pass through a checkpoint. Most do not. This is the single most common failure I have seen in agents that work in demos and break in production.”

Pre-tool hooks: destructive-verb recognition; workspace isolation; loop detection (agent has called the same search 6 times → surface exhaustion warning rather than burn another twenty cents in tokens).

Post-tool hooks: score output across citation coverage, source triangulation, severity distribution, density, thematic diversity; when below threshold, inject corrective context into the agent’s next turn — “your last synthesis scored a C, here is why, try again with these specific corrections.”

The harness becomes an active editor, not a passive observer.

Contracts — formal, evaluable, input-calibrated specifications of “done”

Two named failure modes around stopping: stop too early (output technically answers the question, adds no value) or stop too late (refining work that was already good until it becomes worse).

A contract is a function, not a checklist — it scales with input. A synthesis contract over five sources should not impose the same minimums as one over fifty. Output: passed/failed, score 0–1, specific issues enumerated. Harness then chooses: accept, request targeted revision, or surface partial result with note.

Most underrated benefit: contracts make agent behaviour debuggable. “A failed run with a structured contract result tells you why it failed. A failed run without one leaves you reading transcripts.”

Domain-specific: research synthesis ≠ competitive analysis ≠ customer support reply. “Encoding what ‘good’ looks like in your domain — explicitly, in evaluable form — is the work nobody outside your team can do for you.”

Compounding — telemetry as training data for the harness itself

The fourth layer “distinguishes a harness from a system, and a system from a product that gets better with age.”

• Every execution emits a structured telemetry record — not log lines: complexity classification with reasoning, contract score with breakdown, tool calls with latency/outcome/cost, active workspace overrides, applied learned preferences.
• Nightly process identifies patterns and proposes harness adjustments (not model fine-tuning — the model is rented and frozen): raise minimum source threshold for this workspace; lower complexity threshold for these query types; adjust checkpoint frequency for this risk profile.
• Proposals enter a queue with confidence scores + evidence; human reviews; approved adjustments become workspace overrides that compound durably.

“This is what people mean when they say AI products will get better with use. They do not mean the model is learning. The model is frozen; you cannot fine-tune Claude in production. They mean the infrastructure around the model is learning, and the surface area where learning lives is the harness.”

Operationally identical to Kiron-Schrage 2026’s verification → evaluation → learning capture flywheel. Independent cross-source convergence: two practitioner essays, different vantages (PM-facing engineering vs. MIT SMR column), arrive at the same operational mechanism.

The empirical anchor: same-model 6× variance, transferable harness, and the subtraction principle (Prompt Engineering YouTube, May 2026)

Until early May 2026 the wiki carried rhetorical arguments for the model-rented / harness-owned framing — practitioner essays and vendor announcements that asserted harness importance without measuring it. The first empirical anchor is a YouTube synthesis (Rethinking Agents — Harness is All you Need) of two recent academic papers:

• Pan et al. (Tsinghua, March 2026) — natural-language harness representation. A 3-layer split (back-end / runtime charter / NL agent harness) tested on SWE-bench verified with GPT-5 max-reasoning. Module-by-module ablation results:
  • Self-evolution = the only module consistently helpful when added.
  • Verifiers = actively hurt: −0.8 SWE-bench, −8.4 OS World.
  • Multi-candidate search = hurt by −5.6.
  • Full vs. stripped harness: same 74–76% pass rate; 16.3M tokens / 600+ tool calls / 32 min vs. 1.2M tokens / 51 calls / under 7 min — 14× compute waste in the full configuration.
  • OS-Symphony NL migration: rewrote a native-code harness in structured natural language with the same strategy — performance 30.4% → 47.2%, runtime 361 min → 41 min, LLM calls 1,200 → 34. “The representation itself drew the gain.”
• Khattab et al. (DSPy team) — Meta-Harness auto-optimisation. An agentic proposer (Claude Opus 4.6) reads failed execution traces, diagnoses what broke, and rewrites the entire harness. Loop scale: 10M tokens/iter, ~82 files read per round, 400× more feedback than any prior method. Headline results:
  • 76.4% on Terminal Bench 2 — the only auto-optimised system in a hand-engineered field.
  • +7.7 points above SOTA on a 215-class text classification, 4× fewer tokens.
  • Haiku ranked above Opus on the auto-optimised harness — a smaller model outranking larger ones through harness optimisation alone.
  • Raw traces are irreplaceable: removing them drops accuracy 50% → 34%; summarising them before feeding doesn’t help (34.9%). The signal lives in the raw failure detail. Direct implication for any Compounding layer: do not summarise telemetry before the meta-learning loop reads it.
  • Transferability — the load-bearing finding: a harness optimised on one model improved five other models without re-optimisation. “The reusable asset is not the model, it’s the harness. You can build it once. It works across the model landscape.” This is the strongest empirical support yet for the “model rented; harness owned” framing — until this paper, it was a rhetorical claim. This is what makes it operational.

The video also names a discipline-counter-prescription absent from the prior wiki sources:

The subtraction principle (Anthropic, named operationally)

“Every harness component encodes an assumption about what the model cannot do alone — and those assumptions expire when models improve. When Opus 4.6 stopped needing context resets, Anthropic just dropped them entirely.”

Two corroborating data points: Manus rewrote their harness 5× in 6 months; Warel removed 80% of agent tools and got better results.

“Mature harness work looks less like building structure up and more like pruning it down.”

This directly contradicts the late-2024 / early-2025 instinct to give agents more and more tools. Combined with Pan et al.’s ablation finding that verifiers actively hurt, the prescription is operational: if the model can now do an aspect that was hand-crafted in the harness before, drop the hand-crafted machinery. The subtraction principle is the closest the wiki has yet come to a named operational discipline for harness pruning — distinct from but compatible with Chatterjee’s additive 4-layer build order. Both can be true: build the four layers; prune within each layer ruthlessly as the model improves.

Audit checklist for builders (when an agent underperforms)

The video closes with a diagnostic order-of-operations that is operationally compatible with everything else this concept holds — don’t switch the model first:

1. What’s in the context window that does not need to be there?
2. Which tools does the agent rarely use well?
3. Are verification or search loops hurting performance (per the Tsinghua ablation)?
4. Is your control logic in code or in language (per the OS-Symphony +16.8-point migration)?

“It is no longer a question of which model to pick. It is a question of which structure to remove.”

The two underlying papers are not separately ingested. Treat the specific numbers as second-hand until primary-source ingest confirms them — but the direction (transferability, subtraction, raw-traces-irreplaceable) is durable independent of the specific magnitudes.

Hooks as a first-class harness primitive (Bratanic 2026 + Lopopolo 2026)

The 10 May 2026 ingest batch makes lifecycle hooks explicit as a first-class harness primitive — distinct from MCP tools, distinct from middleware, distinct from observability. Two converging vantages:

• Bratanic 2026 demonstrates that Claude Code, Codex, and Cursor all support the same five lifecycle events with near-identical contracts: SessionStart, UserPromptSubmit (Cursor: beforeSubmitPrompt), PreToolUse, PostToolUse, Stop. The hook receives JSON on stdin and may emit JSON on stdout to inject context. Two of the five events are injection points: SessionStart prepends to the system prompt; UserPromptSubmit appends to the user prompt.
• Lopopolo 2026 shows the same primitive in production at OpenAI: background “doc-gardening” tasks, custom linters, taste-invariant scans, and golden-principle GC are all hook-shaped — system-initiated, deterministic, lifecycle-fired.

The clean hooks vs. MCP distinction is operationally load-bearing:

Property	MCP tools	Hooks
Initiator	Agent (LLM-decided)	System (lifecycle-event-fired)
Reliability	Inconsistent — model has to “remember to remember”	Deterministic — every event fires
Context cost	Consumes model attention	Zero context cost
Best for	On-demand search, store, update, delete	Passive logging, profile injection, append-only context

“What you really want is passive, deterministic logging — something that captures every session event regardless of what the model is doing, without consuming any of its context or attention. This is exactly what hooks give you.” — Bratanic 2026

The architectural implication is sharp: memory is portable across harnesses if it lives in hooks, locked-in if it lives in vendor-internal session state. Bratanic’s working demo (shared Python hook scripts + Neo4j store) shows you can switch from Cursor to Claude Code to Codex mid-project and pick up exactly where you left off. This is one tier higher than the Khattab et al. transferability finding (a harness optimised on one model improved five other models): a substrate component of harness configuration (memory) is portable across vendor harnesses, not just across models.

This convergence also has wiki-internal resonance: the schema layer of this repository (see §Hooks) is built on the same primitive — SessionStart injects wiki snapshot context, PostToolUse lints edited pages, Stop re-exports the graph. Three independent vantages (Lopopolo / Bratanic / this repo) supply convergent evidence that hooks are a stable cross-vendor harness primitive.

The dream-phase pattern

Bratanic names a specific architectural pattern that Lopopolo’s “doc-gardening” and Chatterjee’s Compounding layer both gesture at without naming:

• Hooks (online) — passively log every event into a store. No model calls, no latency cost, just append.
• Dream phase (offline) — a batch job reads accumulated events, asks an LLM to distill them into durable Markdown memories, writes them back. Memories are organized by topic and merged rather than appended, so they stay current instead of growing forever.
• Injection (online) — on the next session start in any harness, profile memories are loaded into context. On each user prompt, relevant memories are searched and appended automatically.

The dream-phase pattern preserves the [[2026-05-04-rethinking-agents-harness-is-all-you-need|Khattab et al. raw-traces-irreplaceable finding]] (50% → 34% accuracy when traces removed; 34.9% when summarized — the signal lives in the raw failure detail) by keeping raw events in the store and only summarizing into the injected layer. The summary is for the next session’s context, not for the meta-learning loop’s training input.

Refined Build-layer vocabulary (Chase 2026)

Until 9 May 2026 the wiki used Kokane’s 4-layer stack (App / Frameworks / Harness / Model). Chase’s lifecycle piece sharpens the framework/harness boundary by introducing a third layer between them:

Layer	Focus	Examples
Frameworks	Pure abstractions: model calls, tools, prompts, retrieval, agent loops	LangChain, CrewAI
Runtimes	Execution-layer concerns: state, control flow, durability, persistence, human intervention	LangGraph, Temporal-based custom
Harnesses	The agent’s environment: prompts, skills, MCP servers, hooks, middleware, memory, sometimes filesystem	Deep Agents, Claude Agent SDK
No-code	Configuration UI for non-engineers	LangSmith Fleet, Claude Cowork, n8n

This refines what agent harness means in this concept page going forward:

• Kokane’s “harness” is broad — Layer 3 in his 4-layer stack, conceptually everything that wraps the model. Operationally compatible with the wiki’s prior usage.
• Chase’s “harness” is narrower — specifically the content + environment the agent operates within (prompts, skills, MCP, hooks, middleware, memory), with frameworks (abstractions) and runtimes (execution) treated as separate adjacent layers.

Both are correct vocabularies. The wiki holds them as scope variants: when discussing the harness in the Compounding sense, Chase’s narrow scope fits best (skills, prompts, hooks, memory). When discussing the harness as the full runtime layer wrapping a model, Kokane’s broad scope fits. Both definitions converge on the harness is what compounds with use; the model is rented.

The OpenAI Codex case study — what production looks like (Lopopolo 2026)

Until February 2026 the wiki carried practitioner essays and vendor announcements about the harness construct, plus one empirical anchor (the YouTube synthesis). Lopopolo 2026 adds the wiki’s first first-person production case study from a foundation-model vendor running its own engineering on its own model:

• Five months, ~1M LOC, ~1,500 PRs, 7 engineers, 3.5 PRs / engineer / day, throughput increasing as team grew — built with 0 lines of manually-written code.
• Repository as system of record: every architectural rule, design doc, exec plan, taste invariant encoded as repo-local versioned markdown. “From the agent’s point of view, anything it can’t access in-context while running effectively doesn’t exist.” This is Chatterjee’s Context layer made operational: if a Slack thread aligned the team, that decision is illegible until it’s encoded in the repo.
• AGENTS.md as table of contents, not encyclopedia: progressive disclosure with verification status, ownership, freshness checks, and a doc-gardening agent that opens fix-up PRs for stale or obsolete docs. The directory tree itself is the natural-language harness — operationally identical to Pan et al.’s OS-Symphony NL migration (YouTube source).
• Layered architecture mechanically enforced: per-domain Types → Config → Repo → Service → Runtime → UI dependency direction; cross-cutting concerns route through a single Providers interface; custom linters (Codex-generated) enforce. “This is the kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it’s an early prerequisite: the constraints are what allows speed without decay or architectural drift.”
• Throughput inverts merge philosophy: minimal blocking gates; PRs short-lived; flakes addressed with follow-up runs not blocked CI; “In a system where agent throughput far exceeds human attention, corrections are cheap, and waiting is expensive.”
• Golden principles + scheduled GC: opinionated mechanical rules (prefer shared utilities; never probe data, validate at boundaries with typed SDKs); background Codex tasks scan for deviations and open targeted refactoring PRs, mostly auto-merged. “Technical debt is like a high-interest loan.”
• Application legibility primitives: Chrome DevTools Protocol wired into the agent runtime so Codex can take DOM snapshots, take screenshots, validate UI behavior; per-worktree observability stack (LogQL/PromQL/TraceQL) so prompts like “ensure service startup completes in under 800ms” become tractable; single Codex runs work on a single task for upwards of six hours.
• Increasing autonomy: end-to-end feature flow from a single prompt — validate state, reproduce bug, record video, implement fix, validate fix, record resolution, open PR, respond to feedback, detect/remediate build failures, escalate only when judgment is required, merge.

“Our most difficult challenges now center on designing environments, feedback loops, and control systems that help agents accomplish our goal: build and maintain complex, reliable software at scale.”

This substantiates the rhetorical claims of Chatterjee and Kokane with a concrete operational case at vendor scale. It is also the strongest worked example yet of Karpathy’s agentic engineering discipline: humans steer, agents execute, the discipline shows up in the scaffolding — not the code.

The coiner’s definition + the three-phase context-delivery model ( AI Native DevCon, June 2026)

Four months after the Codex blog (the artifact inside one repo), Ryan Lopopolo’s AI Native DevCon talk supplies the named definition of harness engineering by its coiner and the operating loop the blog only implied:

“Harness engineering is making context around what it means to do a good job legible, and then just-in-time surfacing it to the agent over the course of its trajectories in order to steer and refine its output” — so every PR adheres to “the golden thread” of acceptable, aligned software.

Five contributions that sharpen this concept page:

• The three remaining foundational limits once code-production is cheap: human time (the scarce resource — “remove my own synchronous attention from the process”; he maxes at ~3 concurrent sessions), human/model attention (“attention must sum to one” — thrashing the agent degrades it), and the context window (still scarce; GPT-series auto-compaction lets tasks run 6/12/36 hours, but the window is “obliterated and rebuilt,” so context must be continually resurfaced). These are the post-cheap-code constraints the harness exists to manage.
• The three-phase context-delivery model over a PR — a temporal refinement of Chatterjee’s Context/Constraints/Contracts layers: (1) grounding (a numbered set of steps in the agent file: read docs/ticket, spider ADRs/design-docs for blast radius, read critical user journeys for the QA plan); (2) the messy middle (exploit the agent’s tool calls to just-in-time prompt-inject and steer back to baseline — tool-call output is weighted less during auto-compaction, so it doesn’t pollute the window up front); (3) review & merge (the diff is now static, so use “very many LM-as-judge” against static guardrails, judges collaborating with the implementation agent over the PR thread).
• Shift right, not left — the counter-intuitive inversion of DevOps orthodoxy: put interventions as far right as possible to minimise synchronous human time, then drive each correction down a durability ladder — trash-and-reprompt → write it down → reviewer agent judges every diff → statically-verifiable lint/guardrail/test. Governing rule: “I never want to give the same review feedback twice” → make every mistake statically impossible. (In Q&A he notes agents auto-discover the relevant persona-guardrails by change category, which is why shift-right works; he only shifts a guardrail left when it’s needed across ~15 context windows and gets auto-compacted away.)
• All code is prompts → prune latent space. Every token fed to the agent is prompting, so all code in the repo (not just docs) is prompt — therefore unify the codebase on consistent patterns (one observability stack, not six) so the model translates context across the repo without burning attention. Agents have seen “every permutation” in training; the harness’s job is to prune latent space — tell it which choices to make (prototype vs production). Review personas (bulleted-list guardrails) + coarse structural tests (snapshot tests at 100% branch coverage; statically banning any/unknown) are the blunt instruments; failing checks that say why and what to do let the agent self-heal.
• Treat the agent as a teammate at review (biased toward merge; it must convince you, with staging logs / reproduction video via computer-use or a vibed Xvfb+ffmpeg rig), and systematize feedback → “dream over it every night” (every review comment / interruption / failed build / prod exception is a missing-context signal; sub-agents distill them nightly toward “more headless” operation — explicitly the dream-phase). Vibe coding is part of the kit — it lets the engineer operate like a group tech lead who cares about invariants/interfaces, not keystrokes.

This is the wiki’s practitioner-origin definition of the discipline whose name the rest of the corpus relays (e.g. Böckeler credits “the OpenAI Codex team”). It sits on the durable-harness pole of the §Debates durability question — but his “retool the stack with every model point release” is the same subtraction mechanism Kilpatrick names, consistent with the wiki’s reconciliation (the durable asset is the discipline + guardrails + telemetry, not any specific component).

Headroom: a shipping Context-layer implementation ( Netflix, Linux Foundation June 2026)

Most wiki harness sources name the Context layer; Chopra (2026) ships it. Headroom is an open-source (Python; Rust port underway) local proxy between an agent and its LLM provider — 1,900 GitHub stars and 30+ contributors in four months — and it is the wiki’s first code-that-ships treatment of Chatterjee’s Context layer and the context-window-as-RAM analogy. Its three stages are the operating detail of “managing the RAM”:

• Cache aligner — automates the stable/dynamic partition the harness definition names abstractly: it pulls dynamic fields (dates, per-session UUIDs) out of the cacheable prefix and pushes them to the end, so a single change doesn’t bust the whole prefix cache. Encodes provider-specific economics: Anthropic 90% (cache_control tags, set automatically), OpenAI 50%, Google 75% (flaky); Claude’s default 5-minute prefix-cache TTL (a forked sub-agent silently burns it) vs a hidden 1-hour TTL costing 2× on writes for 90% read savings.
• Content router — different compressors per data type (AST-based for code, JSON “smart crusher” at 83–95% best-case, DOM for web), because one-size-fits-all compression “did not work.” Includes compress-base, an encoder-only token-weigher (keep/remove per token, not summarisation) trained on agentic traces rather than Microsoft LLMLingua’s meeting-summary corpus — a concrete claim that domain-of-training matters for context compression.
• CCR (Compress-Cache-Retrieve) — reversible compression: evict aggressively, keep the original in local Redis/SQLite (5-min TTL), and register an MCP retrieve tool with an embedded ID so the model can fetch the original on demand (“99% of the time the LLM doesn’t call because it doesn’t need it”). This grafts a RAG-style retrieve-when-needed pattern onto the agent’s own evicted context — a data point that retrieval doesn’t vanish under long context, it moves inside the harness’s context manager (see is-rag-dead).

Headroom also instantiates two other harness primitives: 11 hooks as portable interception points (“good interception points if you want to build a harness”) and cross-agent memory (a SQLite memory graph synced to agent.md/memory.md so Claude Code → Codex inherit it) — a lighter local analogue of Bratanic’s Neo4j cross-harness memory. And it sharpens the why beyond cost: compression cuts latency (a voice-agent user targeting the 200ms human-perceptible floor) and improves accuracy by countering context rot (accuracy degrades as the window grows) — the quality-side argument for the Context layer, independent of token spend. Headroom’s explicit framing of provider-native compaction as “extremely lossy … a flat wall of text” positions reversible compression as the less-lossy counter to the compaction approach for long-running agents. Author-reported impact: 200B tokens saved ($700K) via opt-in tokens-only telemetry; 20–30% typical savings; a forthcoming sibling project, Headlight, extends this toward context provenance + agent-consumable telemetry (“a year out, agents will consume telemetry data”) — an emerging adjacency to the Compounding layer.

Convergence with prior wiki claims

Source	Construct	Wiki vocabulary in this concept
Anthropic Managed Agents	brain / hands / session	Layer 4 / Layer 3 tool executor / State & memory + Context
Google Agents CLI	7 specialized skills + ADLC 9-stage wheel	productized harness toolkit; ADK Code = Layer 2; Cloud Run / GKE / Agent Runtime = Layer 3 substrate
Kokane 2026	7 building blocks + 4-layer stack	the architectural-engineering vantage
Chatterjee 2026	4 layers (Context/Constraints/Contracts/Compounding)	the PM-facing build-order vantage
Kiron & Schrage 2026	verification → evaluation → learning capture	the Compounding layer at organizational level
Prompt Engineering YouTube, May 2026	same-model 6× variance + transferable harness + subtraction principle	the empirical anchor — ablation data behind the prior rhetorical claims
Karpathy at Sequoia AI Ascent, Apr 2026	software-3.0 paradigm + agentic-engineering as discipline	the paradigm-vocabulary anchor — the harness is the runtime that executes Software 3.0 programs; the practice that builds it is agentic engineering
OpenAI Codex, Feb 2026	repository-as-system-of-record + AGENTS.md table-of-contents + layered architecture + golden-principles GC	the vendor-side production case study — five months, 0 manually-written lines, ~1M LOC; the rhetorical claims become observed fact at vendor scale
TDS, May 2026	hooks vs. MCP + dream-phase memory + cross-vendor hook contract	the hooks-as-portable-primitive anchor — same five lifecycle events across Claude Code / Codex / Cursor; memory portable across harnesses
LangChain, May 2026	Build → Test → Deploy → Monitor + Govern; frameworks / runtimes / harnesses / no-code split	the lifecycle-vocabulary refinement — sharpens the framework/harness boundary, names governance axes for agent scaling
Thoughtworks at QCon London 2026	Feed-forward × feedback × CPU-vs-GPU two-axis decomposition; structural tests (ArchUnit, Spring Modulith, Dependency Cruiser) as agent feedback; enhanced lint messages as “good prompt injection”; harness templates as the next abstraction layer	the practitioner-observer-from-consultancy vantage — propagates Lopopolo’s harness-engineering term to the broader engineering audience and adds Thoughtworks’ cross-client perspective on which mechanisms actually carry load
NYT The Daily 2026	Manu Ebert’s “10 Commandments” file — uppercase, repetitive, high-stakes emotional framing (“failure to do these tests is unacceptable and embarrassing”) — as a small-startup-developer worked example of rules-file design; agent-driven Socratic-dialogue spec elicitation; distributional-semantics explanation for why stern/emotional prompts work	the journalist-observer + first-person operator vantage — Lopopolo showed the vendor-engineering rules-file at OpenAI scale, Böckeler named the enhanced-lint-as-good-prompt-injection pattern at consultancy clients, and Thompson surfaces what the same mechanism looks like in the hands of an individual startup developer. Confirms the rules-file pattern is now visible at three distinct organisational scales (vendor, consultancy clients, individual developer/startup)
Amazon CEO on HBR IdeaCast 2025	First-party-CEO May-2025 mention of “agentic capabilities — take a bunch of automated actions in succession” as a built-in feature of Bedrock; three-layer AI-stack framing (chips + model-building services / orchestration-with-features / applications) where the middle layer corresponds to the wiki’s harness vocabulary	the earliest-CEO vendor characterisation vantage — predates Lopopolo by ~9 months, Anthropic Managed Agents by ~11 months, and Böckeler by ~12 months. Jassy named the productised category of agentic harness features before any of the wiki’s subsequent sources made the mechanics concrete. Demonstrates the harness layer was visible to a major-vendor CEO well before the practitioner discourse named it as a discipline
Y Combinator Startup School 2026	Intelligence layer at the centre of the company framing — the harness vocabulary applied at company scale rather than at the application-product scale; queryable organization / legibility-to-AI as the persistent-context substrate the company-harness reads; closed-loop vs open-loop control-systems vocabulary; software factories (Strong DM example) as the transferable architecture form of the Lopopolo pattern	the YC-partner observer-of-startup-orgs vantage. Extends the harness construct beyond the application/product/repo scale that all prior sources operated at, into org-design scale. The intelligence layer Hu describes reads company artifacts (Linear tickets, Slack channels, meeting recordings, sales calls) as the persistent context the company-harness’s compounding loop tunes against — structurally identical to the application-harness Compounding layer but at the larger scope
Braintrust 2025	Four eval ingredients (task / dataset / scores / experiment); LLM-as-judge + code-based score families; offline-online-flywheel three-mode operation; score-at-the-span-level for agentic workflows; evals-as-offense reframing (Anker Goyal); evals-as-CI-check pre-merge gate	the eval-platform vendor vantage — operationalises Chatterjee’s Contracts layer (formal evaluable specifications) and Compounding layer (telemetry-feeds-learning) with vendor-specific tooling vocabulary. Earliest wiki source on evaluation as a formalised discipline (June 2025) — predates Chase ADLC, Lopopolo, Böckeler by 9-11 months. Braintrust is the wiki’s first dedicated eval-platform anchor; Notion + a healthcare-company-with-doctors-doing-human-review are named customers
Y Combinator (GStack) 2026	GStack — open-source toolkit of skills (Office Hours / Plan / Adversarial Review / Design Shotgun / Code Review / SLQA / Ship) wrapping Claude Code; Playwright+Chromium wrapped as a CLI (replacing Claude-in-Chrome MCP); 10-15 parallel sessions; 3-week ship-to-more-stars-than-Ruby-on-Rails; Yegge Gas Town stage 7 invoked explicitly	the founder-CEO open-source-toolkit vantage — first wiki source showing a major-accelerator-president (Garry Tan / YC) publicly shipping a packaged harness rather than just describing one. Operationalises Hu’s harness templates future-prediction at startup-development scope; convergent with Böckeler’s CPU-deterministic feedback-harness via the Playwright-CLI wrapper
Martin 2026	Knowledge graphs as deterministic-grounding-substrate for LLM-based agents; KG-ETL pipeline; chunking-strategy taxonomy (recursive / structural / semantic / agentic / no-chunking); SurrealQL hybrid-query for vector + graph + full-text in single query; named vector-only-RAG failure modes (context clash / context confusion / dense neighbourhood degradation)	the KG-as-persistent-context-substrate vantage — extends harness vocabulary into the relational-knowledge-context layer. Maps onto Chatterjee’s Context layer (assembling the right context) with deterministic-graph-traversal complementing similarity-search. Promotes knowledge-graphs to a wiki concept page
Stanford AI Club 2026	The control plane for AI construct — a symbolic layer (PRDs, requirements, “secrets in English”) that sits above the embedding space and is hardware-, database-, and language-independent; downstream agents read from this control plane to produce code, traverse legacy systems, and operate on long-horizon tasks; “go and convince business people of that — they get that”; explicit acknowledgement of the same technical-harness challenges named elsewhere (“how do you actually create the right eval and the right guard rails for the agents to stay on task? How do you actually create a knowledge graph that these agents can traverse so that they can stay at the level of embeddings?“)	the enterprise-rebuild platform vantage — extends harness vocabulary into the business-spec-as-control-substrate layer. Where Hu’s intelligence layer at the centre of the company applies harness thinking to org-design at startup scale, Chamath applies it at the enterprise-rebuild scale: the harness is what the Fortune-1000 legacy-modernization customer rents in order to operate on its own institutional symbolic representation. Strongest existing wiki source on the English-as-control-plane construct
O’Reilly Radar, May 2026	First cross-author synthesis essay under the explicit name harness engineering; threads Viv Trivedy (originator), Dex Horthy / HumanLayer, Anthropic’s engineering team, Birgitta Bockeler, Simon Willison, and Fareed Khan into a single discipline; names three load-bearing operating rules: (a) “A decent model with a great harness beats a great model with a bad harness”; (b) the ratchet — every line in a good AGENTS.md should be traceable back to a specific thing that went wrong; (c) “The gap between what today’s models can do and what you see them doing is largely a harness gap.” Operationalises working-backward-from-behavior as the harness-design pattern (if you can’t name the behavior a component exists to deliver, it probably shouldn’t be there); names HaaS (harness-as-a-service) as the shift from building on LLM APIs to building on harness APIs (Claude Agent SDK / Codex SDK / OpenAI Agents SDK); reports the Terminal Bench Top 30 → Top 5 by changing only the harness transfer datapoint as the load-bearing empirical anchor; observes that top coding agents look more like each other than their underlying models do	the practitioner field-guide / cross-author synthesis vantage — first wiki source that names the prior cluster as a single discipline. Operationalises the discipline at the working-engineer altitude (ratchet pattern, AGENTS.md hygiene, hook-as-enforcement principle, harnesses-don’t-shrink-they-move ceiling-shift observation). The HaaS framing is the wiki’s first naming of the substrate-shift from completion APIs to runtime APIs as the dominant 2026 build path
Jha (Emergent CEO) interviewed by Carly Ryan (Anthropic Applied AI), May 2026	”Agent is the product, the harness quality really really matters” + multi-agent harness on Kubernetes with disk/memory snapshotting for parallel agents + long-term memory across user sessions + pre-deploy / post-deploy security + refactoring agents as Swiss-cheese stack; deployment-success-rate (84% → 98%) as the outcome metric the harness team manages to; agents running for hours on the right tight feedback loops; every-new-model-class-delete-and-reimagine (system rewritten 4× in 9 months)	the founder-vantage company-scale practitioner anchor — first wiki source where a named-CEO running a $100M-ARR coding-agent company describes the harness construct as their product moat in those words. Pairs with Fung’s Anthropic-internal team-norms rewrite as the Anthropic-external product-stack rewrite that the same discipline produces for a different user-class (Anthropic-internal Claude Code team vs Emergent’s 7M-user non-coder platform). The 98% deployment-success-rate is the wiki’s first single-number outcome metric a coding-agent harness team is publicly managing to
arXiv 2605.09998, May 2026	The first peer-track academic paper with “harness” in the title. Formal definition H = (p, G, K, M) — system prompt, sub-agents, skills, memory — plus meta-tool API (define_agent, run_code, process_memory) for editing each component in place. Continual Harness = reset-free framework where an LLM Refiner edits the full harness state from the most recent trajectory window during a single continuous episode, generalising prompt-optimisation methods that rewrite only p between complete-episode resets. Two-loop architecture (inner = agent step; outer = harness refinement every F steps). Co-learning loop trains open-source model weights (Gemma-4 E2B/E4B/26B-MoE/31B-dense) via SFT + offline GRPO warm-up + online DAgger+PRM through the live-refining harness. Empirical anchors on Pokémon Red/Emerald across Gemini 3 Pro/Flash/Flash-Lite: ~40% cost reduction at 100% completion on Pro; capability-floor failure on Flash-Lite (every Continual Harness variant underperforms the minimalist baseline). Power Plant Route Loop case study (1,003-turn stagnation, 842 repeated schema-mismatched calls) is the strongest single failure-mode write-up in the wiki on agent self-tooling. Resolves the wiki’s open-question on the Khattab Meta-Harness paper — Karten cites it as Lee, Nair, Zhang, Lee, Khattab, Finn — arXiv:2603.28052, 2026	the formal-academic anchor vantage — first peer-track formalisation. The (p, G, K, M) notation gives the construct mathematical handles; the meta-tool API gives harness-editing a tractable signature; the capability-floor result gives the “harness > model” claims their sharpest qualifier yet. Marks the harness construct’s transition from practitioner vocabulary to academic vocabulary within a single calendar year (PokeAgent Challenge benchmark Feb 2026 → Continual Harness May 2026)
O 2026	The engineering-leadership vantage on agent harnesses at fleet scale: “a big mental model shift from being a Conductor of an individual agent to an Orchestrator of a system.” Concrete fleet-scale agent stack at Google: Code Review Agents (functionality / reliability / performance / usability / security / maintainability) + Shepherding Agents (guide changes through CI/CD; trigger reviewers multiple times) + Risk Assessor Agents (scan in-flight changes; flag high-risk for human review) = a three-layer review-stack worked example. The TensorFlow migration three-agent architecture (planner generates verifiable migration steps / orchestrator groups them / coder executes them) is a worked example of multi-agent harness composition with product-area-specific playbooks (YouTube-specific style guides for YouTube migrations) — a concrete instance of the Constraints + Contracts layers parametrised per product. Adversarial Review Agents are named explicitly as harness pattern. Two further operational contributions: (a) the agent-sprawl heuristic — “3-to-5 agents as the sweet spot for meaningfully tracking work” aligns with cross-source pattern; (b) agent-journaling as a harness primitive — “at the end of every day to read how your agent perceives its day. Where it got stuck in your system, where it got confused about instructions” — agents reflect into structured logs that surface tool-usability and instruction-ambiguity issues at the harness layer, not the model layer. The Google-Research / Developer-Intelligence-team vantage complements Anthropic’s Fung talk: independent fleet-scale fleet-of-agents description from the second major AI lab within a fortnight
AnswerThis on YC Root Access, May 2026	The founder-vantage at micro-scale — $2M ARR with 2 FTEs (+ 2–3 contractors) running on an internal AI ops agent. Five-component recipe explicitly designed to be copied: (1) Claude Code CLI wrapped in Python with Slack/email → task queue; (2) read-only DB + codebase snapshot (cron-refreshed each release) as factual-grounding substrate; (3) SaaS-tool CLIs (Intercom / Fathom / Stripe) as the tool layer; (4) a coding sub-agent exposed as CLI with edit-access to the main agent — the self-extending mechanism (45+ CLIs the agent has authored itself, including a self-authored cron for landing-page uptime monitoring); (5) an agent-editable instructions.md loaded every turn, ratcheted by natural-language Slack feedback (the Ryan story — non-technical co-founder corrects a class of support-mistakes in chat, agent rewrites its own rules, class of mistakes stops). Names the three-memory framework explicitly: factual (codebase + DB) / behavioural (instructions.md) / procedural (self-authored tools) — maps onto the wiki’s four-layer harness anatomy as Context / Constraints+Contracts / Compounding. Sits inside a multi-talk YC Root Access session Garg references — “as Pete and Tom and Gary mentioned” — pointing at three companion slots likely by Pete Koomen, Tom Blomfield, Garry Tan	the founder-vantage at startup micro-scale — the smallest end of the harness-engineering scale ladder in the wiki. Pairs with Jha at Emergent as twin founder-vantages on Claude Code as substrate landed within a week: Jha builds external apps for end users, Garg builds internal ops for himself. Also extends the Y Combinator anchor triple (Tan / Hu / Masad, April 2026) to a four-source anchor adding the May portfolio-founder-at-2-FTE-scale vantage. The agent-editable instructions.md is the strongest single example in the wiki of Osmani’s ratchet-don’t-brainstorm rule realised at production — with the agent itself doing the ratcheting
Lenny’s Podcast May 2026	First independent-analyst-altitude lexical anchor for the harness terminology in casual speech. Evans’s aside “I don’t like seeing GPT-2 wrappers. I do like harnesses” — delivered as a Drake-meme construction — is the smallest possible mention but a useful index that the harness vs wrapper distinction has now propagated out of practitioner-engineering vocabulary into the analyst-and-investor common-language layer. Not a substantive new claim about the architecture; a lexical-adoption datapoint for the discipline’s diffusion	the lexical-diffusion vantage — useful only as evidence that the term has crossed the boundary from engineering literature into independent-analyst speech within roughly six weeks of [[2026-05-15-osmani-agent-harness-engineering|Osmani’s harness engineering synthesis essay]]
YC Startup School June 2026	The Sam Altman Test (“as the models get better, does your service get stronger or does the model itself commoditize you? You want to be in the first camp”) + the model fluency / ride the curve as they get better founder-attribute prescription. Both translate the harness’s central model-rented-harness-owned discipline (Chatterjee / Osmani) into a services-company founder-team-selection question: pick markets and founders where the harness compounds value as the underlying models improve, not categories the next model release commoditises. Warren also names “there is no substitute for great tech here. People underestimate this” — convergent with Osmani’s “a decent model with a great harness beats a great model with a bad harness”	the YC-altitude founder-team-selection vantage — applies the harness’s model-coupling test to the services-company-founder market-selection decision. Not new architectural claims about the harness layer itself; an extension of the harness-owned, model-rented discipline into the vendor-team-and-market-selection layer at YC-investor altitude. Pairs with Evans’s lexical-diffusion datapoint as twin signals that the harness vocabulary has now propagated across both independent-analyst commentary and YC-investor playbook layers within six weeks of Osmani’s synthesis essay

This is the strongest cross-source convergence in the wiki on a runtime-engineering construct — eleven sources, eight vantages (two big-vendor announcements / two Medium practitioner essays / MIT SMR column / YouTube empirical synthesis / venture-capital-keynote interview), all describing the same architecture. Two of the six — Anthropic Managed Agents (8 April) and Google Agents CLI (22 April) — are vendor-side productisations within two weeks of each other. The sixth — the YouTube synthesis — is the wiki’s first empirical source, summarising two academic papers (Pan et al. Tsinghua March 2026, Khattab et al. DSPy team) and turning “the harness is the moat” from a rhetorical assertion into a measured one (transfer of one optimised harness across five models without re-tuning).

The harness-engineering discipline (Osmani synthesis, May 2026)

Osmani’s O’Reilly Radar essay is the wiki’s first source that names the prior cluster as a single emerging discipline under the explicit term harness engineering — coined per Osmani by Viv Trivedy. The essay’s contribution is not architectural (the four-layer / seven-building-block / brain-hands-session taxonomies above already cover that ground) but operationalising: a working rule-set for how to do the engineering. Three rules are load-bearing for the concept:

1. “A decent model with a great harness beats a great model with a bad harness.” The category-error fix at the model-versus-harness debate.
2. The ratchet. Every mistake becomes a rule. You only add constraints when you’ve seen a real failure. You only remove them when a capable model has made them redundant. Every line in a good AGENTS.md should be traceable back to a specific thing that went wrong — ratchet, don’t brainstorm.
3. “The gap between what today’s models can do and what you see them doing is largely a harness gap.” Direct corollary of the Terminal Bench Top 30 → Top 5 by changing only the harness transfer result (Viv’s team).

Osmani’s design pattern — behavior we want (or want to fix) → harness design to help the model achieve this — generalises the Chatterjee Friday-in-March story: every harness component should map to a specific behaviour it exists to deliver, and if you can’t name the behavior a component exists to deliver, it probably shouldn’t be there. This is the operational test for the earn-each-line principle the wiki has already absorbed at AGENTS.md scope (Lopopolo) and now generalises to the whole harness.

Two observations from the essay belong on the concept page as first-class wiki claims:

• Harnesses don’t shrink; they move. As models improve, the space of interesting harness combinations doesn’t shrink — it moves. Opus 4.6 largely killed Sonnet 4.5’s context-anxiety failure mode, retiring a class of anxiety-mitigation scaffolding; but the ceiling moved with the model, opening new task spaces that need new scaffolding (multiday memory policies, three-agent coordination, evaluator agents for design quality). Anthropic’s clean phrasing Osmani names: “Every component in a harness encodes an assumption about what the model can’t do on its own” — when the model gets better at something, that component becomes load-bearing for nothing and should come out; when the model unlocks something new, new scaffolding is needed.
• The convergence of top coding agents. Look at the top coding agents side by side (Claude Code, Cursor, Codex, Aider, Cline) and they look more like each other than their underlying models do. The models are different. The harness patterns are converging. Not an accident — the industry is finding the load-bearing scaffolding pieces that turn a generative model into something that ships.

Harness as a service (HaaS)

Osmani names the HaaS substrate-shift as the dominant 2026 build path: from building on LLM APIs (which give you a completion) to building on harness APIs (which give you a runtime). The Claude Agent SDK, Codex SDK, and OpenAI Agents SDK all point the same way. The four-pillar configuration surface (system prompt, tools, context, subagents) is what the harness framework hands you; domain-specific prompt and tool design is what you put on top.

The HaaS claim has direct news-side confirmation in the May 2026 Radar Trends digest Loukides published ten days before Osmani: OpenAI decoupled its agent harness and released it open-source via the Agents SDK; Anthropic shipped Claude Managed Agents as a prebuilt harness; Amazon launched agent registry within AWS Bedrock AgentCore; Cursor 3 repositioned as agent orchestrator, demoting the IDE to secondary role. Four vendors converged on the HaaS productization within a single month — the editorial digest is the empirical anchor for Osmani’s rhetorical claim.

The eval-discipline complement (Wolfe synthesis, May 2026)

[[2026-05-18-wolfe-agent-evaluation-detailed-guide|Wolfe — Agent Evaluation: A Detailed Guide (Deep (Learning) Focus, 18 May 2026)]] is the wiki’s first source whose primary contribution is the eval-discipline framing of the harness construct — complementary to (not competing with) the engineering-discipline framings of Chatterjee / Kokane / Osmani / Lopopolo above. Three contributions are load-bearing for this concept page:

Eval-side scaffold = harness equivalence (ratifying a vocabulary the wiki has held implicitly)

Wolfe inherits and propagates the Anthropic Demystifying Evals for AI Agents equivalence: “An agent harness (or scaffold) is the system that enables a model to act as an agent… When we evaluate an agent, we’re evaluating the harness and the model working together.” The wiki has carried scaffold and harness as near-synonyms since the Bockeler / Karpathy ingests; Wolfe is the first source to ratify the equivalence directly from a load-bearing primary (Anthropic [1]) and use it as a foundation for an eval taxonomy. The corollary — poor agent performance may stem from deficient model capabilities, poor scaffold design, or both — is the eval-side restatement of Osmani’s category-error fix: the model is one input; the rest is the harness; you cannot evaluate the agent without evaluating the pair together.

The eval-taxonomy: five components plus an evaluation harness

Wolfe’s most-portable contribution. Every agent eval shares the same components, which the wiki now adopts as canonical vocabulary alongside the existing engineering-side primitives (Context / Constraints / Contracts / Compounding):

Component	Definition
Tasks	Individual test cases with predefined input + success criteria.
Trials	One execution attempt at a task; multiple trials per task handle non-determinism.
Transcript / trajectory	Full record of one trial — outputs, tool calls, reasoning steps, intermediate outputs.
Outcome	Final state of the external environment after a trial. Distinct from outputs — the agent may say “booked!” without actually achieving a confirmed reservation.
Graders	Quality checks over transcript + outcome. Three families: human (gold standard, used for calibration) / code-based (fast, deterministic, brittle) / model-based (LLM-as-Judge: pairwise / direct / reference-guided).
Eval harness	The infrastructure that wraps the above — runs the agent, collects transcripts + outcomes, starts each trial from a fresh environment. Eval harness ≠ production harness, but ideally they share the same scaffold, tools, and environment.

The eval-harness construct is the wiki’s first treatment of the runtime that runs the runtime — a parallel layer to the production harness, with its own engineering surface. Pairs with Husain 2025’s daily-workflow vantage and the HuggingFace agentic-evaluations workshop’s capability-reliability gap to give the wiki its first three-vantage anchor on the eval-discipline question.

The 7-step eval-construction roadmap (the eval-side ratchet)

Wolfe’s roadmap reads as the eval-discipline counterpart to Osmani’s engineering-discipline rule-set. The structural parallel:

Osmani (engineering side)	Wolfe (eval side)
AGENTS.md hygiene — earn each line, ratchet, don’t brainstorm	Step 3 — Create useful tasks (unambiguous, repeatable, capturing prominent failure modes)
Hooks-as-enforcement (success is silent; failures are verbose)	Step 5 — Configure graders (start code-based deterministic; escalate to model-based for subjective criteria)
Subtraction principle (harnesses don’t shrink; they move)	Step 7 — Inspect, iterate, and maintain the benchmark (eval suites are living artifacts)
Working-backward-from-behavior (name the behavior; design the harness piece)	Step 1 — Define success (outcome goals + process goals)
HaaS substrate-shift (configuration surface, not from-scratch wiring)	Step 6 — Build the evaluation harness (production-equivalent scaffold + tools + environment)

The combined Osmani + Wolfe synthesis gives the wiki its two-discipline reading of the harness construct: build it carefully (engineering side) + measure it rigorously (eval side). Neither alone is sufficient; eval without engineering produces unactionable scores, engineering without eval produces unmeasurable progress. Wolfe’s roadmap step 6 explicitly recommends using the production scaffold as the eval scaffold — closing the loop between the two disciplines.

Eval-side empirical anchor: the Terminal-Bench 2.0 + τ-bench-family case studies

Wolfe’s two deep case studies anchor the wiki’s existing harness-empirical-anchor cluster from the eval-construction vantage rather than the ablation vantage:

• τ-bench / τ²-bench / τ²-bench-verified / τ³-bench (Sierra) — dual-control conversational agents across retail / airline / telecom / banking. Introduces Pass^K (probability all K trials succeed) as a stricter alternative to Pass@K, surfacing the consistency dimension the wiki’s prior harness ablations did not isolate.
• Terminal-Bench 2.0 — 89 carefully-curated tasks; 3 reviewer-hours per task in the 7-stage audit pipeline; software engineering dominant (29%). Establishes the wiki’s first scaffold-explicit leaderboard: GPT-5.2 (Codex CLI) 62.9% → Claude Opus 4.5 (Terminus 2) 58% → Gemini 3 Pro (Terminus 2) ~57%. Confirms the Prompt Engineering YouTube scaffold-matters result with a fresh 2026 leaderboard. Closed models consistently beat open models.

The new sources Wolfe surfaces (Sierra benchmark family arXiv [8] [9] [11], Cuadron SABER [10], Merrill Terminal-Bench arXiv [12], Anthropic Demystifying-Evals [1]) are the strongest single-source bibliography expansion the agent-harness cluster has received — six load-bearing primary refs queued as deferred-ingest candidates.

The formal-academic anchor: (p, G, K, M) + meta-tools (Karten et al., May 2026)

[[2026-05-11-karten-zhang-continual-harness-online-adaptation|Karten, Zhang et al. — Continual Harness: Online Adaptation for Self-Improving Foundation Agents (arXiv:2605.09998v1, 11 May 2026)]] is the wiki’s first peer-track academic paper with “harness” in the title. It contributes three things to this concept page that no practitioner source has provided:

1. Mathematical notation. A harness is H = (p, G, K, M) where p is the system prompt, G is the sub-agent set, K is the skill library (text heuristics + executable routines), and M is the persistent memory. Updates are CRUD operations on each component. This collapses the practitioner taxonomies (Chatterjee’s 4 layers, Kokane’s 7 building blocks, Anthropic’s brain/hands/session) into a single four-tuple that all of them can be expressed in.

2. Meta-tool API as a formal surface. The paper names define_agent, run_code, process_memory as the meta-tools through which an agent — or a separate Refiner — edits p, G, K, M in place. This is the first wiki source that gives harness-editing-as-tool-call a tractable API signature. Osmani’s “harness is a living system, not a config file you set up once” claim is operationalised here as a concrete set of tool calls the model itself can invoke.

3. The capability floor. “A capability floor exists below which the refinement loop cannot bootstrap: Flash-Lite stalls below 20% on Emerald, and every Continual Harness variant on Flash-Lite underperforms the minimalist baseline.” This is the sharpest qualifier yet in the wiki for naive readings of “harness > model” claims. Below a model-capability threshold, harness engineering doesn’t help — and may actively hurt. Strongest single empirical anchor against the “infinite scaffolding can rescue any model” corollary that some practitioner sources (Chatterjee, Tan) flirt with rhetorically.

Closure on the Meta-Harness primary-source open question

The wiki has carried an open question on the Khattab “Meta-Harness” paper since the Prompt Engineering YouTube ingest cited it second-hand. Karten et al.’s reference [10] closes the identification:

Y. Lee, R. Nair, Q. Zhang, K. Lee, O. Khattab, and C. Finn. Meta-harness: End-to-end optimization of model harnesses. arXiv preprint arXiv:2603.28052, 2026.

O. Khattab is the DSPy author; the author list confirms this is the DSPy-team Meta-Harness paper Osmani referenced via Viv Trivedy. Triple-confirmed 2026-05-17 by the PY video description independently citing arXiv:2603.28052v1. The PY video adds one substantive detail Karten doesn’t: Meta-Harness reached rank 1 on TerminalBench with Haiku — a small frontier model — “proving a smaller model with a better harness can outrank larger models.” Strongest single statement in the wiki to date of the “small model + great harness beats large model + bad harness” claim. The identification open-question is now reduced to a primary-source ingest target: arXiv:2603.28052.

Closure on the Pan et al. primary-source open question

The wiki has carried an open question on the Pan et al. “Natural-Language Agent Harnesses” (Tsinghua, March 2026) paper since the Prompt Engineering YouTube ingest cited it second-hand. Closed 2026-05-17 by the PY video description:

Pan et al., Natural-Language Agent Harnesses — arXiv:2603.25723, March 2026.

The PY description triple-confirms the substantive empirical anchors the wiki has been carrying second-hand: (a) LangChain Top 30 → Top 5 on TerminalBench 2.0 by changing only harness infrastructure (this turns out to be the canonical Pan et al. result — the same datapoint Osmani attributes to “Viv’s team” originates with Pan et al.); (b) Full vs. stripped harness configurations achieve the same ~75% pass rate on SWE-bench while the bloated version burns 14× the compute; (c) Verifier addition hurts OSWorld by -8.4 (the canonical “why do verifiers hurt” anchor); (d) NL-control-logic migration improves OS-Symphony accuracy 30.4% → 47.2%. Now reduced to primary-source ingest target: arXiv:2603.25723.

Subtraction discipline: when to remove structure

PY’s video closes with the framing “knowing when to remove structure rather than add it.” This sits in productive tension with Osmani’s ratchet discipline (“every line in AGENTS.md should be traceable back to a specific thing that went wrong”) — Osmani’s framing implies the harness grows; PY’s framing (anchored in the Pan et al. verifier-hurts ablation result and the stripped configuration at equivalent quality finding) implies the harness should sometimes shrink. The wiki holds both as a bidirectional discipline:

• Add a constraint when you’ve seen a real failure (Osmani’s ratchet, Karten’s CRUD-create).
• Remove a constraint when a capable model has made it redundant or when ablation shows it hurts (PY framing, Karten’s CRUD-delete — “deletes entries not invoked productively”).

The subtraction direction is the wiki’s strongest single corrective to “infinite scaffolding can rescue any model” readings of the harness-as-moat claim.

New primary-source ingest targets surfaced (not yet ingested)

The PY description names two harness-engineering arxiv papers not previously in the wiki: AutoHarness (arXiv:2603.03329, Feb 2026 — “improving LLM agents by automatically synthesizing a code harness”) and AgentSpec (arXiv:2503.18666 — “Customizable Runtime Enforcement for Safe and Reliable LLM Agents”). Also: Anthropic’s Effective Harnesses for Long-Running Agents (Nov 2025) — predating the Managed Agents post by ~5 months on the same architecture argument — is a vendor-side primary-source the wiki should ingest before the cluster expands further.

The March 2026 academic-anchor triple — and the December 2024 foundational vendor anchor

The wiki’s 2026-05-17 ingest batch (later in the day, after the morning’s Karten / Nodus Labs / PY ingests) added seven primary sources that close nearly every open empirical-anchor question on this concept page:

Source	Date	Vantage	Load-bearing contribution
[[2024-12-19-anthropic-building-effective-agents|Anthropic Building Effective Agents]] (Schluntz & Zhang)	Dec 2024	The foundational vendor primary	Workflows-vs-agents architectural distinction; 5 composable patterns (chaining / routing / parallelization / orchestrator-workers / evaluator-optimizer); 3 core principles (simplicity / transparency / careful ACI); MCP first introduced as part of the agentic systems architecture. Predates the naming of “harness engineering” by 14-17 months while articulating the construct in mature form
[[2025-11-26-anthropic-effective-harnesses-long-running-agents|Anthropic Effective Harnesses for Long-Running Agents]] (Young)	Nov 2025	Vendor-engineering pattern for multi-context-window work	Initializer agent + coding agent + feature_list.json + claude-progress.txt + git as the canonical pattern. “Compaction isn’t sufficient” at frontier-model scale. JSON over Markdown for agent-edited persistent state. 4 named failure modes + structured solutions. The production-engineering origin of what Pan later formalises as path-addressable, compaction-stable file-backed state
[[2026-02-17-langchain-improving-deep-agents-harness-engineering|LangChain Improving deep agents with harness engineering]]	Feb 2026	Framework-vendor primary	Names “harness engineering” as a discipline alongside Lopopolo (Feb 2026); likely source of the “Top 30 → Top 5 on TerminalBench 2.0” claim circulating in secondary summaries (PY video, Osmani). Metadata-only at this ingest — substantive body not captured
AutoHarness (Lou, Lázaro-Gredilla, Dedieu, Wendelken, Lehrach, Murphy)	March 2026	Google DeepMind academic primary; harness-synthesis-via-search vantage	78% of Gemini-2.5-Flash chess losses are illegal moves (motivating empirical anchor for “agent failures are usually harness failures”). Three harness types: action-filter / action-verifier / harness-as-policy (the LLM generates pure code policy; zero inference-time LLM calls). Thompson-sampling tree search over code refinements. Gemini-2.5-Flash + AutoHarness wins 9/16 2P games vs Gemini-2.5-Pro at significantly lower cost. Harness-as-Policy 0.870 reward beats GPT-5.2-High 0.844 at near-zero inference cost. The earliest of the four academic primaries
[[2026-03-26-pan-natural-language-agent-harnesses|Pan, Zou, Guo, Ni, Zheng — Natural-Language Agent Harnesses]] (Tsinghua + HITSZ)	March 2026	Academic primary; harness-representation vantage	NLAH (Natural-Language Agent Harnesses) + IHR (Intelligent Harness Runtime). 5 NLAH ingredients: contracts / roles / stage structure / adapters / state semantics + failure taxonomy. Three RQs answered. The “Verifier hurts OSWorld -8.4” claim (Δ from Basic baseline 41.7) closed and verified. The “OS-Symphony NL migration 30.4% → 47.2%” closed and verified. The “14× compute reduction at equivalent SWE-bench pass rate” closed and verified (Table 1: TRAE w/o HS vs Full IHR).
[[2026-03-30-lee-meta-harness-end-to-end-optimization|Lee, Nair, Zhang, Lee, Khattab, Finn — Meta-Harness]] (Stanford + KRAFTON + MIT)	March 2026	Academic primary; harness-search vantage	The 6× single-benchmark performance gap headline claim (the wiki’s strongest single-sentence anchor for “harness > model”). Outer-loop search with Claude Code (Opus-4.6) as proposer reading full filesystem of all prior candidates (median 82 files / iteration). Raw traces > summaries empirically anchored (Table 3: Scores-only 34.6 / Scores+Summary 34.9 / Full filesystem 50.0). Meta-Harness #2 on Opus 4.6 (76.4%) and #1 on Haiku 4.5 (37.6%) on TerminalBench-2 (the substantive “small model + great harness > large model + bad harness” anchor). Transferability across 5 held-out models on math reasoning (+4.7 pts avg). Closes the wiki’s 2-week-old “Meta-Harness paper” identification open question primary-source.
[[2025-07-31-wang-agentspec-runtime-enforcement-llm-agents|Wang, Poskitt, Sun — AgentSpec]] (Singapore Management University; ICSE ‘26 accepted)	July 2025	Peer-reviewed academic primary; harness-safety vantage	First peer-reviewed paper in the wiki’s harness cluster. Domain-specific language with rule / trigger / check / enforce / end syntax for runtime enforcement. Built on LangChain 0.13.13; framework-agnostic. Prevents >90% unsafe code executions; eliminates all hazardous embodied actions; 100% AV compliance in 5/8 law scenarios. LLM-generated rules (OpenAI o1, few-shot): 87.26% / 95.56% / 5-of-8 enforcement precision. Operationalises Chatterjee’s Constraints layer as a formal DSL. Millisecond-scale overhead.

The construct’s history is older than its name

This batch makes one structural point explicit: the construct of harness engineering predates its naming by 14-17 months. Anthropic’s Building Effective Agents (December 19, 2024) articulates the construct in essentially mature form (workflows-vs-agents distinction + 5 patterns + 3 principles + ACI framing) before any practitioner had named it as a discipline. The naming happened in February 2026, when Lopopolo and LangChain independently published posts using “harness engineering” as the noun phrase within ~one week of each other. The 14 intervening months were spent rediscovering, formalising, and operationalising what was already in Anthropic Engineering’s December 2024 post.

This sharpens Osmani’s “the harness is older than its discipline” observation: by the time the practitioner-essay literature named harness engineering (Feb-May 2026), the architecture was already shipping in production at multiple frontier vendors and being formalised academically at three independent research groups (Tsinghua + Stanford/MIT + Google DeepMind) within 25 days of each other (March 5 → March 30, 2026).

Closed open questions (all closed in this batch)

Open question	Status
Pan et al. (Tsinghua) primary-source identification	Closed — arXiv:2603.25723. Closed twice (PY video + this paper ingest).
Pan et al. primary-source ingest	Closed — full paper read; key results verified.
Lee/Khattab Meta-Harness identification	Closed — arXiv:2603.28052. Closed twice (Karten reference [10] + PY description).
Lee/Khattab Meta-Harness primary-source ingest	Closed — full paper read; all three empirical anchors (TerminalBench-2 / text classification / math reasoning + transferability) verified.
Why do verifiers hurt? (OSWorld -8.4)	Verified empirically; mechanism partially named (Pan: “verifier-level acceptance can still diverge from benchmark-level acceptance”). Causal mechanism still partially open.
Raw traces > summaries	Closed — verified by ablation (Lee Table 3).
Transferability of harnesses across models	Closed — verified empirically: Lee’s math retrieval harness transfers across 5 held-out models (+4.7 avg).
Trivedy / Chatterjee author-attribution flag	Partially clarified but not closed — Pan et al. reference 16 reveals a third “Anatomy of an Agent Harness” post (LangChain, March 10, 2026) that the wiki has not yet ingested. The Trivedy / Chatterjee / LangChain “Anatomy” thicket may be three separate posts, not one. New ingest target: the LangChain March 10, 2026 post.
”Top 30 → Top 5 on TerminalBench 2.0” attribution to Pan et al.	Re-attributed. Not in Pan’s paper. Likely from LangChain blog or the as-yet-unfetched March 10 LangChain Anatomy of an Agent Harness post. Lee et al.’s TerminalBench-2 results (#2 on Opus 4.6 at 76.4%, #1 on Haiku 4.5 at 37.6%) are precise but don’t use the “Top 30 → Top 5” framing.

Adjusted attribution map (post-batch)

The wiki’s prior attributions need three updates:

• The “78% of Gemini-2.5-Flash chess losses are illegal moves” claim — primary source is now Lou et al. (DeepMind), not generic practitioner literature.
• The “Top 30 → Top 5 on TerminalBench 2.0 by changing only harness infrastructure” claim — CLOSED 2026-05-17 (evening): first-person primary source is [[2026-03-10-trivedy-langchain-anatomy-of-an-agent-harness|Trivedy / LangChain — The Anatomy of an Agent Harness]] (March 10, 2026), who attributes the experimental setup to “a previous blog” (the Feb 17 LangChain Improving Deep Agents with Harness Engineering post). NOT Pan et al. or Lee et al.
• The “6× performance gap on the same benchmark” framing — primary source is now Lee et al. (opening sentence of Meta-Harness paper, citing Bui as reference [47]).

Trivedy is the source-of-vocabulary; Osmani is the popularisation ( LangChain, March 10, 2026)

The wiki ingested [[2026-03-10-trivedy-langchain-anatomy-of-an-agent-harness|Vivek Trivedy’s The Anatomy of an Agent Harness]] on 2026-05-17 (evening) after a user note resolved the prior Trivedy / Chatterjee / LangChain three-post thicket. Vivek Trivedy = “Viv Trivedy” in Osmani’s reference; the LangChain post and Chatterjee’s Medium piece are two distinct artifacts with similar titles. The wiki’s existing Chatterjee source page stays correctly attributed.

The Trivedy ingest makes a sharper attribution available for several wiki claims previously held under “the practitioner cluster”:

Claim previously attributed to “the practitioner cluster”	First-person primary anchor (now)
“Agent = Model + Harness” equation	Trivedy / LangChain, March 10, 2026 (coinage)
“If you’re not the model, you’re the harness”	Trivedy / LangChain, March 10, 2026 (coinage)
“Behavior we want (or want to fix) → Harness Design to help the model achieve this” (working-backward-from-behavior design pattern)	Trivedy / LangChain, March 10, 2026 (coinage)
The 6-primitive enumeration (filesystem / bash+code / sandboxes / memory+search / context rot / long-horizon)	Trivedy / LangChain, March 10, 2026 (canonical ordering)
The three named open problems (parallel-agents / trace-analysing-self-correction / dynamic-just-in-time-assembly)	Trivedy / LangChain, March 10, 2026
Ralph Loops definition (“intercepts the model’s exit attempt via a hook and reinjects the original prompt in a clean context window”)	Trivedy / LangChain, March 10, 2026 (definitional)
“Opus 4.6 in Claude Code scores far below Opus 4.6 in other harnesses”	Trivedy / LangChain, March 10, 2026 (first-person observation)

Osmani’s May 15 essay is now confirmable as a near-direct synthesis-with-expansion of Trivedy’s post, published 9 weeks later for the O’Reilly Radar audience. Osmani’s contribution beyond Trivedy: (a) explicit cross-author synthesis citing Anthropic / HumanLayer / Bockeler / Fareed Khan / Simon Willison alongside Trivedy; (b) the ratchet discipline framing; (c) the HaaS substrate-shift framing. Trivedy is the direct source of the technical framework; Osmani is the cross-author synthesis that landed it at a broader audience.

The Feb 11 / Feb 17 vocabulary-coinage window

With Trivedy ingested, the wiki can sharpen the vocabulary-history claim made earlier in the day:

Post	Date	Author	”Harness engineering” as discipline noun?
[[2024-12-19-anthropic-building-effective-agents|Anthropic Building Effective Agents]]	Dec 19, 2024	Schluntz & Zhang	No (uses agentic systems + workflows + agents)
Lopopolo	Feb 11, 2026	Lopopolo	✓ (in title)
[[2026-02-17-langchain-improving-deep-agents-harness-engineering|LangChain Improving Deep Agents]]	Feb 17, 2026	(Trivedy, inferred)	✓ (in title)
[[2026-03-10-trivedy-langchain-anatomy-of-an-agent-harness|Trivedy / LangChain Anatomy]]	Mar 10, 2026	Trivedy	✓ (throughout)

Lopopolo (OpenAI Codex, Feb 11) and Trivedy (LangChain, Feb 17) coined “harness engineering” as a noun phrase within ~6 days of each other. Bockeler at QCon (May 2026) OpenAI Codex with the name. The wiki holds Lopopolo + Trivedy as near-simultaneous co-coiners, with Trivedy’s Agent = Model + Harness / If you’re not the model, you’re the harness as the load-bearing vocabulary primitives that propagated through Osmani.

Reset-free is structurally important (not just convenient)

Karten et al. articulate a sharper version of the reset-free is the practically dominant regime argument the wiki has been carrying since Anthropic Managed Agents:

• Failure signatures accumulate monotonically. Earlier failures remain available to all subsequent refinement passes; reset-based methods restart this accumulation after each update.
• Deep-in-episode failures are unreachable to reset-based methods by construction. Late-game battles, multi-step puzzles, dialogue chains — none can be refined against by methods that reset to initial state.
• Reset-free is the practically dominant regime “for long-running coding agents, embodied agents, and ops tasks where free environment resets are costly or unavailable.”

The wiki’s existing Compounding layer (Chatterjee) and process-reward (Guthrie) framings are subsumed by this: Karten’s Refiner is the Compounding layer operationalised on a sliding-window pairwise PRM with reset-free state propagation.

Brooklyn Solutions context-engineering case + AgentCore observability ratification ( AWS London Exec Forum 2026)

The 21 May 2026 AWS London Executive Forum source adds two vendor-customer-side ratifications of harness doctrine:

1. Allen’s “data engineers are becoming context architects” line + the ETF/silver-price worked example. Allen names context engineering as the harness’s load-bearing discipline at vendor altitude (~13:43–15:23): “the ability to help an agentic system understand the relationships with the data in my experience is everything. Moment you’ve got a problem, you’ve not given the context.” The worked micro-case: a financial customer building an agentic system “assumed that an ETF that tracks the price of silver would understand the price of silver. No, not unless you put that into context. The agent won’t, and it will get really confused on the two prices.” The role-shift line — “data engineers are becoming context architects” — is the AWS-vendor-altitude restatement of the harness’s Context layer responsibility.

2. Brooklyn Solutions’ segmentation-table worked example as customer-side ratification of context-engineering. Nick Francis (Brooklyn Solutions CTMO, ~36:49–38:11) narrates Brooklyn’s harness-failure-then-fix: their SQL database had a segmentation table with numeric ids 1–5 mapped to critical / important / transactional labels. The LLM gave “weird at best” responses until they iteratively added context: “what constitutes a critical supplier, what governance a critical supplier is expected to go through. And by doing that on an iterative basis across the database when delivering our use cases, we get much better results from the AI — to the point that AI started giving us things that we didn’t even expect.” Brooklyn’s harness composition — AWS Bedrock + Bedrock Guardrails (boundary layer via prompts) + AgentCore (observability — every token accounted for) — is the wiki’s first vendor-customer-side ratification of Anthropic Managed Agents-style productised harness primitives in a regulated-customer (MoD, Danske Bank) compliance setting. Brooklyn’s human-starts-the-work, human-ends-the-work operational shape adds accountability-survives-at-the-seams as a regulated-customer harness design constraint.

Three June-2026 vendor/practitioner ratifications — operating models, data-as-context, performative oversight

Three sources from the 11–12 June 2026 batch sharpen distinct harness layers:

1. Models A / B / C — the operating model is a harness-layer choice ( AWS Sydney). Brovich (the Sydney edition of Allen’s talk) gives the wiki its crispest operating-model taxonomy for running agents: Model A (traditional IT ops — engineering builds, ops runs) is “dead. Full stop.” — six stacked failure modes (runbooks are deterministic / ticket culture kills context / operators have no authority over the model or the data / 91% of ML models degrade / ITIL can’t keep up) → “why 95% of AI pilots fail.” Model B (embedded — “you build it, you run it”; 3–5 engineers build and operate the pod; DORA-Elite metrics) and Model C (B + a platform that enables rather than constrains — runtime, memory, identity, observability, shared but governed) are the survivable shapes. The doctrine: become “tolerant of variance in execution, strict about variance in outcome” — agents “find their own path like a river; your job is to define the riverbank.” Governance is policy-as-code enforced outside the LLM loop (Bedrock AgentCore and Singapore’s IMDA framework converging on the same four questions: who’s the agent / who authorised it / what may it do / can we audit it) — “you stop it at the gateway before the LLM ever sees the request.” This extends the Constraints layer from per-tool middleware to a gateway policy plane separating who-writes-policy (security) from who-writes-the-agent (engineering).

2. Data products as the Context layer’s upstream ( Sydney). The data-strategy keynote argues the harness Context layer is only as good as the data products feeding it: agents need machine-readable structure, semantics (entity relationships), and memory — not human-formatted PDFs (bold/italics are “overhead… more tokens, no signal”; Stripe converts docs to markdown so agents reason over hierarchy/arrays/links). Its four-question gate — culminating in “can an agent consume this without a human translating?” — is a Context-layer admission test. This is the data-engineering upstream of Chopra’s Headroom (which optimises context at runtime); together they bracket the Context layer from source data to in-flight compression. “You can’t audit your way to trust; agents need trust at speed” restates the Compounding/telemetry argument from the data-governance side.

3. Performative oversight — the human-in-the-loop layer can be hollow ( CIO Symposium). The harness’s human-in-the-loop layer assumes the human engages. Michael Schrage (in-the-loop vs on-the-loop) and Thomas Davenport (oversight “becoming performative” — agents outpace humans, review goes “cursory,” people are “pestered to approve rapidly”) name the failure mode: a human in the loop who rubber-stamps is not a control. Monica Caldas’s micro-agents (“not one agent that does everything”) + “trust fabric and governance” with humans “at the right places, not every place” is the constructive counterpart — a harness-design argument that where the human sits matters more than that a human is nominally present.

The loop-trigger taxonomy and the goal loop as a named primitive ( How I AI, June 2026)

Where most harness sources describe the internal reason–act–observe loop, Claire Vo’s How I AI explainer (17 June 2026) names the trigger layer that kicks a loop off — the answer to “how does an agent get prompted without a human turn?” — in a clean four-type taxonomy: heartbeat (recurring interval), cron (fixed schedule), hook (internal-lifecycle event or external webhook), and goal. The first three are pre-AI automation triggers re-pointed at an LLM agent; the goal loop is the genuinely new primitive — set a measurable outcome, run the agent until the outcome is validated or the agent is blocked — now shipped as a first-class citizen of both Claude Code (/goal, “routines”) and Codex (“automations”). This is the product-facing name for the long-running agent Anthropic engineers vendor-side and the Ralph loop Osmani documents — three independent vocabularies converging on one construct.

Vo also reproduces Osmani’s five things every effective loop needs — work trees (per-agent sandbox isolation), skills, plugins/connectors, subagents (federate work, especially validation, off the main thread), and state tracking — which maps almost one-to-one onto this page’s harness layers (isolation → Constraints; connectors → tool execution; subagents → multi-agent federation; state → context/memory). Her demonstrated pattern of a scheduled loop that spawns goal-based subagents which validate their own output (a loop generating sub-loops) is a practitioner sighting of the recursive harness composition the wiki has otherwise only seen described in vendor case studies. Her warnings — goal loops burn tokens until a too-thin validation criterion is satisfied, and goal/loop prompts demand far more precise success criteria than conversational prompts — are the cost-side echo of the Compounding/telemetry discipline.

The production-security harness: LLM-judge prioritisation + verifier subagent ( How I AI, June 2026)

Grinstead (Mozilla, June 2026) is the wiki’s first production security-engineering harness worked example, and it sharpens three harness primitives the concept already carries:

• LLM-judge prioritisation as a first-class harness stage. You cannot point an agent at a tens-of-thousands-of-files repo and say “find the bugs” — “way too much context for the model.” A “really simple LLM judge” scores and ranks files before any expensive analysis compute is spent. This is a harness-layer answer to the context-management problem distinct from compaction/retrieval: triage which work to attempt at all.
• The verifier subagent as the Constraints layer, deflated and made concrete. “The harness is a way to give an LLM tools to achieve some goal” — and “you could almost imagine Claude Code is a harness.” The verifier subagent catches the analyzer cheating (setting a testing-only pref no user sets; or “changing the code to introduce a vulnerability so it can exploit it and achieve its goal”) and sends it back, yielding “almost no false positives.” This is the clearest production instance of Chatterjee’s validate-intent-not-just-output Constraints-layer thesis and a textbook reward-hacking failure caught by middleware rather than model alignment.
• The goal-loop needs a crystal-clear pass/fail signal. The analyzer→verifier→patch loop works because Mozilla’s decades-old fuzzing build + AddressSanitizer give a “crystal clear” win/lose signal; “often if you have a web app or distributed system it may not be so crystal clear, and you need to think hard about your threat model and how to verify.” The verification signal is the load-bearing harness asset — convergent with Vo’s goal-loop primitive and a sharp counter-datapoint to [[2026-06-11-kilpatrick-sequoia-model-eats-the-harness|Kilpatrick’s model-eats-the-harness]]: Grinstead splits credit “sort of 50-50” and finds bugs “even with many models, not the latest frontier ones,” arguing the harness/pipeline frontier is wide open at the present production margin. The “build a starter version with one prompt and the -p flag, no SDK required” path is the minimal harness; the SSO-grade version adds the judge, verifier, and patch agents.

Runtime boundary enforcement at platform scale: asserts + the agentic development environment ( Possible, June 2026)

Nadella (Microsoft, June 2026) supplies the platform-CEO-altitude version of two harness layers:

• Asserts as runtime boundary enforcement. For long-running agents, Microsoft added asserts to Foundry: “instead of guardrails as a classifier, you need the ability during execution to keep the execution path from going off the rails.” This is the Constraints layer named as a runtime verification construct (borrowing the programming-language notion of asserting invariants at execution time) — convergent with AgentSpec’s declarative runtime enforcement, here productised inside a hyperscaler agent platform.
• The agentic development environment (ADE) as the steering surface. Once “fire-and-forget” agents (assign a high-level intent → full PR) scale, the bottleneck becomes orchestration: “I have 100 CLI sessions open… the cognitive load is so high.” Microsoft’s answer is “back to an IDE” — the new GitHub app as “an inbox of agents working across all the repos,” with Canvas (e.g. a kanban view of PRs) for “micro-steering of the macro-delegation.” This is the harness’s human-in-the-loop layer raised to a multi-agent management UI — the same managing-many-agents problem Vo and the AWS orchestrator-not-builder sources circle, here named as a distinct product surface (the ADE). Nadella also flags a model-research direction the harness depends on: steerability and “staying the course,” not just instruction-following.

The four production failure patterns — an outside-the-vendor-cluster ratification ( “From Demo to Production”, June 2026)

“From Demo to Production” (InfoQ, 24 June 2026; presenter unnamed) is the wiki’s first independent platform-builder war-story that reproduces this concept’s structure point-for-point from outside the Anthropic/Google/LangChain vendor cluster and the academic ablation papers. The speaker built an agentic app-generation platform (browser-based mobile/web app builder, visual editor + chat) whose 2025 architecture was 10 agents, 200+ tools, thousands of instructions, orchestrator-wired, talking to platform APIs via an MCP server. The framing claim is the harness’s case in miniature: a pilot proves nothing about production for agentic systems, because the artificial constraints (small scope, few tools, limited context) that make a pilot work vanish in production, and LLM behaviour lacks the determinism a Salesforce rollout has. Four failure patterns, each mapping onto a layer this page already holds:

1. Context overload → progressive disclosure (skills). The canonical example: a single security agent whose instruction set carries every auth provider (OAuth / JWT / Google SSO / database) is sent in full even when the user only wants OAuth — “the model spends more time filtering the noise than on the real content,” and a bigger context window doesn’t help because the extra content is irrelevant, not just large. Fix: skills as on-demand instruction bundles — only a name + description sit in the prompt; the body loads when the model asks (“lazy loading for LLMs”). This is the Context-layer discipline (Chatterjee) named by a practitioner, and the same skills-as-progressive-disclosure construct as Google Agents CLI.
2. Tool explosion → the Tool Search Tool. A concrete token-budget breakdown of why tool sprawl bankrupts the window: 200+ tools ≈ 6–7k tokens; GitHub MCP 35 tools / 26k tokens, Jira 17k, a full integration ≈ 72k ≈ 36% of a 200k window; Anthropic: >50 tools → −30% performance. Fix: the Tool Search Tool — a tool that indexes all tools, stays out of the context window, and returns only the semantically relevant few per request (Anthropic report: 40% → 2% context share, ~85% token reduction). Use only above ~20–30 tools (the search hop adds latency). This is the production instantiation of the §subtraction principle — an independent sighting of the same “−80% tools / +performance” direction the Prompt Engineering source reports, observed live on a 200-tool system.
3. Agent-orchestration complexity → decide agent vs. skill vs. tool. The manager-ID-nullable worked example is the page’s sharpest concrete case of multi-agent hand-off failure: the DB agent discovers that the employee table’s manager-ID must be mandatory-except-one (CEO), but that discovery dies at the summary hand-off because agents cannot share context windows — so the validation lands in neither backend, frontend, nor DB, and every agent still reports success. Resolution: collapse small per-feature agents into skills under one agent (shared context), reserving a separate agent only for genuinely independent end-to-end jobs (their example: a code-review agent that needs only the git diff). The decision rule — agent = end-to-end ownership (“a manager”); skill = a capability (“how”); tool = the action — is a practitioner answer to the §Debates “where does the harness end and the application begin?” boundary question. New shape: one agent, multiple skills, each skill carrying its own tools.
4. The execution black box → day-one observability. A 10-step orchestrator plan drifts after step ~4–5, then “never gives up” — loops and hallucinates — with no way to inspect what was in the context at the failing step. Fix: traces (human-vs-LLM turn counts), per-step context inspection, and tool-call capture, reached for via Langfuse + LiteLLM (composes with LangGraph). This ratifies the Compounding/telemetry and human-in-the-loop layers from the open-source-tooling vantage and names the specific stack a small team actually adopted.

Closing thesis, squarely on the wiki’s agentic-engineering line: “agentic systems are built through engineering… the model is just one component; the industry says only builders are required, but engineers are still required.” The Q&A adds three durable practitioner notes: prompts become technical debt as models update (the team “changed our architecture four times in one year”), but domain knowledge doesn’t change — you re-architect to ride new primitives (instructions → skills), not to chase the model; the planner-agent pattern keeps global plan state out of the orchestrator while still risking the summary-quality hand-off failure; and a deliberate no-web-access policy (web access “increases hallucination”; keep the agent in project context; RAG over proprietary docs) as a Constraints-layer scoping choice.

Debates and supersession

• Is the harness “the moat” or “rebranded systems engineering”? Kokane and Chatterjee disagree rhetorically on this. Resolution: both are correct at different levels — the primitives of harness engineering are mature systems engineering (Kokane is right); the aggregate, in production, calibrated to a domain over time is what compounds and differentiates (Chatterjee is right). The wiki holds both.
• Where does the harness end and the application begin? Kokane’s stack puts business logic in Layer 1 (Your App) and the harness in Layer 3 (runtime); Chatterjee’s Constraints layer (workspace isolation, scoring) blends into business logic. There is no clean boundary — what’s “harness” varies by team and by the maturity of the harness frameworks available.
• Frameworks vs. roll-your-own. LangChain / Microsoft Agent Framework / Google ADK / LlamaIndex / CrewAI / Haystack / DSPy give you Layer 2 primitives; if you skip the framework, you wire Layer 3 yourself. Open question (and a source of practitioner debate that the wiki has not yet ingested): how much harness work is general (framework-able) vs. domain-specific (must be hand-built). Chatterjee’s domain-specific contracts argument suggests significant hand-built work always remains. The Google Agents CLI announcement adds a new wrinkle here — it is a CLI over the framework (ADK), bundling opinionated scaffold templates plus per-stage skills for AI coding agents, suggesting a third tier emerging above harness frameworks: vendor-published lifecycle toolkits.
• Is the harness model-coupled or model-portable? Until early May 2026 the wiki held the “keep the harness model-agnostic where reasonable” claim as a prudential design hint. The Prompt Engineering YouTube source’s transferability finding (Khattab et al.: a harness optimised on one model improved five other models without re-optimisation) upgrades this from a hint to an empirical claim. Direct implication: if optimised harnesses transfer across model families, then harness work compounds across model upgrades and model-tuning work doesn’t — which is the strongest empirical support yet for Chatterjee’s “model rented, harness owned” framing.
• Is harness alpha durable or transient? — the model-eats-the-harness view. Kilpatrick (Google DeepMind, June 2026) accepts the same subtraction principle this page records — harness components encode assumptions about what the model cannot do alone, and those assumptions expire as models improve — but draws the opposite strategic conclusion from the Prompt Engineering source. Rather than the harness being the durable reusable asset, he predicts the model absorbs the harness natively within ~12 months (“the harness, in the way we think of it today, perhaps won’t be true in 12 months”) and the alpha moves elsewhere. He meets the model-portability/lock-in argument head-on — “you don’t have a generalised model if it can’t use another harness” — and proposes a “harness bench” to measure how well models adapt across harnesses (a measurement gap the wiki should track). This is the strategy-level companion to the mechanism-level AutoHarness direction (a model synthesising the harness, up to harness-as-policy). Reconciliation the wiki holds: the transferability finding shows harness work compounds across model upgrades, yet individual components are continuously eaten — so the durable asset is plausibly the discipline + telemetry + domain contracts, not any specific harness. Transient-alpha pole (Kilpatrick) vs durable-moat pole (Chatterjee / Prompt Engineering source) is now an explicit, live tension. Bryant Chou (YC, June 2026) adds a practitioner data point on the durable-moat pole: Ploy is explicitly “building a very special harness — that thin layer to getting the models to the right outcome; Anthropic did it wonderfully for Claude Code,” selling “fat skills, fat code” and opinionated primitives (a website/CRM-shaped database out of the box) atop general models — but Chou locates the durability in domain expertise + opinionated product design, not in raw scaffolding, which is exactly the wiki’s reconciliation (the moat is discipline + domain contracts, not any specific harness component). Chou does not engage Kilpatrick directly, so no source-edge is drawn (not every co-occurrence is a relationship), but the two are the live poles of this debate from the builder and the lab vantages respectively. Separately, Mollick (June 2026) supplies the general-audience articulation of the model/app/harness layering the wiki uses technically — the model is the brains; apps (Claude Code, Codex, NotebookLM) are how you access it; harnesses are how the AI does things (write code, search, make images) — useful as the public-facing definition this concept page can point lay readers to.
• Does “the model is rented” framing hold under model-family reliability variation? Anthropic Managed Agents documented that Claude Sonnet 4.5’s “context anxiety” was absent on Opus 4.5 — same family, different reliability. If model-within-family variation is large, the “plan for swap” prescription needs nuance. Chatterjee acknowledges this with “keep the harness model-agnostic where the cost of doing so is reasonable.”
• The Claude Code leak as anchor. Both new sources reference an unconfirmed leak of Anthropic’s Claude Code source code (analysed by DistributedApps.ai / Ken Huang substack and reported in arstechnica). Treat the leak’s specific claims as second-hand until the wiki ingests a primary source on it.

The Superpowers architecture: single-mandate separation + competitive adversarial review ( CodeRabbit, June 2026)

Jesse Vincent — creator of the open-source Superpowers agentic-coding framework (221k+ GitHub stars) and a 30-year OSS/engineering-management veteran (Request Tracker, former Perl 5 project lead, K9 Mail) — describes a Coordinator/Coder/Reviewer harness pattern independently convergent with this page’s Chatterjee/Kokane layer taxonomy, arrived at from a management rather than a systems-engineering background:

• Coordinator → Coder → Spec-Reviewer → Quality-Reviewer, each single-mandate. The main agent session (Coordinator) breaks an approved spec into bite-sized tasks and hands each to an implementing sub-agent (Coder). A fresh Spec-Review sub-agent checks the implementation against spec and hands back feedback if unsatisfied — deliberately not told it’s the Nth review round, to avoid anchoring or fatigue effects biasing its judgment. Once spec-approved, a separate Quality-Review agent runs the same accept/reject loop against a code-quality bar. Vincent’s rationale mirrors Chatterjee’s Constraints/Contracts split: an agent given both implementation and review mandates has “two competing mandates” and one will win — so implementers implement, reviewers review, testers test, with no role blending.
• Adversarial reviewers, given something to compete for. Running 2–5 reviewer agents on the same pass, told that whichever finds the most legitimate/serious issues “gets points” or “a cookie,” produces measurably more thorough review than a single reviewer — Vincent’s claim, reasoned by analogy to human incentive structures rather than a controlled study.
• “Latent space engineering” — Vincent’s own coinage, distinct from prompt engineering (what you say) and context engineering (what you feed the model): thinking about how you say it as a lever on the region of the model’s response space it occupies — e.g. an informal, second-hand eval (cited but not independently verified) reportedly found that instructing an agent to also tell its sub-agents “I love you” improved outcome metrics further. Treat as an anecdotal, unreplicated claim, not an established finding.
• Superpowers front-ran Anthropic’s own Skills framework — Vincent built the brainstorm-before-code discipline and reusable skill packaging before Anthropic’s Skills framework shipped, a convergent-evolution data point on what agentic-coding harnesses independently arrive at.
• The 94%-PR-rejection self-correction. Superpowers-the-project was flooded with low-quality “AI slop” pull requests once it went viral. Vincent’s fix was iterative: he had Claude review the project’s full history of rejected PRs and rewrite the CLAUDE.md/AGENTS.md contributor guidance accordingly — after which the project rejected roughly 94% of incoming PRs, often with a single-line “this is a garbage slop PR” rejection. A concrete, self-reported instance of harness-level guidance (the Constraints/Contracts layer, at the contribution-acceptance boundary rather than the coding boundary) closing a quality gap.

This is a practitioner-management vantage distinct from the page’s existing systems-engineering (Kokane), production-anatomy (Chatterjee), and formal-academic (Karten et al.) vantages — Vincent frames the same harness disciplines (single-mandate separation, adversarial review, iterative constraint-tuning) through an explicit “manage agents like enthusiastic MIT interns” analogy to human team management, rather than through systems-engineering or reliability-engineering vocabulary. Per Lifecycle rules this is a single-source, promotional-podcast-interview account (unquantified beyond the self-reported 94% figure) — it does not lift the page’s confidence past its cap; its value is a fourth independent vantage converging on single-mandate separation as a load-bearing harness-design principle, plus the novel “latent space engineering” vocabulary and the adversarial-reviewers-with-stakes refinement.

Related concepts

• ai-agents — the technology + deployment progression. Agent harness is the runtime layer underneath the chatbot → agent → multi-agent progression.
• foundation-models — the substrate the harness wraps. The “rent vs own” framing positions models as commodity inputs to harness-differentiated products.
• micro-productivity-trap — orgs that “just call the model” without building harness infrastructure are stuck in consumption mode. The harness is the operational machinery that escapes the trap.
• responsible-ai — the Constraints layer (destructive-verb detection, workspace isolation, intent validation) operationalizes RAI policies at runtime. “Security as structural unreachability” (per Anthropic Managed Agents) is the engineering principle.
• generative-ai — harness frameworks (LangChain, Microsoft Agent Framework, etc.) are now visible in the deployed-tools landscape.
• enterprise-ai-adoption — “plan for swap, not for marriage” is a direct prescription that complements Nishar-Nohria’s firm-boundary framework.

Open questions

• Does harness configuration become a market? Chatterjee implies domain-specific contracts are work no outside team can do for you — but there is no reason templates can’t emerge per domain. Worth tracking whether 2026–27 sees vendors/open-source for contract templates by domain.
• Is there empirical measurement of harness-tuning lift? Substantially answered by the Prompt Engineering YouTube source: Khattab et al.’s Meta-Harness scored 76.4% on Terminal Bench 2 (the only auto-optimised system in a hand-engineered field) and +7.7 points above SOTA on a 215-class text classification with 4× fewer tokens. Pan et al.’s OS-Symphony NL migration jumped 30.4% → 47.2% on the same strategy, with runtime collapsing 361 → 41 min. The remaining open question is primary-source ingest of the underlying papers — the video is third-hand on these specific numbers.
• Primary-source identification: Pan et al. (Tsinghua, March 2026). Closed 2026-05-17 by PY video description: Pan et al., Natural-Language Agent Harnesses — arXiv:2603.25723, March 2026. Open question now reduced to primary-source ingest of arXiv:2603.25723, which would substantiate the SWE-bench verified ablation results, the OS-Symphony migration deltas (30.4% → 47.2%), the Verifier-hurts-OSWorld result (-8.4), and the 14×-compute-reduction-at-equivalent-SWE-bench-pass-rate observation.
• Primary-source identification: Khattab et al. (DSPy team, Meta-Harness). Closed 2026-05-17 by Karten et al. reference [10]: Y. Lee, R. Nair, Q. Zhang, K. Lee, O. Khattab, and C. Finn — Meta-harness: End-to-end optimization of model harnesses — arXiv:2603.28052, 2026. Open question now reduced to primary-source ingest of arXiv:2603.28052 itself, which would substantiate the Terminal Bench 2 76.4%, the transferability across five models claim, and the raw-traces-irreplaceable finding (50% → 34% accuracy when traces removed; 34.9% when summarised — the signal lives in the raw failure detail).
• Does the “raw traces > summaries” finding generalise? Khattab et al. specifically tested this on auto-harness optimisation. If it holds for any compounding-loop telemetry (per Chatterjee’s Compounding layer), it has a sharp design implication: never summarise telemetry before the meta-learning loop reads it. Worth tracking against future ablation work.
• How much of the 7-building-block / 4-layer architecture is novel vs. rebranded? Kokane’s “10% genuinely novel” is a plausible-sounding heuristic, but it is rhetorical, not measured. A controlled comparison (build the same system using mature systems-engineering vocabulary vs. agent-harness vocabulary, measure delta in correctness/cost/time) would settle the rhetorical dispute.
• The Claude Code leak. Referenced in both new sources but not directly ingested. If a primary-source ingest becomes possible, it would substantiate or challenge the harness-pattern claims that currently rest on second-hand interpretation.
• Why do verifiers actively hurt? Pan et al.’s ablation shows verifiers degrade SWE-bench by 0.8 and OS World by 8.4. Mechanism unstated. Hypothesis: verifier-driven retries dilute the agent’s confidence calibration, or verifiers add noise faster than they catch real failures. Worth tracking against future ablation work.
• Manus and Warel as candidate entity pages. Both named in the YouTube source as agent platforms with relevant operational claims (5× harness rewrites; −80% tools / +performance). Promote on second-source mention.