Agent Anatomy: Seven Harness Responsibilities

The authors inspect pinned system versions, mainly from July 2026. Their sample includes Claude Code, Codex CLI, Gemini CLI, Mistral Vibe, OpenHands, Aider, mini-SWE-agent, Hermes, Pi, OpenCode, and OpenClaw. Claude Code is represented by a March source snapshot. OpenClaw serves as an assistant-gateway contrast, while Omnigent is considered separately as a system coordinating other harnesses. These deliberately chosen projects have different purposes; they are not a random market sample.

There is no common evaluation on identical tasks. Source code reveals history storage, tool implementation, and approval checks, but cannot establish which system solves tasks better. Vendor scores from different models and configurations do not form a fair comparison. The host treats the study as a catalog of architectural options whose practical benefits remain to be tested.

An agent combines a model and a harness. The harness has seven responsibilities: the execution loop, model integration, tools, context management, safety and permissions, orchestration, and extensions. A framework supplies libraries for constructing a system; a harness supplies the environment in which the agent acts. This breakdown supports discussion of individual mechanisms instead of judging entire products by one score.

A minimal loop with bash can already solve tasks. Much product code addresses recovery, human interaction, access restrictions, and extensibility. Even stopping conditions differ: Aider checks edits and returns errors to the model, Hermes checks unverified changes before exiting, and OpenHands adds an evaluation step. The study describes these alternatives without selecting a winner. Each leaves different responsibilities with the user.

A shared API does not remove model-specific behavior. Harnesses use vendor protocols, LiteLLM, custom transports, or other SDKs. Caching, reasoning modes, and tailored instructions are not exclusive to model vendors. However, someone must implement and maintain those optimizations as models change. Building a harness means accepting that continuing compatibility work.

File editing illustrates the issue. Exact text replacement, a dedicated patch format, progressively looser matching, and shell commands define different action contracts. OpenCode selects an editing tool according to the model family. Moving a harness to a new model therefore requires checking how that model edits code, not merely whether an API request succeeds. Editing is only one tool affected by such differences.

Tool counts change quickly, making feature inventories snapshots of particular versions. Large sets of descriptions consume context and complicate action selection. Deferred loading and tool search let a model request a relevant description instead of receiving everything at once. Hermes also limits the amount of external tool-schema content placed in context.

The host questions the basis for the authors’ recommendation to introduce such mechanisms at roughly fifteen tools. Observing established products suggests an experiment, not a universal threshold. A team still needs to determine whether its chosen tool organization improves accuracy or cost on its own workload.

Rewinding a conversation does not necessarily rewind the work. Pi keeps branching conversation history without restoring files, Mistral Vibe offers file restoration through checkpoints, and OpenCode uses a shadow git repository. Session state must relate explicitly to the working copy. Otherwise, an agent can read a conversation about one project state while operating on another.

The next-turn context window, the action log, and persistent knowledge serve different purposes. LLM-based context summaries are widespread, although thresholds and retention rules vary. Persistent memory has more diverse write policies: human approval, size-limited files, or a separate agent consolidating memories. The host sees this area as less settled. Merely having memory says little about what will survive or how useful it will be.

Approval determines whether an operation may proceed; isolation constrains its execution environment. These are separate safety mechanisms. The review covers rules, classifiers, and user prompts alongside operating-system sandboxes and containers. Codebase size does not reveal whether a required access boundary exists. Omitting built-in isolation may deliberately leave its provision to the user.

Orchestration also involves more than a subagent checkbox. Options include sequential child calls, concurrent sessions with separate histories, task trees, and partial inheritance of parent context. Child-tool access and result delivery matter. Many systems implement internal coordination through their own mechanisms; a shared external protocol is not a prerequisite for delegation.

MCP connects tools, a skill describes how to perform work, and a hook responds deterministically to an event or checks an action. The host disputes inferring greater skill popularity from a small coverage difference within this sample. General-purpose products usually support several of these mechanisms. He also proposes revisiting old step-by-step instructions when models change and evaluating skills instead of preserving them unchanged.

Comparing April and July versions reveals ideas moving between projects, including planning modes, checkpoints, and extension formats. The host connects SDKs, add-on catalogs, and enterprise controls to a transition from tools to platforms. His forecast that vendors will sell entire development workflows rather than tokens alone remains an interpretation of that trend.

The authors found neither general-purpose agent frameworks nor embedding-based code retrieval in the studied corpus. This is a sample-bounded observation: other systems may differ, and documentation retrieval is a separate case. Pinned versions make inspection repeatable without turning an absent mechanism into proof that it is useless.

The episode closes by returning to controlled experiments from the preceding review: change planning, tools, or context management and examine the effects on real tasks. A small teaching scaffold helps begin that investigation but does not replace a product with recovery and access controls. The atlas helps choose questions. An experiment must establish whether a change improves your particular system.