Agent Anatomy: Seven Harness Responsibilities

Alexander opens by distinguishing agent rankings from studies of their internal architecture. The paper pins eleven systems and inspects source code to identify seven harness responsibilities. This reveals where history lives, how tools are invoked, and which mechanisms check permissions. It does not establish which architecture solves tasks better: there is no common evaluation of all systems. The sample is heterogeneous, combining model-vendor products, a minimal research agent, and the OpenClaw assistant gateway. Claude Code is represented by a March snapshot. These boundaries matter when interpreting broad findings, particularly claims about absent frameworks or code-retrieval mechanisms.

A minimal loop already performs useful work, while a full product adds recovery, interfaces, access restrictions, and extensions. The host examines model integration in detail: one API does not eliminate differences in caching, instructions, or editing formats. Open harnesses can implement optimizations similar to vendor products, but someone must continually maintain them. Exact replacement, dedicated patches, and looser matching illustrate the cost of compatibility. Larger tool sets create another problem because descriptions consume context. Deferred loading and search organize access, although the host does not treat the authors’ numerical threshold as a proven universal rule.

The discussion separates session history, the working copy, and persistent memory. Returning to an earlier message can leave files modified; products make different deliberate recovery choices. A model needs bounded context for its next step, a history for auditing, and durable knowledge for future tasks. Context summarization is widespread, while persistent-memory write policies remain diverse. Approval and process isolation also need to be separated. User confirmation does not describe filesystem or network boundaries, and a large codebase does not guarantee a sandbox. Subagent coordination introduces further decisions about inherited history, tool access, and result delivery.

MCP, skills, and hooks are examined as distinct extension points. The host challenges a claim that skills are more popular based on a small coverage difference in the selected sample: general-purpose products usually support multiple mechanisms. Old instructions should be revisited as models change and assessed through evaluations. Repeated source snapshots reveal ideas moving between projects, while SDKs, add-on catalogs, and enterprise policies suggest a platform transition. Alexander closes by treating the atlas as a collection of hypotheses: choose a subsystem, change one approach, and test it on your own tasks. Architectural appeal cannot replace observed benefit. Timestamps follow the Podster audio version; alignment with the YouTube timeline was not measured separately.