Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — part 8/11

Cleaned-text code points [108832, 124707). Bibliography omitted here; source.md includes it.

Contemporary systems implement isolation at different granularities. Codex-style agents run each task inside a dedicated cloud sandbox with its own filesystem snapshot, network restrictions, and resource quotas, so that one execution cannot contaminate another ( Wang et al., 2025a ; Yang et al., 2024a ) . Claude Code takes a complementary approach by exposing graduated permission modes—from fully autonomous execution to mandatory user approval for every tool call—so that the same agent can operate at different trust levels depending on the task and the operator’s risk tolerance ( Anthropic, 2026 ) . In both cases, the sandbox is not merely a security fence. It is a cognitive boundary that simplifies the agent’s operating environment by removing irrelevant state, restricting dangerous actions, and making the workspace inspectable. Isolation thereby serves the same representational function as other forms of externalization: it changes what the model must reason about.

#### 6.2.3 Human Oversight and Approval Gates

Full autonomy is rarely appropriate for deployed agents. Most production systems therefore insert intervention points into the agent loop where a human operator can inspect proposed actions, approve or reject them, supply corrections, or redirect execution. The design question is where those gates should be placed and how much autonomy to grant between them.

Three patterns are common. Pre-execution approval pauses the agent before every potentially consequential action and asks for explicit confirmation. Post-execution review lets the agent act but surfaces results for inspection before committing or continuing. Escalation triggers allow the agent to run autonomously under normal conditions but halt and request human input when specific risk signals are detected—such as actions involving sensitive data, irreversible operations, or confidence below a threshold. Hook systems generalize this pattern by allowing operators to attach arbitrary logic—shell scripts, validation checks, notification dispatches—to specific lifecycle events in the agent loop, such as tool invocation, file write, or subagent spawn ( Lazaros et al., 2026 ; Fernandez, 2026 ) . The level of autonomy is therefore not a binary property of the agent but a configurable parameter of the harness, adjustable per task, per tool, and per organizational policy.

#### 6.2.4 Observability and Structured Feedback

An agent that acts without leaving inspectable traces is an agent that cannot be debugged, audited, or improved. Observability is the harness surface that makes the agent’s internal trajectory visible to developers, operators, and the agent itself Zhu and Lu (2026) ; Zheng et al. (2025b) .

At the implementation level, observability typically involves structured logging of every model invocation, tool call, memory read/write, and decision branch; execution traces that link each action to its causal antecedents; and aggregate metrics such as step counts, token consumption, error rates, and latency distributions. These records serve two distinct purposes. Externally, they support debugging, compliance auditing, and post-incident analysis ( Phiri, 2025 ) . Internally, they close the feedback loop that connects execution outcomes back to the modules that produced them. A failed tool call can trigger a memory write that records the failure context; a pattern of repeated failures can flag a skill for revision; a latency spike can cause the harness to switch protocol paths. Without structured observability, these feedback loops cannot operate, and the harness remains a static scaffold rather than an adaptive system. Observability is therefore not an auxiliary convenience; it is the mechanism by which the harness learns from its own operation.

#### 6.2.5 Configuration, Permissions, and Policy Encoding

A harness must encode not only what an agent can do, but what it is allowed to do under what conditions. This requires a configuration layer that separates policy from execution logic and makes governance rules explicit, versionable, and auditable.

In practice, configuration is typically stratified across multiple scopes. User-level settings encode personal preferences and trust boundaries. Project-level settings specify which tools are available, which file paths are accessible, and which commands require approval. Organization-level settings impose compliance constraints, cost ceilings, and data-handling rules that individual projects cannot override. This layered model means that the same base agent can operate under different policy regimes depending on its deployment context, without any change to the model or the skill artifacts it loads ( Anthropic, 2026 ; Lee et al., 2026 ) . Permissions and policies are therefore best understood as externalized governance: constraints that would otherwise have to be embedded in prompts or enforced through post-hoc filtering are instead encoded as declarative rules that the harness enforces at runtime.

#### 6.2.6 Context Budget Management

