Thin vs Thick Agent Harnesses: How Much Scaffolding Does a Model Need?

Two teams run the same model on the same task. One ships reliably. The other drowns in tool-call latency, context bloat, and incidents nobody can explain from logs. The difference is rarely the model. It is where each team put the complexity.

The weak mental model treats harness thickness as a maturity level: thin harnesses are prototypes, thick harnesses are production. That framing costs teams months. Thickness is not a score. It is a location decision. Every unit of scaffolding you add moves complexity out of the model and into code you now own, test, and pay for on every request.

The invariant I defend here: put each piece of complexity on the cheapest surface that can hold it, and never let an abstraction own a decision you cannot observe.

The Axis Is Location, Not Amount

A harness is every piece of code, configuration, and execution logic that is not the model — system prompts, tool definitions, bundled infrastructure, orchestration, hooks, middleware. If you are not the model, you are the harness. That definition is assumed here; the question is not what a harness is but how responsibility should be distributed inside it.

Thin and thick are not endpoints on a quality scale. They are different distributions of the same responsibilities across four surfaces:

The real question is not "how much scaffolding" but "which surface absorbs this uncertainty, and who pays when it is wrong." This is a design axis, not a vendor taxonomy. Two harnesses with identical component counts can sit on opposite ends of it. A framework with forty tools and no state store is not thick where it matters.

Two Axes, Not One: Ownership and Sophistication

Before comparing thin and thick, separate two questions that the word "thickness" tends to blur.

Surface ownership answers: where does this guarantee live? A retry policy can live in the runtime, in a workflow step, or in the model's own loop. Ownership is categorical.

Sophistication answers: how much deterministic machinery and policy does that surface contain? A runtime can have a minimal retry primitive — one attempt, one backoff, one log line — or a thick one with circuit breakers, jittered backoff, dead-letter queues, and per-tool budgets. Both own retries. They differ in depth.

This distinction matters because the thin/thick debate is really about sophistication, not ownership. Every deployable harness needs some enforceable execution and recovery boundary. A thin harness keeps those primitives minimal. A thick harness adds deterministic orchestration, rich state management, typed registries, supervision, and layered policy.

Apply it to state. A minimal implementation: append each turn to a JSONL file, reload on restart. A thick implementation: a state store with schema versioning, crash recovery, cross-session memory, and an evaluation interface that exposes intermediate states. Same surface. Different sophistication. Different evidence produced.

Thin and thick describe how much deterministic machinery a surface carries — not whether the surface exists. A harness with no recovery boundary is not thin. It is incomplete.

What a Thin Harness Actually Owns

The thin end is not a strawman. It is a minimal runtime contract: run the model, execute tool calls, manage context, enforce a small allowlist, and persist enough state to resume. Five responsibilities, not forty.

The general-purpose tool move is what makes thin viable. Instead of pre-building a tool per endpoint, you give the model a bash or code-execution tool and let it compose its own actions. The model designs its own tools on the fly via code rather than being constrained to a fixed set of pre-configured tools. This is the single highest-leverage decision in thin harness design — and the one with the sharpest boundary, which I will return to.

Why thin wins on iteration speed: the artifact you edit is a prompt, a script, or a skill file. The cost of being wrong is a text change, not a release. When the next model drops, every skill improves because the judgment in the latent steps gets better while the deterministic steps stay reliable.

Where thin becomes too thin for the task — not a universal property of thin, but a signal you have under-built for this workload:

• No durable state across sessions, so a restart loses work
• No crash recovery, so a mid-task failure is unrecoverable
• No policy enforcement point, so an irreversible action has no gate
• No trajectory capture, so a failure cannot be reproduced

The failure signature is specific: the agent works in a demo and silently loses work when the process restarts mid-task. You will not see this in a demo. You will see it at 2 AM when a customer's half-finished workflow evaporates.

What a Thick Harness Buys, and What It Charges

