Stop Overengineering Your Agent Harness

Hugo Bowne-Anderson · rss · 2026-07-22 source ↗ Reader 🖥️

Agent Harness Agent Tool Management Agentic AI Context Engineering Guardrails Multi-Agent Orchestration Riding Model Improvements Right-Sizing Boundaries & Primitives

Most builders should reject the coding-agent-derived harness checklist (memory, compaction, sub-agents, hooks) as a default and instead size their harness to where a given task actually falls on two independent axes — action complexity and context complexity — because harness features are provisional, encoding assumptions about model limitations that expire as models improve (the 'Kirby effect'), so the discipline is to build the minimum viable harness for the job and prune it as capability arrives.

practical · argumentative — Argumentative essay built on definitional/expository scaffolding (agent vs. LLM workflow, prompt vs. context vs. harness engineering) plus two contrasting case studies (coding/deep-research agents vs. Maven Assistant) used as evidence for a sizing prescription.

Structure

Part	Role
Opening statistical analogy ('average testicles')	context
What is an agent? (agent vs. LLM workflow)	conceptual groundwork
What is an agent harness? (five core jobs; prompt/context/harness engineering distinction)	key-term definition
The action-complexity / context-complexity framework	central analytical device
Harnesses for coding agents (loop size, context-engineering patterns, deep-research case study, OpenClaw/Pi)	evidence (high-complexity case)
The Kirby effect (CoT, Amp's plan mode, Manus/LangChain/Claude Code rebuilds)	evidence + mechanism
Harnesses for support agents (Maven Assistant case study)	evidence (low/moderate-complexity case)
Fundamentals that remain; eval-harness boundary aside (Trivedy vs. Husain)	qualification / generalization
Closing prescription (map the two axes; build minimum; revisit as models improve)	conclusion

Key terms

agent harness Agent Harness
The complete non-model software and infrastructure the LLM relies on at runtime — the 'body' to the LLM's 'brain' — covering the loop, tool execution, context management, state, and safety.
agent (vs. LLM workflow) Agentic AI
Strictly, an LLM with tools operating inside a reasoning loop that decides for itself when a task is finished; a fixed, deterministic sequence of model calls with no feedback into an earlier step is an 'LLM workflow,' not an agent.
the Kirby effect
Nicolay Gerold's coinage (relayed by the author): every harness component encodes an assumption about something the current model cannot do on its own; as models improve, that assumption expires and the component can be removed — the model absorbs the capability the way Kirby swallows an enemy's ability.
action complexity / context complexity
Two independent axes for sizing a harness: action complexity is how many tools, decisions, dependencies, and handoffs an agent must coordinate; context complexity is how much information it must gather, retain, and retrieve.
prompt engineering / context engineering / harness engineering
Three nested scopes of increasing breadth: prompt engineering shapes a single model call, context engineering determines what the model sees, harness engineering governs the complete system around those calls.
minimum viable harness
The smallest set of harness components a task's actual complexity profile demands, built incrementally only when a real observed failure requires it.

Propositions

explicitdevelopedAn AI agent, strictly defined, is an LLM with tools operating in a reasoning loop that decides for itself when a task is finished; a system running a fixed, deterministic sequence of model calls with no feedback to an earlier step is an 'LLM workflow,' not an agent, even though common parlance calls both 'agents.'conf: high
extends ←Podcast: Strands Agents with Clare Liguori · p3 — Supplies quantified accuracy data (82.5% vs. 100%) for the workflow-vs-agent distinction this proposition draws only conceptually.
refines ←Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman · p1 — Berryman's account decomposes the terser 'LLM with tools in a reasoning loop' agent definition into two explicit loops (outer message-passing / inner tool-use) — finer structure on the same definitional target, not a broadened claim; it doesn't itself address Bowne-Anderson's self-termination criterion for what distinguishes an agent from a fixed 'LLM workflow' (see g5).
explicitAn agent harness is the non-model software — the loop, tool execution, context management, state, and safety layer — that surrounds the LLM at runtime, distinct in scope from prompt engineering (a single call) and context engineering (what the model sees).conf: high
explicitHow much harness a task needs is determined by two independent variables: action complexity (tools, decisions, dependencies, handoffs to coordinate) and context complexity (information to gather, retain, retrieve) — and the two can move independently (e.g., a support agent can be action-heavy but context-light).conf: high
extendsAI Is Changing Software Engineering. The Fundamentals Still Matter. · p2 — Operationalizes the general 'right-sized primitives' thesis with a concrete two-axis rubric (action complexity x context complexity) specifically for sizing agent harnesses.
explicitCoding and deep-research agents sit high on context complexity and therefore need heavy context-management techniques (compaction, hand-off, sub-agent isolation, hooks), while most support, sales, and enterprise agents are low on at least one axis and complete tasks in one to five turns without needing that machinery.conf: high
explicitThe core reasoning loop of a functioning coding or search agent can be implemented in roughly 60-130 lines of Python, showing the underlying agentic-loop pattern stays small even as the surrounding harness that builders actively extend (AGENTS.md instructions, skills, evals) grows large.conf: high
explicit⚡ disputed & corroboratedHarness features expire as models improve because each component encodes an assumption about a model limitation that becomes false once the model absorbs the capability (the 'Kirby effect') — concretely: chain-of-thought prompting was absorbed into reasoning models trained via RL on CoT traces, and Amp removed its experimental 'plan mode' once models could reliably obey a single 'plan, don't edit' instruction.conf: high
extendsThe Anatomy of an Agent Harness · p11 — Extends the 'harness complexity should decrease as models improve' claim with a named mechanism (the Kirby effect: each component encodes an expiring assumption) plus additional concrete precedents (CoT->reasoning models, Amp's plan-mode removal).
contradictsAgent Harness Engineering · p6 — Directly conflicts with the other harness piece's claim that 'as models improve, the space of interesting harness combinations doesn't shrink — it moves to new failure modes': this essay argues harness complexity should shrink and features get removed outright as capability is absorbed.
supports ←Podcast: Strands Agents with Clare Liguori · p13 — A first-person description of living through the 'Kirby effect' (harness features expire as models absorb the capability they compensated for), including the emotional cost the essay's framing leaves out.
supports ←Head of Claude Code: What happens after coding is solved | Boris Cherny · p6 — Both describe the same mechanism — harness/scaffolding features expire because they encode an assumption about a model limitation that becomes false once the model improves — with Boris's account giving the quantified magnitude (10-20% typical gain) the other extraction's claim doesn't include.
extends ←Just Talk To It - the no-bs Way of Agentic Engineering · p1 — The other document's abstract claim that harness features expire as models improve is given concrete, first-person instances here: dropped plan-mode reliance, deleted Tailwind-4 guidance, abandoned subagents, all as GPT-5-Codex absorbed what the harness used to compensate for.
explicitMajor agent products have had to substantially rebuild their harnesses repeatedly to keep pace with model improvements: Manus was re-architected five times in a year, LangChain's Open Deep Research was rebuilt multiple times, and even Anthropic rips out Claude Code's harness as Claude improves.conf: high
supportsDon't train the model, evolve the harness · p9 — The named repeated-rebuild examples (Manus 5x, LangChain Open Deep Research, Claude Code) are concrete corroborating instances of 'evolve the harness' meaning add-and-remove to fit the current model, not monotonic growth.
explicitA production support agent (Maven Assistant, at Maven Clinic) reached single-turn resolution for essentially all initial external conversations and needed almost no memory or compaction, while still requiring domain routing to sub-agents, tools bounded per sub-agent, deterministic guardrails run before the LLM, and explicit human-handoff rules (e.g., automatic transfer on self-harm language) — i.e., low context complexity but moderate action complexity, resolved with a different harness toolkit than a coding agent's.conf: high
implicitBecause harness needs are read off a task's position on the two complexity axes rather than off its being 'an agent' at all, the coding-agent harness playbook currently dominating public discourse is a poor default for most other builders, and copying it produces over-engineered, over-costly systems for tasks that don't need it.conf: high
implicitPublic discourse about harness engineering is disproportionately generated by coding-agent and personal-agent builders even though the author states most builders will build support, sales, and enterprise agents instead — an availability-bias skew the essay names but does not explain.conf: medium
explicitWhether eval/testing infrastructure counts as part of 'the harness' is a genuinely unsettled definitional boundary among practitioners: Vivek Trivedy's account treats the harness as runtime-only, while Hamel Husain argues the eval harness belongs inside the definition too — and the author defers resolving it to a future conversation.conf: high
explicitRegardless of complexity level, a fixed set of harness fundamentals remains durable: reasoning loops with tools/state/control-flow, prompt and tool-schema design, context and memory management, structured outputs/traces for debugging, guardrails and human handoffs, using SDKs/MCP without outsourcing system design, scheduled/event-driven work via hooks, and evals covering task success, tool use, guardrails, and handoffs.conf: high
explicitcontestedBefore reaching for compaction, memory, handoffs, or sub-agents, builders should map the task on the action-complexity/context-complexity axes; if both are low, keep the harness small, add infrastructure only when a real observed failure demands it, and revisit or remove additions whenever a stronger model arrives.conf: high
contradicts ←The Anatomy of an Agent Harness · p9 — This article implies harness engineering's components are each independently justified by a model limitation and so broadly applicable; the other document argues harness complexity should be matched to a task's complexity profile first, implying much of this component list is unnecessary overhead for simpler tasks.
implicitBecause the Kirby effect makes harness components' usefulness time-bounded, engineering effort invested in a harness feature has a built-in short amortization horizon — a component built to work around today's model limitation is, by design, waste once a future model no longer needs it.conf: medium
implicitThe prescription to 'add infrastructure only when a real failure demands it' presupposes that failures reliably surface before or independent of live traffic; but the essay's own Maven Assistant anecdote (one Zendesk retrieval returning far too much text) shows the failure that mattered was discovered only in production, undercutting the idea that upfront complexity-mapping alone tells you what to build.conf: medium

Arguments

Most builders should not adopt the full coding-agent harness toolkit (memory, compaction, sub-agents, hooks) by default. strength: high

Explicit premises:

Harness needs are driven by two independent variables: action complexity and context complexity.
Coding and deep-research agents are high in context complexity, which is why they need heavy context engineering.
Most support, sales, and enterprise agents are low on at least one axis and complete tasks in one to five turns.

Implicit premises:

Public harness discourse is generated disproportionately by coding-agent and personal-agent builders, creating an availability bias that makes the elaborate toolkit look like the default requirement for 'agents' in general.
Adding harness machinery has real cost (engineering time, latency, failure surface, maintenance burden) that is unjustified unless the task's complexity profile demands it.

Inferences:

A team building a low-turn, low-memory support agent that copies a coding agent's memory/compaction architecture is committing a category error, importing unneeded cost rather than following a genuine best practice.

Harness engineering effort should be treated as provisional and pruned each time a materially stronger model arrives, rather than treated as durable architecture. strength: medium

Explicit premises:

Each harness component encodes an assumption about something the current model cannot do.
Models improve via training on more and better agent traces (e.g., RLVR), which can make specific harness assumptions false.
Concrete precedents exist: CoT prompting was absorbed into reasoning models; Amp removed 'plan mode' once models could follow a single instruction; Manus, LangChain, and Claude Code have all had harnesses rebuilt multiple times.

Implicit premises:

Builders can reliably tell, after a new model release, which specific harness components have become dead weight versus still load-bearing.
Model improvement happens frequently enough (multiple step changes within a year) to make 'revisit on every model release' a practically recurring obligation rather than a rare event.

Inferences:

Some harness features that look necessary today (e.g., 'plan mode,' which the essay notes Claude Code and Codex still ship) may already be candidates for removal — and the essay's own inconsistency about why plan mode persists in some products but not others is left unexplained.

Prompt engineering, context engineering, and harness engineering are nested but distinct scopes and should be reasoned about separately when diagnosing an agent failure. strength: medium

Explicit premises:

Prompt engineering shapes an individual model call.
Context engineering determines what the model sees.
Harness engineering governs the complete system around those calls.

Implicit premises:

Conflating these three levels — which the essay implies 'the conversation around harness engineering' often does — causes builders to misdiagnose which layer actually needs work when an agent underperforms.

Inferences:

A team debugging an agent failure should first identify which of the three layers is implicated before reaching for a fix, rather than defaulting to 'better prompting' or 'more context.'

Narratives

The statistician's crude question 'how many testicles does the average human have?' as an analogy for how a summary answer to 'what harness techniques do I need' describes almost no real system.
→ Opens the essay by discrediting the idea of a single default harness checklist, priming the reader for the task-specific sizing argument that follows.
A coding agent reading, editing, and re-reading app.py in a loop until the LLM decides it's finished (Figure 1).
→ Illustrates the strict definition of 'agent' as an LLM-tool reasoning loop, distinguishing it from deterministic workflows.
A sales-call workflow that transcribes, extracts structured data, and populates a CRM as a fixed deterministic sequence (Figure 2).
→ Illustrates the contrasting 'LLM workflow' case with no reasoning loop, sharpening the agent/workflow boundary.
A 131-line Python coding agent and a 61-line search agent sharing the same core loop, plus a coding agent that can read its own tool definitions, write a new tool, hot-reload it, and use it on the next step.
→ Supports the claim that the reasoning core stays small even in sophisticated agents, and that capability can be added without permanently baking it into the core harness.
A deep-research agent built from scratch with Ivan Leo (ex-Manus, now Google DeepMind), which plans, dispatches concurrent search sub-agents with separate queries and iteration budgets, and synthesizes findings with citations using hooks for tracing.
→ Case study of a genuinely high action-and-context-complexity harness, showing what that end of the spectrum actually requires.
The Kirby-effect lineage of examples: chain-of-thought prompting becoming reasoning models via RL; Amp shipping then removing 'plan mode'; Manus rebuilt five times in a year; LangChain's Open Deep Research rebuilt multiple times; Claude Code's harness repeatedly ripped out; Opus 4.5 and GPT-5.2 (November 2025) as a named inflection point (quoting Simon Willison).
→ Evidences the mechanism by which harness features expire as models absorb capabilities.
William Horton and team's Maven Assistant at Maven Clinic: nearly all initial external conversations resolved in a single turn, with one Zendesk retrieval returning far too much text as the notable failure encountered.
→ Case study of a low-context, moderate-action-complexity production harness, contrasting with the coding-agent case and grounding the closing prescription.
The unresolved disagreement between Vivek Trivedy (harness as runtime-only) and Hamel Husain (eval harness is part of the agent harness) relayed via private correspondence.
→ Signals that even the essay's central term has a contested boundary, and that the author declines to adjudicate it.

Questions addressed

✅ What is an agent harness, and how does it differ from prompt engineering and context engineering?
The harness is the non-model runtime system (loop, tool execution, context management, state, safety); it is the broadest of three nested scopes, containing context engineering (what the model sees), which in turn contains prompt engineering (a single call).
✅ How much harness engineering does a given agent-building task actually need?
Assess the task's action complexity and context complexity independently, then build only enough harness for where it falls on both axes rather than defaulting to the full coding-agent toolkit.
✅ Why do harness features that once seemed essential get discarded as models improve?
The 'Kirby effect': each harness component encodes an assumption about a model limitation, and that assumption expires once training on richer agent traces lets the model absorb the capability itself.
⭕ Does the eval/testing infrastructure around an agent belong inside the definition of 'agent harness'?
The author presents Trivedy's runtime-only view against Husain's broader eval-inclusive view without adjudicating between them, explicitly deferring the question to a future live conversation.
⭕ How does a builder know, in the moment, which specific harness component has become obsolete after a model upgrade versus one that remains load-bearing?
Not addressed. The essay asserts pruning should happen ('yesterday's necessary workaround may be tomorrow's dead weight') but gives no diagnostic method, treating the answer as self-evident even though its own examples show inconsistent pruning across products (plan mode persists in Claude Code and Codex but was removed from Amp).

Gaps

incompleteNo diagnostic or decision procedure for scoring a task's position on the action-complexity/context-complexity axes. The framework is presented as the deciding factor but is never operationalized — no rubric, thresholds, or worked example for a borderline case — so two builders looking at the same task could reasonably disagree about where it falls.
Read next: Read a treatment that operationalizes the framework with measurable proxies (e.g., tools invoked per successful run, tokens retained across turns) or validates it against outcome data.
incompleteNo cost/economics treatment of over- vs. under-building a harness. The essay argues against overengineering but never quantifies what overengineering actually costs (latency, token spend, engineering hours, maintenance burden) against the cost of under-building and hitting a production failure, leaving 'add infrastructure only when a real failure demands it' as an unweighted heuristic.
Read next: Pair with pieces that quantify harness cost/performance tradeoffs across designs to make the build/wait decision economically grounded.
illogicalNo method is given for telling, after a model upgrade, which specific harness component has actually become obsolete versus still load-bearing. The essay asserts pruning as general practice ('yesterday's necessary workaround may be tomorrow's dead weight'), yet its own examples show inconsistent pruning in the wild — Claude Code and Codex still ship 'plan mode' even though Amp removed its equivalent — without explaining why the same capability threshold would be crossed for one product's harness and not another's.
Read next: Read practitioner accounts of harness regression-testing across model versions to see what evidence teams actually use to decide a component is safe to remove.
incompleteThe Maven Assistant case study — the essay's single detailed low-complexity example — describes an already-live consumer health product with meaningful compliance stakes (self-harm handoffs, withheld high-cost benefits questions). The essay never shows a genuinely minimal internal/low-stakes agent receiving the 'keep it small' advice, leaving open whether even Maven's 'moderate action complexity' harness (routing, bounded tools, guardrails, handoffs) is itself already more than many builders need.
Read next: Read case studies of minimal single-tool, single-turn internal agents to test whether even Maven's harness is over-built for lower-stakes use cases.
incompleteThe essay names but doesn't explain the skew whereby public harness-engineering discourse is dominated by coding/personal-agent problems even though support, sales, and enterprise agents are described as the majority of what builders actually build — leaving unaddressed whether this reflects genuine attention bias, differing incentives to publish, or something else.
Read next: Read industry-adoption surveys on where AI agents are actually deployed (support/sales/enterprise vs. coding) to check whether the discourse mismatch tracks a real minority-attention bias.

Closes gaps elsewhere

Agent Harness Engineering · g3 — Extends the harness-engineering framework beyond coding agents to support/sales/enterprise agents via the Maven Assistant case study, showing the framework still applies to non-coding domains but resolves differently there — low context complexity needs routing/guardrails/handoffs rather than the coding-agent toolkit of memory/compaction/sub-agents.
Agent Harness Engineering · g5 — Supplies an explicit decision rule for when harness investment is worth it: map the task on action-complexity and context-complexity axes, keep the harness minimal when both are low, and add infrastructure only when a real observed failure demands it.

Stop Overengineering Your Agent Harness

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents