Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems

A coding agent needs more than a model call. Its runtime decides which tools exist, what context reaches the model, when execution stops and which actions require permission. This paper calls that surrounding system the harness and compares its implementation across a selected set of agent systems.

The authors organize the comparison into seven subsystems: the agent loop, model integration, tools and actions, memory and context, safety and permissions, orchestration, and extensibility. They use pinned source versions, with a smaller set retained across two snapshots to inspect change over time.

The contribution is an architectural map rather than a shared runtime benchmark. It helps an engineer ask where an approval check belongs, what context compaction preserves or how a failed tool call returns to the loop. It does not establish that the most elaborate implementation is the most reliable.

Evidence quality varies within the corpus. The authors acknowledge that their Claude Code discussion relies on an unofficial circulated source snapshot rather than an official release. This breakdown does not reproduce that material or treat it as verified shipping behavior. It uses the paper's general taxonomy and explicitly bounded findings, while directing implementation decisions toward official project releases and measured requirements.

When a customer asks for an agent, the difficult requirements often sit outside the model: preserve the task after a restart, prevent an unauthorized write, keep a useful observation after compaction or explain why execution stopped. A subsystem map makes those requirements assignable and testable.

It also improves build-versus-adopt discussions. A library may handle provider calls while leaving approvals, event persistence and tool isolation to the application. An integrated agent runtime may supply more behavior but impose its own lifecycle and extension contracts. Compare those responsibilities against the customer requirement, not against a label such as framework or platform.

Use agent framework failure modes to structure that review. The source study supplies examples of design variation; the deployment still needs evidence that its selected configuration works under the customer's permissions, latency limits and recovery conditions.