Thick harnesses provide genuine capabilities. Typed tool registries with schema validation. Lifecycle hooks for auth and policy. State stores with crash recovery. Subagent spawning. Evaluation interfaces that expose trajectories and intermediate states. These are not ceremony. Systems missing lifecycle hooks cannot enforce safety policies. Systems missing evaluation interfaces cannot debug failures. Systems missing state persistence cannot recover from crashes.

But the cost curve is not linear, and this is where teams misjudge the trade.

Every tool definition and MCP server description consumes context before the agent does any work. Context rot degrades behavior before the first useful action. A harness with dozens of tool definitions can eat a large fraction of the context window before the model reasons about anything.

Round-trip latency compounds. A tool that takes seconds per call turns a ten-step task into a minute of waiting, and each hop is a new failure point. The difference between a browser operation that takes 100 milliseconds and one that takes 15 seconds is not a detail — it is the difference between an agent that feels responsive and one that feels broken.

The abstraction tax is the quiet one. When the framework owns the decision, you lose the ability to see why the agent chose a path. Every incident becomes archaeology. You have logs, but not the reasoning. You have traces, but not the context that produced them.

The anti-pattern to name explicitly: a fat harness with thin skills. Dozens of overlapping tools. God-tools that wrap whole APIs. No procedural knowledge anywhere. More tokens, more latency, more failure surface — and no skill file to fix it.

The Four-Surface Ledger: Deciding Where Complexity Lives

Turn the comparison into a repeatable placement procedure. For each capability, name the surface that owns it and the observable signal that proves it works.

Surface 1 — model. Absorb complexity here when the capability is general reasoning, planning, or self-verification that improves with model releases and you cannot maintain better yourself. Planning and long-horizon coherence are migrating into models. Do not build what the next release will absorb.

Surface 2 — runtime. Absorb it here when the requirement is mechanical and non-negotiable: persistence, sandboxing, retries, egress policy, credential scoping. The runtime is the bill nobody budgets for correctly. Most teams ship it too thin, then patch with post-hoc filters.

Surface 3 — workflow. Absorb it here when the sequence is known and the failure must be deterministic: validation gates, ordering, human approval steps. If the order matters and the model cannot be trusted to preserve it, it belongs in the workflow.

Surface 4 — tools. Absorb it here when the capability is domain-specific and the interface is stable. A scoped CLI or a typed function beats a general agent loop. Build exactly what you need.

The decision rule: if you cannot name the surface that owns a behavior, you have hidden it in an abstraction, and you will not be able to debug it.

The Same Task, Two Harnesses

Here is the placement ledger applied to a code-modification agent, then the same task traced under thin and thick control. The task: fix a failing test in a repository.

Placement:

• Sandbox and filesystem → runtime
• Test execution → tools
• Edit-verify-fix loop → model
• Merge gate → workflow

Now trace the execution. Thin version, model-directed:

[runtime]  start session, load repo into sandbox
[model]    read failing test, propose edit
[tools]    apply_patch -> ok
[tools]    run_tests -> 1 failure remaining
[model]    propose second edit
[tools]    apply_patch -> ok
[tools]    run_tests -> pass
[model]    declare done
[runtime]  session ends, no merge gate

Thick version, workflow-directed:

[runtime]  start session, load repo, attach state store
[workflow] enter state EDIT
[model]    read failing test, propose edit
[tools]    apply_patch -> ok
[workflow] transition EDIT -> VERIFY
[tools]    run_tests -> 1 failure remaining
[workflow] transition VERIFY -> EDIT (retry budget 2/3)
[model]    propose second edit
[tools]    apply_patch -> ok
[workflow] transition EDIT -> VERIFY
[tools]    run_tests -> pass
[workflow] transition VERIFY -> APPROVE
[workflow] gate: require human approval before merge
[runtime]  persist final state, emit trajectory

Inject one failure: the model declares done after the first edit, before tests pass. In the thin version, nothing catches this — the model's self-assessment is the only gate, and the session ends with a broken repo. In the thick version, the workflow never leaves VERIFY without a passing test, so the false completion is rejected by state transition, not by a prompt instruction.

That is the concrete difference. The thick harness catches a failure the thin one cannot safely guarantee, because the guarantee lives in a state machine rather than in the model's judgment.

