AI Agent Harness: Thin vs. Thick and Model-Harness Co-evolution

Introduction: If You Are Not the Model, You Are the Harness

Teams building AI agents often encounter the same component: the harness. In this context, a harness is the runtime wrapped around a model that lets it reliably complete real tasks. It includes instruction and tool interfaces, context organization, task orchestration, result validation, and permission control.

A common claim is: “If you are not the model, you are the harness.” Yet the industry has not reached consensus on how thick a harness should be. The debate centers on one question: models are updated every few months, so will today’s carefully built scaffolding be natively learned by tomorrow’s model?

Both sides have concrete evidence.

One side argues that scaffolding is a temporary patch on model capabilities. The creator of a widely used AI coding tool said at an AI summit in 2026 that as models become stronger, the surrounding harness becomes less important. In an earlier podcast interview, this person explained that building scaffolding around a model can usually improve performance by 10%–20%, but “this gain is largely erased by the next model upgrade.” That leaves teams with two choices: keep rebuilding the scaffolding, or wait for the new model to provide the improvement for free. The team follows the core lesson of The Bitter Lesson: always bet on general model capabilities, not temporary, scenario-specific scaffolding.

The other side argues that the harness determines how much model capability is actually realized. In February 2026, an engineer from an agent development framework team wrote that their command-line coding agent rose from the top 30 to the top 5 on Terminal-Bench 2.0. The model stayed the same throughout. Task completion rate increased from 52.8% to 66.5%, and the entire 13.7-percentage-point gain came from the harness layer. The article summarized the harness mission as: “shaping the model’s innate, uneven intelligence into the shape required by the tasks we care about.” In April 2026, a co-founder of a data and agent framework proposed a more aggressive “big harness” view: the model is only a “blank slate,” and the biggest obstacle to realizing AI value is the user’s ability to engineer context and workflows. Complex business processes require complex harness design.

This article does not simply choose a side. Instead, it answers three questions:

• Why can both conclusions be true at the same time?
• Which parts of the harness are destined to be absorbed by the model, and which parts will increase in value over time?
• How should engineering teams dynamically allocate investment between them?

1. First, Disassemble the Harness: What Exists Beyond the Model

Any model output must pass through a pipeline before becoming a deliverable result. A typical harness performs at least five responsibilities:

• Interface adaptation: Wrap model capabilities into unified instructions, tool definitions, and output parsing.
• Context construction: Retrieve private data, assemble business background, compress history, and manage memory.
• Task orchestration: Decompose tasks, schedule work, retry, roll back, and recover from failures.
• Quality validation: Use tests, validators, and human review to confirm output correctness.
• Governance and control: Manage permissions, filter sensitive information, enforce cost quotas, and provide observability.

These responsibilities are technically very different. Interface adaptation and some task orchestration mainly compensate for what the model cannot yet do. Context construction mainly fills in missing information. Quality validation and governance mainly establish trust. Arguing about all five responsibilities on a single thin-versus-thick axis is one reason this debate has dragged on.

2. The Model-Side View: Why Harness Value Can Be Diluted

The core model-side argument can be summarized as “capability replacement.” Most of what the harness compensates for today is likely a model weakness. Once the weakness is filled, the scaffolding loses its reason to exist.

The thin-harness approach designs the harness as the thinnest possible wrapper around the model. After each model upgrade, it actively removes the parts the model can now handle natively.

This view relies on several testable assumptions. Only when these assumptions hold is “thin” the correct strategy:

• Assumption A: General capability improvements propagate to target tasks. Improvements in model benchmarks need to translate into higher success rates on real business tasks. However, end-to-end metrics such as task completion rate can be inflated by better tool-calling ability. A model that is better at calling tools is not necessarily better at making judgments.
• Assumption B: Gains decay faster than model iteration. Improvements from scaffolding should shrink quickly after a model upgrade. Otherwise, rebuilding once and benefiting long term may be more economical.
• Assumption C: Building and removing are equally cheap. Scaffolding can be shipped quickly and removed cleanly without accumulating technical debt in the codebase.
• Assumption D: The risk of keeping a thinner harness is manageable. Stripping away validation and permissions in pursuit of “thinness” is acceptable only under the premise that the model will keep improving reliably.

