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

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

The representational shift introduced by skills is therefore from repeated synthesis to reusable procedure. Instead of asking the model to regenerate task-specific know-how from weights or ad hoc prompts on every run, a skill system packages that know-how into explicit artifacts that can be discovered, loaded, revised, and composed. This does not mainly expand the set of actions available to the agent; it changes the task the model faces at runtime from inventing a workflow to selecting and following one ( Xu and Yan, 2026b ; Wang et al., 2026a ) .

In harnessed agents, skills sit between memory and action. They are often selected in light of retrieved state, bound to tools and subagents through protocolized interfaces, and updated from execution traces and post hoc reflection. As discussed in Section 3 , memory externalizes what has been learned over time; skills externalize how that accumulated experience becomes a reusable operating structure ( Sumers et al., 2024 ; Wu and Zhang, 2026 ) . The chapter therefore focuses on three linked questions: what burden skills externalize, how skills reorganize task execution, and how they become actionable inside a larger harness.

### 4.1 What is Externalized: Procedural Expertise

Skill externalization concerns procedural expertise rather than isolated action interfaces. Expertise here means a repeatable way of carrying out a task under recurring assumptions and constraints, not a vague claim that the model “can” do something. A useful boundary follows from that definition: tools expose operations, protocols govern how those operations are described and invoked, and skills encode how a class of tasks should be executed with them. In practice, that expertise has three coupled components: operational procedures , decision heuristics , and normative constraints . Together they define the reusable unit of know-how that a harness can externalize.

#### 4.1.1 Operational Procedure

Operational procedure is the task skeleton: the decomposition of a complex job into steps, phases, dependencies, and stopping conditions. It addresses a common failure mode in LLM agents. Many errors do not come from incapacity at the action level; they come from instability at the process level, such as skipped steps, misordered operations, or premature termination ( Hsiao et al., 2025 ; Nandi et al., 2026 ) . Externalizing procedure turns that fragile process knowledge into an explicit operating path.

This shift has deep roots in the broader evolution of LLM reasoning. Chain-of-Thought made intermediate reasoning explicit ( Wei et al., 2023 ) ; ReAct coupled reasoning with action ( Yao et al., 2023a ) ; later prompt-chaining and orchestration systems packaged recurring patterns into engineered workflows. What those approaches often lacked was persistence. The procedure existed in the current run, but not yet as a reusable artifact. Skill systems close that gap by turning workflow structure into something that can be stored, revised, and reapplied ( Ye et al., 2025 ) .

Once procedures are externalized, execution becomes less improvisational. The agent can resume after interruption, hand work across contexts or collaborators, and recover state without reconstructing the entire workflow from memory. This matters most in long-horizon, multi-agent, and production settings, where process stability is often more important than momentary fluency.

#### 4.1.2 Decision Heuristics

If procedures define the skeleton of execution, decision heuristics govern what happens at branches. Real tasks rarely unfold as fixed pipelines. Tools fail, observations are noisy, and several locally plausible actions may compete. Under those conditions, good performance depends on practical rules of thumb derived from experience rather than on exhaustive search alone ( Gigerenzer and Gaissmaier, 2011 ) .

Externalizing those heuristics changes the distribution of reasoning effort. Instead of forcing the model to rediscover local policy at every junction, the system can encode default choices, escalation rules, or preference orderings that have already proved useful. That reduces deliberation cost and also makes behavior more stable. Heuristics are therefore not a secondary convenience. They are one of the main ways a skill captures expert style: what to try first, when to back off, what evidence is sufficient, and which trade-offs are preferred when multiple paths remain viable.

#### 4.1.3 Normative Constraints

The third component is normative constraint: the conditions under which a procedure counts as acceptable. A workflow may be technically effective and still be noncompliant, unsafe, or operationally wrong. In real deployments, execution is bounded by testing requirements, scope limits, access restrictions, traceability expectations, and domain-specific operating rules ( Chen et al., 2021 ; Bai et al., 2022b ; Wei et al., 2023 ; Schick et al., 2023 ; Madaan et al., 2023 ) .