Thickness Is a Function of Task Horizon and Blast Radius

Two variables actually move the recommendation. Everything else is taste.

Task horizon. Short, single-turn, verifiable tasks tolerate a thin harness. Long-horizon work across multiple context windows needs state, compaction, and continuation logic somewhere. Models today suffer from early stopping, decomposition failures, and incoherence as work stretches across context windows. A good harness designs around all of this — but the design can live in a skill file, not necessarily in framework code.

Blast radius. Read-only or sandboxed work tolerates a thin harness. Anything touching production data, money, or external systems needs an enforcement point that is not the model's judgment. The harness should be widest where the model is being trained and narrowest where it is being deployed. The gap between them should be a deliberate, audited engineering artifact.

Reversibility. Cheap-to-undo actions can run thin. Irreversible actions need a gate, and the gate belongs in the runtime or workflow, not in a prompt instruction. A prompt instruction is a suggestion. A runtime gate is a wall.

Respect the asymmetry: a thin harness fails loudly and cheaply. A thick harness fails quietly and expensively.

The Code-Execution Boundary

General-purpose code execution is the leverage point for thin harnesses, and it is also where thinness gets dangerous. Giving the model a shell reduces registry thickness and integration work for exploratory or sandboxed tasks. In production, the same tool expands the action surface, weakens typed observability, and complicates authorization.

The boundary is blast radius, not preference. Sandboxed, reversible, exploratory work: let the model write and run code freely. Production systems with real side effects: keep the general tool, but wrap it in scoped capabilities, resource limits, egress controls, and an auditable approval boundary. The flexibility is real. So is the expanded attack surface. Choose based on what a mistake costs, not on how elegant the demo looked.

When not to use each:

• Do not add orchestration layers for a task that a single deterministic script plus one model call already solves.
• Do not go thin on a task with irreversible side effects just because the demo looked good.

Making Thickness Observable and Reversible

The choice should not become permanent. Instrument the seams, not the model.

Log tool calls with arguments and results. Log context size per step. Log retries. Log termination reason. These signals reveal which surface is failing. If context size climbs monotonically, your context manager is not compacting. If retries cluster on one tool, that tool's interface is wrong. If termination reason is always "max steps," your workflow is missing a gate.

Build the evaluation harness as the durable asset. Tasks, environments, and success signals outlive any specific scaffold. They let you re-measure after a model or harness change. The wide training harness, the narrow production harness, and the evaluation harness that connects them should be deliberately engineered — but not mistaken for permanent product surfaces.

Treat application-facing scaffolding as replaceable. Keep the thin substrate stable and the thick conveniences isolated so a model upgrade can delete code instead of forcing a rewrite. Build the durable substrate like you mean to keep it. Build each production harness like you mean to replace it.

Migration signals that you are too thin:

• Repeated manual re-prompting
• Lost work on restart
• No way to reproduce a failure

Migration signals that you are too thick:

• Tool definitions crowding the context
• Latency dominated by round-trips
• Incidents you cannot explain from logs alone

Expect absorption. Capabilities that live in the harness today — planning, self-verification, long-horizon coherence — will migrate into models. Design the boundary to move.

The Decision Rule

For each capability in your system, write down the surface that owns it and the signal that proves it works. Anything you cannot place is hidden complexity. Hidden complexity is not a design choice. It is a future incident.

Then take one concrete action: pick your longest-horizon, highest-blast-radius task. Run the four-surface ledger against it. Move exactly one responsibility to the surface that can hold it most cheaply.

Measure the move with at least three metrics, because they can move in opposite directions:

• Outcome: task success rate on a fixed task set
• Operational: p95 step count or latency, plus token and tool cost
• Recovery: behavior after an injected interruption — does the run resume, or restart from zero?

Add a fourth if policy matters: count of gate violations blocked. The specific metrics depend on the task, but require at least one from each category. A before/after that only reports success rate will hide the cost you just added.

The adjacent concept worth studying next is how evaluation harnesses and trajectory capture turn harness thickness from an opinion into a measurement. Without that, you are guessing. With it, you are engineering.