The context window remains the scarcest shared resource in any agent system. Memory retrieval, skill loading, protocol schemas, tool descriptions, and the model’s own reasoning traces all compete for the same finite token budget. How that budget is allocated is a harness-level coordination problem that no single module can solve on its own.

Effective context management typically combines several strategies. Summarization compresses older conversation turns and execution history into shorter representations that preserve decision-relevant information while freeing tokens for the current step ( Packer et al., 2023 ) . Priority-based eviction removes or demotes context entries whose relevance to the active subtask has decayed. Staged loading—already discussed for skills in Section 4 —ensures that detailed procedural guidance enters the context only when a matching task pattern is detected, rather than occupying budget from session start. The harness orchestrates these strategies jointly, because the optimal allocation depends on the current phase of execution: an early planning phase may need more memory and less skill detail, while a late execution phase may need the reverse. Context budget management is therefore not a compression problem in isolation. It is a dynamic resource-allocation problem whose solution must be informed by the agent’s current goals, the modules it is drawing on, and the constraints under which it operates.

Taken together, these six dimensions—loop control, sandboxing, human oversight, observability, configuration, and context management—provide an analytical framework for characterizing harness architectures. None of them is a form of externalization in its own right; each is part of the coordinative infrastructure that makes memory, skills, and protocols function as a coherent system. The next subsection uses this framework to examine how contemporary agent systems instantiate these dimensions in practice.

### 6.3 Harness in Practice: Contemporary Agent Systems

The analytical dimensions identified above are not abstract desiderata; they correspond to concrete design choices observable across deployed agent systems. Contemporary production agents—such as OpenAI Codex ( OpenAI, 2025a ) and Anthropic Claude Code ( Anthropic, 2026 ) —differ substantially in product surface, implementation lineage, and target workflow, yet they converge on a strikingly similar set of harness structures. That convergence is analytically significant: it suggests that the six dimensions are not incidental implementation choices but structural requirements of externalized agency. The following discussion examines these recurring patterns without tracking any single system in detail.

##### Loop and control flow.

Mature agent systems uniformly organize execution around an explicit loop that interleaves model reasoning with tool invocation and environmental observation. The harness is distinguished from the underlying model and characterized as providing the core agent loop, execution logic, and feedback pathways. Crucially, the loop includes explicit termination control—step limits, recursion depth bounds, and resource ceilings—that define the operational envelope within which the model’s reasoning unfolds.

##### Sandboxing.

Current systems implement execution isolation at different granularities. Some run each task inside a dedicated cloud sandbox with its own filesystem snapshot, network restrictions, and resource quotas; others expose graduated permission modes so that the same agent can operate at different trust levels depending on the context. These designs occupy different points in the isolation design space, but they share a common principle: sandboxing functions as a cognitive boundary that simplifies the agent’s operating environment by removing irrelevant state and restricting dangerous actions, not merely as a security perimeter.

##### Human oversight.

Rather than treating autonomy as a binary property, deployed harnesses implement configurable approval gates—hook systems that attach validation logic to specific lifecycle events such as tool invocation, file write, or subagent spawn, and application layers that route high-risk actions through approval workflows ( Lazaros et al., 2026 ; Fernandez, 2026 ) . The level of autonomy becomes a parameter of the harness, adjustable per task, per tool, and per organizational policy.

##### Observability.

Production systems produce structured execution traces—logs of every model invocation, tool call, memory read/write, and decision branch—that support debugging, compliance auditing, and post-incident analysis ( Phiri, 2025 ; Zhu and Lu, 2026 ) . These traces also close internal feedback loops: failed tool calls can trigger memory writes, and patterns of repeated failures can flag skills for revision. Observability is therefore the mechanism by which the harness learns from its own operation.

##### Configuration and governance.

Deployed harnesses typically stratify configuration across multiple scopes—user, project, and organization—so that the same base agent operates under different policy regimes without changes to the model or its skill artifacts. Permissions and policies function as externalized governance: constraints that would otherwise have to be embedded in prompts are instead encoded as declarative rules enforced at runtime ( Lee et al., 2026 ) .

