8 Critical Harness Design Issues That Threaten Long‑Running Agent Accuracy

1. Introduction

If you want to design a harness for a long‑running autonomous system, several problems must be understood first. The purpose of a harness is to hedge two classes of issues: agents taking shortcuts and agents misinterpreting requirements.

2. Where Agents Go Wrong

2.1 Before the Task Starts

Errors are often planted before execution when the context is incomplete or contradictory. The author stresses that a systematic check for completeness and consistency must be performed before any action, because a faulty premise propagates downstream.

2.2 Planning Stage: Incomplete Context

During planning, the agent must choose a solution path. The most common failure is selecting the wrong attack path, now often caused by alignment problems rather than model stupidity. The author recommends that the agent cover all relevant files before planning and that the repository avoid conflicting information, otherwise the agent merely guesses in a sea of contradictory context.

2.3 Planning Stage: Short‑Term Thinking

Agents tend to adopt cheap, short‑term fixes, akin to hiring a low‑cost contractor that leaves technical debt. The suggested remedy is to remind the agent during planning to produce solutions that are extensible, maintainable, and respect clean‑code principles. A practical approach is to have the agent generate multiple (e.g., five) candidate plans and let a downstream process select the one that best follows clean‑code guidelines.

2.4 Execution Stage: Context Anxiety

When execution begins, the biggest problem is not capability but the exhaustion of context. Large‑scale, multi‑session tasks consume millions of tokens, causing the agent to rush to finish. The author advises a smart session handoff: the handoff prompt must be dense and detailed so the new agent can continue without re‑establishing context, effectively compressing the necessary information.

2.5 Execution Stage: Plan Drift

Agents may deviate from the original plan, delivering an approximate solution (A') that falls short of the true goal (A). This leads to downstream code breaking. Early and frequent verification is required to ensure the implementation truly matches expectations, preventing cascading failures.

2.6 Execution Stage: Complexity Fear

Agents show a clear aversion to complexity: they can write a five‑line function easily but avoid a 50,000‑line class, either by producing stubs or aborting the session. The author notes that, similar to human behavior, breaking a large problem into many small (<100‑line) tasks reduces fear and encourages progress.

2.7 Execution Stage: Lazy Verification

Agents naturally choose the shortest verification path, writing weak tests that pass without truly validating behavior. The mitigation is to give the verification agent the freshest possible context and ensure it tests the exact production behavior, not a superficial substitute. The author lists concrete checks for a front‑end button: visual confirmation, actual click, and correct payload receipt.

2.8 Execution Stage: Entropy Buildup

Agents often modify code without updating documentation, leaving the repository increasingly noisy and harder to maintain. The recommended solution is to reserve tokens after each long session for a cleanup agent that removes contradictions, deletes dead code, and updates stale documentation.

3. Why Build Your Own Harness

Native harnesses in tools like Claude Code or Codex have limited control points and lack hooks. A better design separates the orchestration layer from the task list, placing a dedicated agent to enforce algorithmic contracts, monitor for drift, and trigger independent quality‑assessment agents. Additional agents can classify task complexity, split high‑complexity tasks into smaller ones, and perform post‑session cleanup. Collecting detailed telemetry (prompts, traces, results) and evaluating it with a rubric is essential for iterative improvement.

4. Conclusion

For most users, a simple native harness suffices for short tasks. However, when dealing with long‑duration, high‑intensity autonomous engineering tasks, the article highlights the inevitable problems and provides concrete, pre‑emptive strategies to keep agents accurate and the codebase healthy.