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

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

A skill is usually not itself an action executor. Instead, it must be bound to a lower-level runtime substrate, such as tools, files, APIs, sub-agents, protocol endpoints, or other execution interfaces. A skill may specify that the agent should search relevant code, run tests, and summarize the resulting diff, but the actions themselves are carried out by search tools, file operations, shell commands, and test runners. Tools therefore provide the executable operations; protocols govern how those operations are described and invoked; skills provide the higher-level strategy for combining them into repeatable task completion.

This binding typically requires an intermediate interpretation layer that determines, in the current context, which skill steps should be activated, which primitives should be bound, which conditions should trigger branching, and which constraints should take priority. Without such an interpretation and binding process, a skill easily remains a static artifact that is readable in principle but unusable in practice. More generally, schema-based interfaces such as MCP ( Anthropic, 2024 ) support this runtime binding layer by making capabilities discoverable and invocable without collapsing skills into tools or protocols themselves.

#### 4.3.5 Composition

The value of a skill system is most fully realized when skills can be composed. Unlike atomic tools, skills can participate in higher-order structured coordination, allowing complex tasks to be decomposed into the cooperation of multiple capability packages. Common composition patterns include serial execution, parallel division of labor, conditional routing, and recursive invocation of sub-skills within a higher-level skill ( Wang et al., 2023a ) .

This compositionality means that a skill is not merely a document intended for model consumption, but a schedulable runtime unit inside an agent architecture. More importantly, composition is not just the concatenation of multiple procedural fragments. It is a higher-level reuse of procedural expertise itself. For example, a skill for producing a data analysis report need not be implemented as a monolithic end-to-end procedure. It can instead be organized as a coordinated composition of smaller skills for data cleaning, statistical analysis, visualization, and narrative synthesis. In this way, the system gains not only stronger task performance, but also better maintainability, replaceability, and auditability. Composition therefore marks the point at which skills become a genuine capability layer rather than a collection of isolated recipes ( Yu et al., 2025 ) .

Overall, skill externalization should not be understood as the mere publication of a static instruction file. It is a coordinated process in which procedural expertise is specified, made discoverable, selectively disclosed, bound to executable substrates, and composed into larger capability structures. What matters is not only whether a skill can be written down, but whether it can reliably enter the agent’s runtime as a usable unit of action that interoperates with retrieved state and protocolized interfaces. Hence, the externalization of skills marks a shift from informal prompting toward a more explicit capability layer for agent systems.

### 4.4 Skill Acquisition and Evolution

A skill system matters not only because it stores authored instructions, but because it provides a pathway for turning successful behavior into reusable expertise. Skill acquisition is therefore better understood as an evolutionary process in which procedural knowledge is written, extracted, discovered, and recomposed over time ( Xu and Yan, 2026b ) .

##### Authored.

Manual authoring remains the most common and stable route by which skills enter current systems. Whether in the form of SKILL.md , AGENTS.md , project-level instruction files, or organizational SOP templates, these artifacts are all instances of human-designed procedural capability packages. Their importance lies not only in providing initial capability, but also in supporting iterative revision. When an agent repeatedly exhibits a failure pattern in deployment, engineers can update the corresponding skill so that one observed failure becomes a clarified procedure or an added constraint. In this way, authored skill documentation is not merely descriptive. It also serves as a practical interface through which operational experience is gradually turned into reusable behavioral structure ( Ling et al., 2026 ) .

##### Distilled.

Skills may also be induced from historical trajectories, practice traces, or other stored experience. Episodic records preserve what the agent previously did and why a trajectory succeeded or failed. When certain successful structures recur across tasks, the system can abstract these patterns into more stable procedural units. In this sense, memory preserves experience, while skill induction extracts the reusable structure within it. Existing evidence supports this most directly when the process is framed as induction from interaction traces rather than as a broad claim that memory automatically becomes skill. Skill Set Optimization, for instance, extracts transferable skills from rewarding sub-trajectories ( Nottingham et al., 2024 ) . In memory-management settings, MemSkill further shows that some memory operations themselves can be reformulated as learnable and evolvable skills ( Zhang et al., 2026a ) .

##### Discovered.

Beyond manual authoring and post hoc distillation, agents may also autonomously discover new skills through environmental interaction. Voyager provides an influential example in the Minecraft setting, where exploration, execution feedback, self-verification, and curriculum-driven task selection jointly produce an ever-growing skill library of executable code ( Wang et al., 2023a ) . More recent work suggests that this discovery process can also be oriented toward generalization. PolySkill, for example, improves skill reuse by separating abstract goals from concrete implementations ( Yu et al., 2025 ) . Once an agent can identify behavioral patterns that repeatedly succeed and elevate them into explicit skills, the skill library becomes not only a storage layer but also a mechanism for capability growth.

##### Composed.

Finally, skills can evolve through composition. Many higher-level capabilities are not invented from scratch, but assembled from existing lower-level or mid-level skills. A complex workflow such as report generation or code repair may emerge from the repeated coordination of smaller capabilities. Composition matters here not only as an execution strategy but also as an acquisition mechanism. Once a particular combination of existing skills is repeatedly validated as effective, that combination can itself be packaged as a new higher-level skill. In this way, composition generates new reusable units and gradually gives rise to hierarchical skill repertoires rather than flat lists of isolated capabilities ( Wang et al., 2025c ) .

Overall, skill acquisition is not a one-time design step but a continuing process of writing, extracting, discovering, and recomposing procedural knowledge. A mature skill system is therefore defined less by how many instructions it stores than by how effectively it turns experience into reusable externalized expertise. In a harnessed agent, this evolutionary loop is itself systematized: memory provides the evidence, evaluators decide what merits promotion, and protocolized execution surfaces determine whether a candidate skill can actually be deployed.

### 4.5 Boundary Conditions

Skill externalization improves reuse and governance, but it does not guarantee reliability. Once procedural expertise is externalized as an explicit artifact, its effectiveness becomes conditional on how well the artifact matches the task, the environment, and the runtime in which it is used. In practice, the main boundary conditions concern semantic alignment, portability and staleness, unsafe composition, and context-dependent degradation.

##### Semantic alignment.

A skill specification expresses intent and guidance in natural language or lightweight structured form, while actual execution depends on concrete tools, APIs, and environmental constraints. As a result, a model may follow the literal wording of a skill while still missing the real objective of the task. Existing evidence suggests that the effectiveness of skills depends heavily on the alignment between task intent, skill description, and invocation decision. SkillProbe identifies semantic-behavioral inconsistency as a fundamental flaw in existing skill marketplaces ( Guo et al., 2026 ) . Related work on tool-use decision making likewise shows that the key difficulty is often not only whether an external capability can be called, but whether it should be called under the current interpretation of the task ( Ross et al., 2025 ) . This suggests that externalized skills remain sensitive to mismatches between description and use.

##### Portability and staleness.

Even when a skill is internally coherent, its validity across environments cannot be assumed. Changes in websites, APIs, dependencies, workflows, or runtime conventions can make a once-effective skill partially misleading or entirely obsolete. More broadly, heterogeneity across agent frameworks, tool substrates, and base models means that the same skill may not behave consistently across settings. Programmatic-skill work already shows that some induced skills transfer across websites while incompatible ones must be updated to accommodate environmental change ( Wang et al., 2025c ) . SkillsBench further indicates that skill utility varies substantially across domains and model-agent configurations ( Li et al., 2026c ) . The broader implication is that skill portability is best treated as a conditional empirical property rather than an intrinsic feature of externalization.

##### Unsafe composition.