Once externalized, those constraints stop being merely post hoc evaluation criteria and become part of the skill itself. They can shape preconditions, block unsafe branches, require intermediate validation, or define evidence that must be produced before completion. This is what lets skills encode not only how to perform a task, but also how to perform it within organizational and safety boundaries. In mature systems, that makes skills carriers of governance as much as carriers of capability.

Taken together, operational procedures provide structure, decision heuristics provide local policy, and normative constraints provide acceptable boundaries. A skill is reusable only when all three are specified well enough to survive across tasks, contexts, and runs. That is why skills sit above action interfaces and beside memory: they externalize not past state and not raw execution primitives, but repeatable task know-how.

### 4.2 From Execution Primitives to Capability Packages

Skill systems do not emerge in isolation, but they should also not be conflated with tool use. Historically, skills are downstream of two earlier developments: reliable action invocation and large-scale action selection. Those stages expanded what an agent could do , but not yet how a class of tasks should be carried out repeatedly. Skills appear only when procedural organization itself becomes an explicit reusable artifact.

#### 4.2.1 Stage 1: Atomic Execution Primitives

The first stage equips language models with reliable action execution, for example through structured tool invocation and function-calling interfaces. Toolformer is representative in showing that models can learn when to call tools, how to construct arguments, and how to incorporate results ( Schick et al., 2023 ) . The key achievement at this stage is stable access to atomic action units. What it does not provide is an explicit reusable procedure for completing a broader class of tasks. The unit is the action primitive, not the skill.

#### 4.2.2 Stage 2: Large-scale Primitive Selection

As the number of callable tools grows, the problem shifts from invocation to selection. Work such as Gorilla, ToolLLM, ToolNet, ToolScope, and AutoTool shows that models can retrieve, rank, and dynamically choose among large tool collections ( Patil et al., 2023 ; Qin et al., 2023 ; Liu et al., 2024b ; Liu et al., 2025b ; Zou et al., 2025 ) . This is a major step toward scalable action selection, but the unit remains the tool rather than the procedure. Even when multi-step behavior begins to emerge, the know-how for accomplishing a task class is still largely implicit in prompts or parameters rather than externalized as a bounded reusable artifact.

#### 4.2.3 Stage 3: Skill as Packaged Expertise

The third stage marks a further shift in abstraction. The central question is no longer whether a model can invoke a function or retrieve an appropriate API, but whether the know-how required to complete a class of tasks can be packaged into reusable capability units. In this stage, the fundamental unit of capability is no longer an isolated tool call, but a higher-level artifact centered on reusable procedural guidance and execution structure ( Wang et al., 2025c ; Chen et al., 2026b ) . Rather than merely specifying what can be done, a skill increasingly captures how a task should be carried out through reusable procedural organization ( Li et al., 2026c ) .

Recent work makes this transition increasingly explicit. Program-based skill induction compiles primitive actions into higher-level reusable skills, showing that agent capabilities can be represented as executable procedural abstractions rather than one-off invocations ( Wang et al., 2025c ) . In web environments, interaction trajectories can be distilled into reusable skill libraries or skill APIs, allowing agents to accumulate and refine transferable know-how across tasks ( Zheng et al., 2025a ) . In computer-use settings, skills are further organized as parameterized execution and composition graphs, with retrieval, argument instantiation, and failure recovery operating at the skill level rather than the level of individual interface actions ( Chen et al., 2026b ) . Related work on SOP-guided agents likewise shows that domain expertise can be externalized as explicit procedural structures that guide execution according to domain-specific procedures ( Ye et al., 2025 ) .

Compared with earlier stages, the key transformation here is representational rather than merely operational. Capability is no longer treated primarily as access to tools or APIs, but increasingly as packaged procedural knowledge that can be loaded, reused, and composed across tasks ( Li et al., 2026c ; Xu and Yan, 2026b ) . In this sense, Stage 3 does not simply make tool use more complex, but it reflects a shift toward representing agent capability as externalized and reusable procedural know-how.

### 4.3 How Skills Are Externalized

