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

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

The three externalization modules are analytically distinct, but real systems derive their power from interaction among them. Sections 3 – 5 treated memory, skills, and protocols largely in isolation; Section 6 argued that the harness unifies them. This section examines the system-level couplings that arise once the modules are placed inside a harness, asks how they manifest at the model boundary, and considers where the boundary between parametric and externalized capability should be drawn.

### 7.1 Module Interaction Map

##### Memory to skill: experience distillation.

Repeated trajectories can be distilled into reusable procedures, making this the main path by which accumulated experience becomes codified expertise. Systems such as TED and UMEM show how episodic traces can be clustered, abstracted, and promoted into skill artifacts without modifying base-model weights ( Yuan et al., 2026 ; Ye et al., 2026 ) . Voyager makes the same logic concrete in lifelong learning: successful behaviors are retained as reusable code-level skills that can be recomposed later ( Wang et al., 2023a ; Zhang et al., 2025b ) .

The cross-cutting significance of this flow is that memory does not merely preserve the past; it provides the evidence from which a harness can decide what deserves to become a reusable operating pattern. The quality of the distillation step—how the system determines which trajectories generalize and which are situational—therefore conditions the reliability of the entire skill layer downstream. If distillation is too aggressive, noisy or context-dependent behaviors become entrenched as skills; if too conservative, the system fails to capitalize on hard-won experience.

##### Skill to memory: execution recording.

The flow also runs in the opposite direction. Every skill execution generates traces, intermediate failures, and runtime refinements that would otherwise vanish with the active context window. Observability and logging infrastructure capture those trajectories as durable evidence, allowing the system to validate which skills remain reliable and which ones should be revised, split, or constrained ( Chen et al., 2025 ; Wang et al., 2026f ; Wang et al., 2026d ) .

This flow is what makes the skill layer self-correcting rather than merely self-expanding. A mature skill system cannot be separated from memory management: reusable procedures only remain trustworthy if their real execution histories are continuously written back into external state. Without this recording, the harness has no empirical basis for skill maintenance, and the distillation path from memory to skill (the previous flow) operates on increasingly stale evidence.

##### Skill to protocol: capability invocation.

Skills become operational only when they cross the boundary from abstract procedure to governed action. That transition occurs through protocols, which translate high-level intent into typed calls, lifecycle events, and permission-checked interaction surfaces ( Takyar, 2025 ; JSON-RPC Working Group, 2010 ; Hou et al., 2025 ) . A skill may specify that the agent should search code, run tests, and summarize a diff, but the individual operations are carried out through protocolized interfaces to search tools, shell commands, and test runners.

The coupling matters for safety as well as for function. The OpenClaw analysis of the “Lethal Trifecta”—sensitive data access combined with unconstrained external communication and unverified execution—illustrates that unconstrained execution remains a safety problem even when the procedural guidance itself is sound ( McKerchar, 2026 ) . Protocol-level validation therefore acts as a boundary check that is independent of the skill’s own correctness: even a well-written skill can be intercepted if it attempts to invoke a forbidden operation or malformed call.

##### Protocol to skill: capability generation.

Once an interface is standardized, it becomes substantially easier to codify best practices for using it. OpenAPI and MCP do not merely make tools callable; they provide enough structural regularity for systems to package interface-specific know-how into reusable skill artifacts ( OpenAPI Initiative, 2021 ; Hou et al., 2025 ) . The HashiCorp Agent Skills ecosystem is a concrete example: once the underlying interfaces for infrastructure management are made legible and stable through protocol contracts, domain procedures can be externalized as portable skill files rather than rederived ad hoc during each run ( Baghel and Chandna, 2026 ) .

This flow highlights an important asymmetry in the externalization process. Protocol standardization does not merely consume skills; it actively expands the surface on which new skills can be authored or induced. Each new stable interface is a potential seed for a family of reusable procedures. The ecosystem growth of skill artifacts therefore depends in part on the pace and quality of protocol standardization.

##### Memory to protocol: strategy selection.