These assumptions generally hold for capability-type components. Once business information, quality validation, and governance are involved, they may no longer hold.

3. The Harness-Side View: How the Same Model Can Produce a 13.7-Point Gap

The core harness-side argument can be summarized as “distribution shaping.” When a general model faces a specific task, its capability distribution is uneven. The role of the harness is to shape that distribution so that model outputs fall into the range actually required by the task.

They also have a set of implicit assumptions:

• Assumption E: There is a structural difference between the task and the model’s training distribution. Enterprise workflows, coding standards, and business definitions are difficult to cover with general training data. This gap will not disappear as models become stronger; it may even widen as task complexity increases.
• Assumption F: Model capability has variance. The same model may show uneven reasoning depth, instruction following, and output-format stability across tasks. Structured workflows can compress this variance and make the lower bound usable.
• Assumption G: The model lacks key information required by the task. User data, process knowledge, and implicit definitions of “what counts as correct” can only be injected by the harness.

It is worth noting that the 13.7-percentage-point case changed only the harness. It shows that Assumptions E, F, and G hold for that task, but it does not prove they hold for all tasks. In open-ended question answering, for example, the harness space may be limited.

4. The Decisive Experiment: Let Data Decide

The disagreement can ultimately be reduced to one empirical question: For a given set of tasks, does the harness gain decay with model upgrades, remain stable, or even amplify?

One way to answer this is to design a “model version × harness configuration” cross-evaluation. Harness configuration should include at least thin and thick modes. The following pseudocode shows the skeleton:

# Cross-evaluation: fix the task set and iterate over model versions and harness configurations.
# Repeat each combination R times, and report the mean and variance range.
MODELS = ["model_old", "model_new"]      # old and new model generations
HARNESS = ["thin", "thick"]              # thin and thick harness configurations
TASKS = load_tasks()                     # fixed task set covering typical business scenarios
R = 5
report = {}
for m in MODELS:
    for h in HARNESS:
        runs = [evaluate(m, h, TASKS) for _ in range(R)]
        report[(m, h)] = summarize(runs)
        # Suggested metrics: task completion rate with variance range, rework rate,
        # human intervention rate, cost per task, P95 latency, and regression pass rate.
# Check whether the gain changes after model upgrades by comparing thick minus thin.
for h in HARNESS:
    delta_old = report[("model_old", h)]["pass_rate"]
    delta_new = report[("model_new", h)]["pass_rate"]
print(f"{h} configuration gain change: {delta_new - delta_old:+.1f} percentage points")

The results generally take one of three forms, corresponding to three very different strategies:

• Convergence: The thick configuration has a clear advantage on the old model, but the gap narrows on the new model or is even reversed. Assumptions A and B hold, and the team should gradually slim the harness as models upgrade. This is the case described by the thin-harness camp.
• Stability: The thick configuration maintains a stable advantage on both old and new models. This indicates that the harness supplies private information or validation outside the model’s training, which model upgrades do not directly address. It should be retained long term.
• Amplification: The thick configuration’s advantage becomes larger on the new model. This often means the model already has execution capability, and the bottleneck has shifted to context organization. The stronger the model, the greater the leverage of good context, so harness investment should increase.

5. Three Types of Harness Components and Their Lifecycles

If harness responsibilities are reclassified by “what they compensate for,” the lifecycle of each type becomes clear.

Component type	Core purpose	Typical content	Direction after model upgrades	Recommended strategy
Capability-type	Compensate for what the model cannot yet do	Hard-coded reasoning chains, format repair, tool-selection fallback, special parameter patches	Gradually absorbed by the model; gains converge	Keep it thin, pluggable, and removable; review quarterly
Information-type	Fill in private-domain knowledge the model does not have	Private data integration, business rules, terminology and definitions, domain schemas	Does not decay with model upgrades; increases with data accumulation	Structure it and keep investing
Validation-type	Define what counts as “done correctly”	Test suites, validators, regression cases, human review	Becomes more important as models produce more and faster	Build long term and expand in sync with capability upgrades

