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

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

These domain protocols matter because they externalize workflow-specific governance, not just generic communication. In vertical settings such as shopping, payments, identity, or compliance, the protocol must encode who is authorized, what evidence must be produced, and how responsibility is tracked across the flow ( UCP Documentation, 2026 ) . Across all families, the common pattern is that protocols make a coordination problem explicit. Tool protocols externalize invocation grammar, agent-agent protocols externalize delegation, agent-user protocols externalize presentation and state streaming, and domain protocols externalize specialized governance.

### 5.3 Agent Protocol in Harness Engineering

If the survey above shows which interaction burdens are being externalized in the ecosystem, Harness Engineering shows how those protocol surfaces become part of a running agent. The question is no longer only how an agent ought to communicate with other entities, but how those communication contracts govern execution, persistence, delegation, and recovery once the agent is embedded in a runtime.

Traditional LLM pipelines rely on the model to infer formats, remember recent interaction state, and guess how external actions should be formed. That can be adequate for short, loosely coupled requests, but it breaks down when work spans many steps, tools, agents, or approval boundaries. Harness Engineering externalizes that burden into protocol surfaces. Model outputs are captured as structured intents, validated against permissions and lifecycle state, routed through typed interfaces, and reflected back into the runtime as governed events rather than free-form guesses.

#### 5.3.1 Intent Capture and Normalization

Intent capture and normalization is the first of those surfaces. The job of this layer is to translate model-produced language into explicit commands or events that the runtime can validate and act on. Without it, execution semantics remain implicit: the system guesses what the model meant, and small linguistic variations can produce large operational differences.

A mature harness therefore normalizes intent before execution. Free-text proposals are mapped into protocol objects, checked against current context and permission boundaries, and rejected or revised if they do not satisfy the contract. This does not remove model judgment; it relocates the fragile part of the interaction from latent inference to an inspectable interface. The result is higher reliability in long-horizon execution, stronger governance, and cleaner handoffs across tools, agents, and users.

#### 5.3.2 Capability Discovery and Tool Description

Capability discovery and tool description form the second surface. In older systems, knowledge of available tools often lives partly in prompts and partly in developer assumptions. Protocolized discovery replaces that with explicit metadata. At session start or phase transitions, the runtime exposes the currently available tools, their schemas, and their input/output structure through standardized messages.

That shift has two effects. It reduces context inflation because the model does not need to carry every tool contract in prompt, and it makes capability boundaries governable because permissions, versioning, and auditing can be enforced against structured metadata rather than inferred from model behavior. In other words, the agent stops guessing what can be called and starts reading a declared capability surface.

#### 5.3.3 Session and Lifecycle Management

Harness protocols also need explicit session and lifecycle management because long-horizon agents do not operate as isolated single calls Chai et al. (2025) . The runtime must preserve interaction state across multiple turns, context windows, and execution phases. What is preserved here is not durable memory in the full sense, but protocol state: identifiers, roles, pending actions, phase transitions, and allowed next moves.

Most long-running systems therefore treat an execution as a lifecycle object with named states and transition rules. The protocol layer advances that object, emits status changes, and coordinates checkpoint or recovery events. When outputs or checkpoints are written to persistent storage, they become memory. The distinction matters: protocol maintains continuity of interaction; memory maintains continuity across time.

### 5.4 Protocol as Cognitive Artifact

The preceding sections surveyed the content, landscape, and harness integration of agent protocols. This final section interprets what protocol externalization achieves as a representational transformation, using the same cognitive-artifact framework applied to memory and skills in earlier chapters.

In Norman’s terms, a cognitive artifact transforms a task by changing its representational structure ( Norman, 1993 ) . Protocols do this for interaction. Without them, every external action is partly a natural-language inference problem: the model must infer the intended operation, guess the right format, reconstruct acceptable constraints, and hope the receiving system interprets the result correctly. Protocols replace that open-ended inference with a bounded, structured task: fill typed fields, follow a declared state transition, and receive structured feedback. The model still needs judgment about whether and when to act, but it no longer needs to reinvent the syntax and semantics of interaction on each step.

This is one of the strongest forms of externalization in agent systems, because it removes entire classes of reasoning from the critical path. The transformation is analogous to the shift that memory introduces for temporal state (Section 3.4 ) and that skills introduce for procedural expertise (Section 4.7 ), but it operates on a different dimension: not what to remember or how to proceed, but how to communicate and coordinate. Standardized protocols reduce the number of decisions that must be made inside the model. They make correct interaction easier and incorrect interaction harder—which is precisely what Norman’s framework predicts when an external representation is well matched to the task.

Kirsh’s account of complementary strategies provides additional clarity ( Kirsh, 1995 ) . LLMs are strong at interpreting intent, selecting among options, and adapting to context, but they are unreliable at consistently producing well-formed structured output under varying interface requirements. Protocols implement a complementary division of labor: the model contributes judgment and intent, while the protocol surface contributes format, validation, and lifecycle control. Neither side alone is sufficient; together, they produce interaction that is both flexible and disciplined.

This interpretation also explains why protocols serve a distinctive role that cannot be reduced to memory or skills. Memory externalizes what has been learned over time; skills externalize how tasks should be carried out; protocols externalize the discipline by which both memory and skills enter the world as governed action. Memory needs governed read and write paths; skills need bindable interfaces; both depend on protocols to cross system boundaries in a form that is inspectable, auditable, and recoverable. Protocols are therefore not secondary plumbing around a “real” intelligent core. They are cognitive artifacts for interaction—the representational infrastructure that makes other forms of externalized intelligence operational.

## 6 Unified Externalization: Harness Engineering