Stored context can also influence which protocol path the harness selects next. Historical success rates, user preferences, and prior failures can determine whether a request should stay local, call an external tool, or be delegated to another agent ( Xu et al., 2026b ; Zhou et al., 2025 ) . In systems with multiple available interaction paths, memory transforms protocol selection from a static configuration into an experience-informed routing decision.

This coupling is especially visible in multi-agent settings, where the harness must choose between local execution, tool invocation via MCP, and delegation to a remote agent via A2A. If past interactions with a particular tool have consistently failed for a certain class of tasks, the routing logic can learn to prefer an alternative path. Memory therefore informs not only what the model reasons about, but which interaction channel carries that reasoning into action.

##### Protocol to memory: result assimilation.

Finally, every protocol interaction produces state that must be preserved if it is to become part of the agent’s ongoing cognition. Tool outputs, approval events, error payloads, and delegation results arrive as structured responses, often in formats richer than plain text ( Qin et al., 2023 ) . The harness must normalize these results into memory so that later reasoning can rely on verified external state rather than on reconstructed or hallucinated assumptions.

This flow closes the cycle. The protocol layer provides the evidence that memory stores, which later conditions new skill selection and new protocol routing. Without reliable result assimilation, the agent’s memory becomes disconnected from its actual interaction history, and downstream flows—particularly experience distillation and strategy selection—operate on unreliable premises.

##### System-level dynamics.

The six flows above are pairwise, but several important dynamics emerge only at the system level. First, the cycle is self-reinforcing: better memory enables better skill distillation, better skills produce richer execution traces, richer traces improve memory, and so on. This positive feedback can accelerate capability growth, but it can also amplify errors. A poisoned memory entry can lead to a flawed skill, whose execution traces further contaminate memory—a cascade that no single module’s quality control can interrupt without harness-level intervention.

Second, the modules compete for the same scarce resource: the model’s context window. Memory retrieval, skill loading, and protocol schemas all occupy tokens. Expanding one module’s context footprint necessarily compresses the others. A harness must therefore manage not only the content of each module but also their relative budget allocation at each step of execution, a coordination problem analyzed further in Section 6 .

Third, the flows operate at different timescales. Protocol interactions are typically synchronous and fast; skill loading occurs at task or subtask boundaries; memory distillation and skill evolution unfold over sessions or longer. A harness that optimizes for one timescale—say, fast tool execution—may neglect the slower loops that determine long-term capability growth. Effective harness design requires balancing responsiveness at the fast loop with coherence at the slow loop.

### 7.2 The LLM Input/Output Perspective

Another useful viewpoint is to ask how each module manifests at the model boundary. Seen from the perspective of the context window and output surface, the harness does not simply add more components; it reorganizes what enters and leaves the model into functionally distinct layers.

##### Memory as contextual input.

Memory shapes the historical and situational input available at decision time. Instead of flooding the model with a full execution log, retrieval mechanisms select a small slice of state, prior trajectories, or entity relations that matter for the present step ( Du, 2026b ) . This turns long-horizon continuity into a targeted contextualization problem and reduces context waste. The quality of this selection directly determines whether the model reasons over an accurate picture of the past or over a distorted one.

##### Skills as instructional input.

Skills shape the procedural guidance given to the model. Rather than encoding every workflow in a monolithic system prompt, the harness can load specialized instructions, examples, and constraints only when a relevant task pattern appears ( Jiang et al., 2026a ) . The model is thereby asked less often to invent a workflow from scratch and more often to interpret and follow a prepared one. The risk, discussed in Section 4 , is that overly detailed or context-consuming skill files can crowd out other inputs; the benefit is that procedural variance is reduced when the right skill is loaded at the right time.

##### Protocols as action schema.

Protocols shape the output boundary. By enforcing structured contracts such as JSON schemas, MCP messages, or OpenAPI-aligned calls, they constrain the model’s generative space and make downstream execution deterministic enough to govern ( Hasan et al., 2026 ) . The output is no longer merely language to be interpreted later; it becomes a machine-readable action proposal situated inside an explicit interface. This constraint reduces the incidence of malformed tool calls and hallucinated arguments, though it also means that action expressiveness is bounded by the protocol’s schema.