The model camp discusses capability-type components. The harness camp focuses on information-type and validation-type components. In reality, the two sides are not talking about the same harness.

This leads to a design principle: Capability-type harnesses should be thin; information-type and validation-type harnesses should be thick.

Four implementation guidelines follow:

1. Capability-type components must be removable. Manage them through feature flags, independent modules, and feature inventories. Register failure conditions for each component, meaning the assumed model version from which it can be removed.
2. Information-type components must be structured. Business rules, domain vocabulary, and interface schemas should become versionable data assets, not scattered prompt strings. Prompts are just one rendering of these assets.
3. Validation-type components must be decoupled from the model. Tests, validators, and permission rules describe the task itself, not the model’s temperament. They should be maintained independently of model versions.
4. Do not thicken the harness blindly for differentiation. The real moat is user-specific data and workflows, not scaffolding that competitors do not have.

6. Architecture Practice: A Three-Layer Harness Refactor

Following these principles, the harness can be split into three layers. Model-related parts that need frequent adaptation are confined to one layer. Stable business and validation capabilities accumulate in the other two layers. This keeps the scope of change controllable and measurable during model upgrades. The following code shows the idea:

# ---------- Layer 1: Model adaptation layer (thin): only model-version-related concerns ----------
# Use a capability profile to describe known model characteristics.
# The harness no longer hard-codes assumptions about a specific model.
CAPABILITIES = {
    "model_v1": {"native_tool_choice": False, "stable_json": False},
    "model_v2": {"native_tool_choice": True, "stable_json": True},
}
def build_model_adapter(model_id: str) -> "ModelAdapter":
    caps = CAPABILITIES[model_id]
    # Capability branches: use a temporary fallback when unsupported;
    # the branch is naturally disabled once the model supports it.
    tool_choice = "native" if caps["native_tool_choice"] else "harness_fallback"
    parser = JsonParser(strict=caps["stable_json"])
    return ModelAdapter(tool_choice=tool_choice, parser=parser, system_prompt="core_v3")
# ---------- Layer 2: Context assembly layer (thick): model-independent private knowledge ----------
def build_context(task) -> list:
    blocks = [
        load_schema(task.domain),         # domain structure definitions
        retrieve_private_docs(task),      # retrieval of private documents
        load_business_rules(task.org),    # business rules and definitions
        load_terms(task.domain),          # glossary aligning model and human terminology
    ]
    return [b.render() for b in blocks if b.relevant(task)]  # assemble on demand and control context budget
# ---------- Layer 3: Validation and governance layer (thick): define what "done correctly" means ----------
def guardrails(result, task) -> "GuardrailReport":
    report = GuardrailReport()
    report.add(run_tests(task, result))          # functional tests
    report.add(validate_schema(task, result))    # structure and definition validation
    report.add(check_permissions(task, result))  # permission boundary checks
    return report
# ---------- Orchestration: the thin layer evolves with the model; the thick layers accumulate over time ----------
def run_agent(task, model_id: str):
    adapter = build_model_adapter(model_id)      # changes with the model
    ctx = build_context(task)                    # accumulates long term
    result = adapter.invoke(ctx, tools=task.allowed_tools)
    return result if guardrails(result, task).passed else adapter.retry(result, ctx)

This three-layer split brings three direct benefits:

• The adaptation layer can safely become thinner over time. For each new model, teams only need to update the capability profile and remove fallback branches already covered by native capabilities.
• The context layer can safely become thicker over time. Business knowledge accumulates as data and configuration, so it does not become obsolete when the model changes.
• The return on investment of the validation layer becomes measurable. After each model upgrade, regression tests can be rerun to reveal behavior changes introduced by the model and measure the marginal value of the harness.

At the infrastructure level, this layered design usually also requires general cloud capabilities. Task sets and regression cases can be stored in object storage with versioning. Context construction and tool invocation can be asynchronously decoupled through message queues. Evaluation jobs can run on a container platform to enable parallelism and elastic scaling. Evaluation metrics, failure distributions, and costs can be connected to logging services and monitoring alerts, forming a continuous comparison before and after model upgrades.