##### Context budget.

The context window remains the scarcest shared resource in any agent system. Current harnesses actively manage it through summarization of older history, staged loading that defers detailed skill guidance until a matching task is detected, and priority-based eviction of entries whose relevance has decayed. The harness orchestrates these strategies jointly because the optimal allocation depends on the current execution phase.

The fact that independently developed systems converge on the same set of harness dimensions is itself instructive. It indicates that the primary design challenge of externalized agency is not eliciting better completions from a model, but arranging the operational conditions under which completions become effective interventions. Harness engineering is therefore neither a synonym for memory systems nor a rebranding of tool calling. It is the broader discipline concerned with constructing the cognitive and operational environment in which externalized modules compose into coherent agency.

### 6.4 Harness as Cognitive Environment

The preceding sections analyzed the harness in terms of its definition, its recurring design dimensions, and its manifestation in current systems. This final section steps back to interpret the harness at a theoretical level, asking what kind of object it is rather than how it is built.

The significance of the harness extends beyond infrastructure in the ordinary software-engineering sense. A harness does not merely support an already-formed intelligence; it shapes the effective cognition of the agent by determining the environment within which reasoning unfolds. It regulates what enters the agent’s perceptual field, what is retained across turns and sessions, which operations are callable, which actions require approval, which intermediate states are exposed for revision, and which forms of failure are detectable and recoverable. The harness therefore sets the agent’s practical cognitive boundary. What the agent can know, remember, and do is not fixed by model weights alone, but by the conditions of access, persistence, and action supplied by the surrounding system.

This claim can be situated within Norman’s account of cognitive artifacts ( Norman, 1993 ) . Norman characterizes cognitive artifacts as artificial devices designed to maintain, display, or operate upon information in ways that transform cognitive performance—not merely by accelerating inner computation but by changing the structure of the task itself. A harness fits this description at system scale. It does not simply augment a model with more context or more tools; it reorganizes the representational problem the model faces. By externalizing memory, formalizing procedures, introducing explicit control points, and constraining execution, the harness converts an unbounded task into a structured environment of guided action. The model’s apparent intelligence is thereby altered not only because it has more resources, but because the cognitive workload has been redistributed across artifacts, representations, and procedures outside the model. In earlier chapters, we analyzed this redistribution dimension by dimension: memory transforms recall into retrieval (Section 3.4 ), skills transform procedural reconstruction into guided execution (Section 4.7 ), and protocols transform ad hoc interaction into structured exchange (Section 5.4 ). The harness is the system-level artifact that composes these individual transformations into a single cognitive environment.

Kirsh’s account of the intelligent use of space sharpens this interpretation ( Kirsh, 1995 ) . His central observation is that cognition is shaped by how environments are arranged: spatial and representational organization can offload search, simplify choice, and reduce internal computational burden. The harness plays an analogous role for agents. It is a cognitive niche in which information, tools, permissions, and procedures are arranged so that desirable behavior becomes easier to execute and undesirable behavior becomes harder to produce. Defaults, hooks, file boundaries, skill invocation patterns, and review gates all serve as structured regularities that narrow the space of plausible action. The agent’s competence is therefore partly an ecological achievement: it arises from being embedded in an environment whose organization channels cognition productively.

The framework of distributed cognition generalizes the point. Hutchins’s formulation rejects the view that cognition resides exclusively within an individual mind, locating cognitive processes instead across people, artifacts, representations, and coordinated practices ( Hutchins, 1995 ) . An agent system equipped with a harness is intelligible in precisely these terms. The operative intelligence is distributed across model parameters, external memory stores, executable skills, protocol definitions, tool surfaces, monitoring systems, and the runtime constraints that govern their interaction. The harness is the medium through which this distributed system is coordinated. It is thus more accurate to describe the harness as a cognitive environment than as a mere infrastructure layer. Infrastructure is one of its manifestations; environmental structuring—the design of the conditions under which cognition unfolds—is its deeper function.

## 7 Cross-Cutting Analysis