This input/output decomposition is analytically useful because it clarifies both the division of labor and the failure taxonomy. Retrieval errors manifest as input-selection errors: the model reasons correctly but over the wrong context. Skill failures manifest as procedural-guidance errors: the model follows instructions faithfully but the instructions themselves are flawed or mismatched. Protocol failures manifest as action-schema errors: the model’s intent is sound but the output violates the interface contract. The harness makes these failure classes separable enough to debug, attribute, and optimize independently—an important property for systems where multiple modules contribute to every decision.

From a broader perspective, this tripartite organization of the model boundary—contextual input, instructional input, and action schema—can be understood as a structured form of context engineering. Rather than treating the prompt as an undifferentiated text buffer, the harness separates it into layers with distinct update rates, governance requirements, and failure modes. Each layer can be revised without disturbing the others: memory retrieval can be improved without rewriting skills, skill artifacts can be updated without changing protocol schemas, and protocol surfaces can be extended without altering memory policies. This modularity at the model boundary is one of the main practical advantages of the externalization approach.

### 7.3 Parametric vs. Externalized: The Trade-off Space

The relevant design problem is not whether intelligence should reside in the model or in the infrastructure. It is where particular burdens should live, given their update rate, reuse pattern, governance requirements, and execution cost. The following dimensions structure that partitioning decision.

##### Update frequency and temporal decay.

Fast-changing knowledge and procedures are strong candidates for externalization. APIs, organization structures, and live environment state decay too quickly to maintain reliably in model weights. Attempts to keep a model current through continual fine-tuning risk catastrophic forgetting and are often impractical at the required update frequency ( Cheng et al., 2024 ; Qiu et al., 2025 ; Zhang et al., 2025d ; Chen et al., 2026a ) . External stores, by contrast, can be updated immediately without retraining and can maintain explicit provenance and versioning ( Oelen et al., 2025 ; Chinthareddy, 2026 ) . Stable background capabilities—language understanding, broad reasoning, common-sense inference—decay at a much slower rate and are still more naturally carried parametrically, where they benefit from fast retrieval and deep integration with the model’s representational structure.

##### Reusability and multi-agent portability.

If a capability is repeatedly needed across tasks, users, or agents, externalization improves portability and composition ( Tagkopoulos et al., 2025 ; Xu and Yan, 2026a ; Liu et al., 2025d ) . Explicit skills, scripts, and interface artifacts can be shared, versioned, and reused across heterogeneous runtimes without requiring that each agent rediscover or retrain the same procedures. In multi-agent settings, a skill authored for one agent can be broadcast to an entire swarm, provided that the skill’s assumptions about tools and protocols are met. One-off or highly idiosyncratic behavior may not justify the overhead of externalization, packaging, and maintenance ( Zhao et al., 2026a ) .

##### Auditability, governance, and alignment.

Whenever inspection, approval, rollback, or policy enforcement matters, externalized artifacts have clear advantages over opaque parametric behavior ( Li et al., 2026b ; Lazaros et al., 2026 ; Lee et al., 2026 ; Fernandez, 2026 ; Zhu and Lu, 2026 ) . Symbolic interfaces support circuit breakers, schema validation, and traceable execution records in a way that weights alone do not. Alignment fine-tuning (such as RLHF) provides probabilistic behavioral shaping, but externalized constraints provide deterministic enforcement at the interface level. High-stakes deployment therefore pushes the architectural boundary outward: the more consequential the agent’s actions, the stronger the case for making the governing logic explicit and inspectable.

##### Latency, simplicity, and context burden.

Externalization shifts computational and organizational cost from the model’s forward pass into the surrounding system. Retrieval, routing, parsing, and tool invocation all introduce latency ( Park et al., 2026 ; Xu et al., 2025a ) . Every retrieved artifact competes for limited context budget, and excessive context loading can degrade performance through information overload or the “lost in the middle” phenomenon ( Corallo and Papotti, 2026 ; Mishra et al., 2026 ; Esmi et al., 2025 ) . For ultra-fast, low-variance, or purely semantic tasks, allowing the model to rely on its internal parametric knowledge remains substantially simpler and often more reliable.