7. Evolution Path: Cutting Weight and Building Muscle at the Same Time

On a real timeline, harness evolution usually involves “cutting weight” and “building muscle” in parallel. Take a coding agent as an example:

• Stage 1: The harness is forced to be thick when model capability is limited. Teams need hard-coded task decomposition templates, output repair logic, tool-selection rules, and format patches. These are mainly capability-type components and can provide a 10%–20% baseline improvement.
• Stage 2: Once the model has basic reasoning and tool-calling ability, cut weight and build muscle at the same time. On one hand, remove task decomposition templates and output repair logic. Review the system prompt once during each model upgrade, removing content now supported natively to avoid unlimited growth, because overly long prompts consume context budget and distract attention. On the other hand, solidify test-driven development workflows, domain schemas, and private data integration as the backbone of the harness.
• Stage 3: When model capability approaches or exceeds that of human developers, keep building muscle. Capability-type components are nearly zero. Value concentrates in three areas: large-scale parallel scheduling and task division; a complete validation loop including sandboxes, tests, static checks, and code review; and governance facilities such as permissions, auditing, and cost control.

This aligns with the common industry observation of coding-agent architecture evolution: the core “generate-execute-validate” loop keeps strengthening, while specific compensations for model capabilities are continuously removed.

8. Engineering Checklist: Deciding When Harness Should Be Thin or Thick

Engineering teams can use the following checklist to evaluate harness design item by item:

• Can it be removed cleanly? Capability-type components should have independent feature flags. After removal, the system should gracefully degrade to native model behavior instead of breaking.
• Can it be evaluated? Every new harness component should have a controlled experiment. Components whose value cannot be measured should not enter the mainline.
• Can it be replaced? If a prompt fragment can be replaced by “a better model plus fewer instructions,” it should go on the elimination list.
• Has it been patched repeatedly? Layers of patches added to work around a specific model defect should be the first candidates for removal after a model upgrade.
• Does it depend on private information? Components that depend on user-private data and business workflows are the foundation of long-term harness value and deserve continued investment.
• Does it define the standard for “done correctly”? Tests, validators, and permissions are part of the product promise. They should not be relaxed as models become stronger.
• Can updates keep up with the model? Teams should establish a fixed model-upgrade process, including capability profile updates, full regression evaluation, prompt review, and cost accounting.

9. Outlook: The Center of Gravity Is Shifting

Over the next period, the harness is likely to evolve in five directions:

1. From compensating for capability to compensating for information. As models become more general in reasoning and tool calling, the incremental value of the harness will concentrate on private data integration, domain knowledge modeling, and business process structuring.
2. From writing rules to writing evaluations. The only hard currency for measuring harness value is a reproducible task set and a scorer. Evaluation itself will become a core harness asset, and evaluation-driven development will become the mainstream process.
3. From monolithic scaffolding to layered architecture. The adaptation layer will become thinner and standardized, while the context and validation layers will become thicker and specialized. They will be decoupled through clear interfaces.
4. From stacking components to scheduling resources. When the cost of a single model task is low enough, harness competitiveness will be reflected in large-scale parallelism, task division, and result aggregation, exchanging more runs and more validation rounds for higher completion rates.
5. From one-off prompts to context-engineering assets. Continuously accumulated assets such as business rules, glossaries, domain schemas, and failure-mode libraries form the real long-term barrier.

In one sentence: The model determines the upper limit of agent capability; the harness determines how much of that upper limit is realized and whether the result is trustworthy. Each model upgrade should trigger a harness “health check.” Cut weight decisively for capability-type parts, keep building muscle for information-type parts, and never relax validation-type parts.

Conclusion

Thin versus thick is not a binary choice. It is the lifecycle of different harness parts. The real lesson from The Bitter Lesson is not that “the harness is useless,” but that engineering resources should not be bet on things the model will eventually learn. They should be bet on things the model cannot learn but that truly determine success or failure.

The next time someone debates whether the harness should be thin or thick, ask first: Which type of component are we discussing?