Skill externalization is not exhausted by writing down instructions. In mature agent systems, the crucial issue is whether procedural expertise can be represented in a form that is discoverable, loadable, interpretable, bindable, and executable at runtime. Therefore, skill externalization involves both a representational layer and a runtime layer. The former determines how a skill is described and delimited, while the latter determines whether it can actually function as a reusable capability during task execution ( Xu and Yan, 2026b ) . In harness terms, a skill only becomes real when the runtime can decide when to load it, which memory to condition it on, and which tools, files, or subagents to bind it to. That binding requirement does not make skills identical to tools or protocols; it simply means that procedural expertise must eventually be grounded in executable interfaces.

#### 4.3.1 Specification

The externalization of a skill begins at the specification layer. Typical forms include SKILL.md , instruction files, manifests, or other declarative specification artifacts. These artifacts describe what a skill does, what scenarios it applies to, what dependencies it assumes, what constraints it must satisfy, and under what input-output conditions it should operate. A skill specification resembles API documentation more than API implementation. Its value lies in turning procedural expertise from an opaque internal state into an explicit object that can be inspected, discussed, revised, and governed ( Ling et al., 2026 ) .

A well-formed skill specification should ideally cover at least five kinds of information, namely capability boundaries, scope of applicability, preconditions, execution constraints, and examples together with counterexamples. The first two clarify what kinds of problems the skill is intended to solve. The next two clarify when it can be used safely and under what operating assumptions. The final category helps anchor the intended usage pattern in concrete cases, thereby reducing underspecified interpretation by the model. Through such structured specification, a skill is elevated from an unstructured prompting trick to a bounded capability description, which in turn provides the foundation for discovery, loading, version control, and governance.

#### 4.3.2 Discovery

Once skills become explicit artifacts, they naturally introduce the problem of registration and discovery. In realistic settings, an agent cannot indiscriminately load every available skill for every task. It therefore requires some form of registry and discovery mechanism to support selective retrieval. A skill may be published to a local repository, an organizational registry, or a platform-level marketplace, while the agent searches for relevant candidates based on task goals, context state, and environmental conditions ( Zheng et al., 2025a ) .

This discovery process may rely on semantic retrieval, structured metadata, task decomposition, or combinations of these strategies, depending on the system design. The key point is that the system is not merely asking which tool can be called. It is asking which unit of procedural expertise is appropriate for the present problem. This makes skill discovery a higher-level matching problem. It must consider not only topic similarity, but also task complexity, environmental assumptions, operational constraints, and risk conditions. A skill should therefore be retrieved not simply because its keywords overlap with the task description, but because it is genuinely compatible with the semantic and operational structure of the current task ( Ross et al., 2025 ) . Skill externalization is incomplete if a skill is merely stored. It must also be retrievable under realistic task conditions.

#### 4.3.3 Progressive Disclosure

The discovery of a skill does not imply that its full contents should immediately be injected into the active context. Because long context does not reliably translate into better performance, detailed instructions can become a source of reasoning noise rather than a source of guidance. For this reason, current skill systems often benefit from a progressive disclosure strategy in which the existence of a skill is exposed first, and deeper detail is loaded only when needed ( Xu and Yan, 2026b ) .

In current industrial implementations, this often takes a layered form. At a minimal level, the model sees only the name of the skill together with a brief description, which is sufficient to signal that the capability exists. A deeper level may expose manifest-like information such as applicability conditions, required prerequisites, and major constraints. Only at the deepest level does the system load the full guide, including detailed procedures, exception handling, examples, and supporting files. The purpose of such staged loading is not simply to compress documentation. More fundamentally, it turns the question of whether more skill detail is needed into a runtime decision in its own right. In this way, the informational density of the skill can be matched to the complexity of the current task rather than saturating the context with unnecessary detail from the outset. This design is especially visible in current industrial implementations of skills, such as Claude Code’s skill system ( Anthropic, 2025 ) .

#### 4.3.4 Execution Binding

A skill remains a cognitive-level description unless it is connected to executable action. Actual task completion therefore depends on a binding process that translates the natural-language or structured specification of a skill into concrete operations in the current environment. It is precisely at this point that the distinction between skills, tools, and protocols becomes clear.