Composition makes skills more powerful, but it also creates new risks. Skills that appear harmless in isolation may interact unsafely when combined, especially when they bundle long-form instructions, executable scripts, and external dependencies. In such cases, the problem is not confined to a single skill artifact, but emerges from the interaction among multiple artifacts and the interfaces that connect them. This is one of the boundary conditions for which direct evidence is now available. Large-scale empirical studies of public skill ecosystems report substantial rates of vulnerabilities, including prompt injection, data exfiltration, privilege escalation, and supply-chain risk ( Liu et al., 2026 ) . Attack-oriented studies further show that skill files themselves can become realistic prompt-injection surfaces for current agents ( Wang et al., 2026c ) . Skill composition should therefore be treated as a security-sensitive process rather than a purely benign form of modular reuse.

##### Context-dependent degradation.

A further difficulty is that skill execution can degrade over extended interaction. Even when a skill file has been updated, the agent may continue to follow outdated operational logic because of residual session context, cached summaries, or previously reinforced action patterns. At the same time, detailed skill guides can interfere with global task tracking when too much local procedural detail is injected into the context. In such cases, the model may execute the instructions carefully while losing sight of the true success condition. Direct skill-specific evidence for these effects is still limited, but adjacent work on multi-turn drift, long-horizon reliability, and long-context reasoning strongly suggests that they are realistic boundary conditions ( Lee, 2026 ) . Skill loading should therefore be treated not only as a retrieval problem, but also as a problem of context allocation and execution stability.

Taken together, these boundary conditions show that a skill is not a self-sufficient module that remains stable once written. Its effectiveness depends on continued alignment with tasks, environments, runtime conditions, and security constraints. Skills should therefore be treated not as isolated artifacts, but as components embedded in a broader engineering framework. This is precisely why skill design ultimately points beyond the artifact itself toward harness engineering.

### 4.6 Skills in the Harness

The boundary conditions above show that skills cannot be evaluated as standalone artifacts. Their reliability depends on how they are situated within a running system. This section examines how skills become operational once embedded in a harness, focusing on the couplings that connect them to memory, protocols, and runtime governance.

##### Conditioning on memory.

A skill is selected and parameterized in light of retrieved state. The harness queries memory for task history, prior outcomes, user-specific context, and environmental constraints, then uses that evidence to decide which skill to load, which parameters to instantiate, and which branches to prefer. Without this conditioning loop, skill selection degenerates into keyword matching against task descriptions. With it, the same skill can be applied differently depending on what the agent has previously learned. Memory therefore supplies the situational evidence that makes skill choice contextual rather than generic.

##### Binding through protocols.

Once selected, a skill must be grounded in executable action. That grounding passes through protocolized interfaces: tool schemas, subagent delegation contracts, file operations, and approval workflows. The harness mediates this binding by resolving which protocol endpoints are currently available, checking permissions, and routing skill steps to the appropriate execution substrates. Skills and protocols are therefore complementary: skills specify what should be done; protocols specify how the resulting actions are described, invoked, and governed.

##### Runtime governance.

In production settings, the harness also imposes governance over skill execution. This includes permission checks before sensitive operations, approval gates for high-risk steps, audit logging of which skill was loaded and what actions it produced, and rollback mechanisms when execution fails partway through a multi-step procedure. These controls are not part of the skill artifact itself; they are properties of the harness environment in which the skill runs. A skill that is safe and effective in a sandboxed development context may require additional constraints in a production deployment, and the harness is the layer that enforces those constraints.

##### Lifecycle feedback.

Finally, the harness closes the loop between skill execution and skill evolution. Execution traces, success rates, failure patterns, and user corrections are written back into memory. Over time, that evidence may trigger skill revision, deprecation, or the promotion of new candidate skills. The harness therefore does not merely host skills; it provides the feedback infrastructure through which skills improve. This loop connects skill acquisition (Section 4.4) to runtime operation: authored or discovered skills enter the harness, the harness governs their execution, and execution outcomes feed back into the evidence base from which future skills are derived.

### 4.7 Skill as Cognitive Artifact

The following interpretation is primarily theoretical rather than directly empirical. It draws on classic work on cognitive artifacts to help explain why externalized skills can improve the organization of procedural expertise, rather than to claim that these theories were originally developed for LLM agents.