Figure 7 provides an overview: the foundation model sits at the center, surrounded by six harness dimensions that coordinate externalized cognition into coherent agency. Three of those dimensions—Memory, Skills, and Protocols—are the externalization modules analyzed in the preceding chapters (Sections 3 – 5 ). The remaining three—Permission, Control, and Observability—are the operational surfaces that govern how those modules are accessed, constrained, and monitored at runtime. This chapter unpacks these three surfaces into six finer-grained analytical dimensions that together characterize harness design. Each earlier chapter closed by noting that its module becomes fully operational only when embedded in a broader runtime. Sections 3.3 , 4.6 , and 5.3 identified specific harness demands from each module’s perspective. The present chapter unifies those threads. It asks what kind of system is needed to compose externalized memory, skills, and protocols into coherent agency, and how that system should be understood analytically.

The central claim is that a harness is not merely an implementation convenience layered on top of a capable model. It is the designed cognitive environment within which externalized modules become jointly effective. That framing motivates the structure of this chapter. Section 6.1 defines the harness concept and situates it relative to the module-level analyses of earlier chapters. Section 6.2 identifies the recurring analytical dimensions along which harness designs vary. Section 6.3 examines how these dimensions manifest in contemporary agent systems. Section 6.4 closes the chapter by interpreting the harness as a cognitive environment through the lens of distributed cognition and cognitive artifact theory.

### 6.1 What is a Harness?

Externalization, pursued module by module, improves local capability, but agenthood demands global coordination. Memory accumulates experience without specifying which traces are salient to the present task. Skills encapsulate effective routines without automatically incorporating lessons from past interactions. Protocols regularize invocation formats without determining when, or under what policy, a tool should be called. The modules are present, yet the cognitive loop that would render them jointly effective remains under-specified. What is missing is a principled structure that coordinates their interaction over time—aligning perception, memory access, action selection, execution, monitoring, and revision within a single operational envelope.

The term “harness” names that structure. It has recently entered practice as a descriptor for the scaffolding that converts raw model capability into reliable agent behavior. OpenAI’s engineering discussions around Codex, for instance, use the term explicitly to describe the agent loop, execution logic, feedback pathways, and surrounding operational machinery that make the system usable ( OpenAI, 2025a ) . Because the concept is still consolidating, the characterization we offer here is best understood as a synthesis of recurring patterns in current systems rather than a closed definition.

A practical agent, on this account, is better understood as a model operating inside a harness than as a model with peripheral capabilities attached. A foundation model alone retains general-purpose inference ability, but lacks the operational structure that determines what it can access, how it may act, how its actions are constrained, and how its behavior is observed and revised across time. The harness supplies that structure. It governs the pathways by which the model encounters context, invokes tools, preserves state, and responds to feedback. Agency is therefore not located in the model alone; it emerges from the coupling of the model with the environment that organizes its cognition into action.

Described functionally, the harness comprises the external systems that make such coupling possible: persistent memory and project-level context, reusable skills and executable routines, protocolized interfaces for deterministic interaction with tools and services, and the broader runtime infrastructure within which these elements become operational. The crucial point is not the exact inventory of components—which varies across implementations and will continue to evolve—but their collective role: they create the conditions under which model reasoning can be made stable enough to support sustained work. This shifts the locus of analytical attention from model capability alone to the representational, procedural, and operational conditions under which the model perceives, decides, and acts. Improvements in agency may therefore come not only from better base models, but also from better organization of memory, sharper constraint regimes, more legible feedback channels, and more carefully designed execution environments.

### 6.2 Analytical Dimensions of Harness Design

The modules discussed in earlier chapters—memory stores, skill artifacts, and protocol interfaces—supply the raw materials of externalized cognition, but they do not by themselves specify how the runtime coordinates perception, action, constraint, and feedback over time. That coordination is the province of the harness. The three operational surfaces highlighted in Figure 7 —Permission, Control, and Observability—can be decomposed into six recurring dimensions of design variation. Each dimension addresses a distinct aspect of how externalized modules are composed into a functioning agent; together, they provide an analytical framework for comparing harness architectures rather than an implementation checklist.

#### 6.2.1 Agent Loop and Control Flow

The agent loop is the temporal backbone of the harness. At its simplest, it implements a perceive–retrieve–plan–act–observe cycle in which the model receives a structured view of the current state, decides on an action, executes it through a tool or protocol interface, observes the result, and updates its internal plan accordingly ( Yao et al., 2023a ; Shinn et al., 2023 ) . Practical systems vary the loop structure considerably. Single-loop designs interleave reasoning and action within one generation pass; hierarchical designs separate a planning agent that decomposes goals from executor agents that carry out individual steps; and multi-agent designs route subtasks across specialized agents with distinct tool sets and permission scopes ( Wu et al., 2023 ; Hong et al., 2023 ; LangChain, 2024 ) .

What the harness adds beyond a bare loop is governance over termination, recursion, and resource consumption. Without explicit control, an agent loop can cycle indefinitely, escalate costs through unbounded tool calls, or recurse into sub-agent spawns that exhaust context or compute budgets. Production harnesses therefore enforce maximum step counts, recursion depth limits, per-step cost ceilings, and timeout constraints. These controls are not secondary safety measures; they define the operational envelope within which the agent’s reasoning unfolds. A well-tuned loop makes the agent more reliable not by making the model smarter, but by bounding the space of possible execution paths.

#### 6.2.2 Sandboxing and Execution Isolation

Whenever an agent acts on the world—writing files, executing shell commands, calling external APIs—the harness must decide how much of the environment to expose and how to contain unintended side effects. Sandboxing is the engineering response to that requirement. It creates a controlled execution boundary that limits what the agent can read, write, and modify, and it provides the reproducibility guarantees that make failures diagnosable and rollbacks feasible.