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

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

From the perspective of Norman’s theory of cognitive artifacts, a skill system can be understood as a representational transformation along the dimension of capability organization ( Norman, 1993 ) . Without externalized skills, a model must repeatedly reconstruct procedural knowledge from internal parameters during task execution. With skills, part of that procedural burden is moved into an explicit external representation that can be loaded, inspected, and followed. This shifts the task from unstable latent procedural recall toward a more stable process of recognizing applicable guidance and acting under it. In that respect, the role of a skill file is closely analogous to Norman’s analysis of how an external list changes the nature of remembering. The crucial point is not simply that extra information has been added. It is that the form of the cognitive task itself has been reorganized.

This reorganization matters because it changes what the model must do at inference time. In the absence of a skill, the model must probabilistically recover an appropriate way of proceeding from its parameters under the pressure of the current context. Once the skill has been externalized, the procedural structure is already present as an object in the environment. The model’s burden shifts toward interpreting the current situation, recognizing whether the skill applies, following the relevant guidance, and handling local exceptions. Procedural knowledge is therefore no longer something that must be reconstructed from scratch on each run. It becomes an external object that can be operated on directly ( Li et al., 2026c ; Xu and Yan, 2026b ) .

This interpretation also aligns with Kirsh’s notion of complementary strategies, according to which agents improve performance not only by thinking harder internally, but also by reorganizing the external environment so that some cognitive work is offloaded into it ( Kirsh, 1995 ) . LLMs are often not especially reliable at reproducing long multi-step procedures in a stable and repeatable manner. The same prompt may yield different decompositions, branching decisions, or stopping conditions across runs. By contrast, they are comparatively better at reading explicit guidance, matching it to the current context, and adapting execution locally under stated constraints. A skill can therefore be understood as an engineered complementary strategy. It externalizes procedure definitions, constraints, and portions of best practice into an artifact, while leaving interpretation, contextual matching, and exception handling to the model itself.

A skill does not simply add more information to the system. It changes how capability is organized. Procedural expertise is moved out of an opaque and difficult-to-audit parameter space into an inspectable, revisable, and composable external structure. That is why the significance of skills lies not merely in engineering convenience, but in a deeper reallocation of where know-how resides and how it becomes available for reuse. Seen in this light, skills are better understood not simply as prompts or tool wrappers, but as cognitive artifacts for organizing procedural competence in agent systems. At system scale, they externalize procedural burden by converting repeated workflow invention into selection, loading, and composition under runtime control.

## 5 Externalized Interaction: Protocols

Protocols externalize the interaction burden of agency. A bare model may infer that a tool should be called, a subagent should be delegated to, or a response should be shown to a user, but without explicit contracts it must also improvise message formats, argument structure, lifecycle semantics, permissions, and recovery behavior. That burden turns every external action into a fragile prompt-following exercise.

Within a harness, this protocol layer is where interaction becomes governable. It mediates how tools are discovered, how subagents are contacted, how user-facing state is exposed, how session progress is represented, and how permissions and failures are enforced. A protocol is therefore not a memory store and not a skill description: it specifies the contract by which state, requests, and actions move across system boundaries. The present section therefore examines what interaction burdens protocols externalize, why that externalization matters, how the current protocol landscape is organized, how protocols become operational inside a harness, and how the resulting transformation can be understood through the lens of cognitive artifacts. Section 6 identifies the content of interaction that is externalized; Section 5.1 motivates the benefits; Section 5.2 surveys the protocol families; Section 5.3 examines harness-level integration; and Section 5.4 closes the chapter with a cognitive-artifact interpretation.

If memory externalizes temporal state and skills externalize procedural expertise, protocols externalize the contracts that govern how an agent exchanges information and actions with entities outside itself. The representational shift is from free-form communicative inference to structured exchange. Instead of asking the model to invent the syntax and semantics of interaction at runtime, protocols provide typed surfaces, state transitions, and machine-readable constraints that the model can fill and follow. In that sense, protocols do not merely accelerate communication; they change the task from negotiating ad hoc interfaces to operating within explicit contracts.

More concretely, what protocols externalize can be organized along four dimensions:

##### Invocation grammar.

Every tool call, API request, or delegation message requires a format: argument names, types, ordering, and return structure. Without protocols, the model must infer or reinvent this grammar on each call. Protocols externalize it into schemas and typed interfaces, so the model fills fields rather than guessing syntax.

##### Lifecycle semantics.

Multi-step interactions need coordination: who acts next, what state transitions are allowed, when a task is complete or has failed. Protocols externalize these sequencing rules into explicit state machines or event streams, removing them from the model’s inferential burden.

##### Permission and trust boundaries.

Real-world agent actions are bounded by who is authorized, what data may flow where, and what evidence must be produced. Protocols externalize these constraints into inspectable rules that a runtime can enforce, rather than relying on the model to self-police.

##### Discovery metadata.

Before an agent can interact with a tool or another agent, it must know what capabilities are available and how to reach them. Protocols externalize this discovery problem into registries, capability cards, and schema endpoints, replacing implicit prompt-embedded knowledge with queryable metadata.

These four dimensions are not independent—a single protocol may address several at once—but they clarify the scope of what is being externalized. Tools expose operations; skills encode how classes of tasks should be carried out with those operations; protocols specify the interaction grammar, lifecycle, permissions, and discovery mechanisms through which operations and skills become executable across system boundaries.

### 5.1 Why Protocols Matter

The importance of Agent Protocols follows directly from the burden they externalize: without them, every interaction is partly an inference problem about format, legitimacy, and coordination. Their benefits are easiest to see along three dimensions.

##### Unified interaction standards.

Protocols give tools, agents, and frontends a shared grammar for discovery, invocation, handoff, and state exchange. Without that layer, the ecosystem fractures into local prompt-plus-parser integrations that do not travel well across runtimes ( Yang et al., 2025a ) . Standardized interaction makes interoperability a designed property rather than a fortunate accident ( Ehtesham et al., 2025a ) . It is also the precondition for stable multi-agent collaboration, because delegation and context transfer need common representations before they can be automated.

##### Improved security, governance, and auditability.

Once agents operate in real environments, the question is not only whether they can act, but whether those actions remain bounded, inspectable, and recoverable ( Phiri, 2025 ) . Protocols help by making permissions, identity, execution traces, failure states, and responsibility boundaries explicit. That turns previously implicit glue logic into something a runtime can validate and an operator can audit.

##### Reduced vendor dependence.

Open interaction contracts also preserve architectural flexibility. If the system accumulates capability at the protocol layer rather than inside provider-specific interfaces, models, vendors, and runtime components can be swapped with less rewiring. Protocols are therefore not only engineering conveniences; they are part of the mechanism by which an agent ecosystem remains portable and evolvable over time ( Yang et al., 2025a ) .

### 5.2 Agent Protocol Survey

In this section, we classify popular Agent Protocols in the community into agent-tool, agent-agent, agent-user, and other protocol families according to the different entities they are designed to interact with, and briefly introduce several representative and commonly used protocols in each category. The purpose of this survey is not to catalogue every emerging standard, but to show that contemporary protocols externalize different slices of interaction burden: some stabilize tool invocation, some stabilize delegation among agents, some stabilize the agent-user boundary, and some govern high-risk vertical workflows.

#### 5.2.1 Agent-Tool Protocols

Agent-Tool Protocols were among the earliest protocol families to mature because tool access is where interface fragmentation appears first. MCP ( Anthropic, 2024 ) is the clearest representative. It provides a standardized way for agents to discover tools, inspect their schemas, and invoke them across heterogeneous services. The problem it addresses is straightforward: without a shared contract, every new tool requires bespoke integration logic, duplicated schema definitions, and provider-specific adaptation.

The boundary with neighboring layers is important. MCP and related protocols specify how tools are described and invoked; they do not specify which multi-step procedure should be followed with those tools, and they do not themselves preserve cross-session cognition once results have been produced. Those roles belong to skills and memory respectively.

Architecturally, MCP turns tool access into protocol-based integration rather than interface-by-interface engineering. Servers expose tools and context resources through a common structure, typically over JSON-RPC 2.0, while clients perform discovery and invocation against that shared specification. This decouples tool ecosystems from model-provider-specific function-calling formats and lowers the cost of adding new capabilities. The practical gains are straightforward: dynamic capability discovery, standardized access to complex external systems, structured request/response exchange, and modular extensibility.

The same separation also improves governance. Because invocation is mediated by a protocol layer rather than emitted as an unconstrained model-generated call, sensitive data handling, permission checks, and audit boundaries can be managed more explicitly. ToolUniverse and related systems extend this logic with more specialized tool schemas and interaction conventions ( Gao et al., 2025b ; Gao et al., 2025a ) . The broad point is that agent-tool protocols externalize invocation grammar so that tool use becomes portable, inspectable, and scalable rather than an accumulation of bespoke adapters.

#### 5.2.2 Agent-Agent Protocols

As soon as multiple agents collaborate, interaction itself becomes a systems problem. Agent-Agent protocols define how capabilities are discovered, how tasks are delegated, how progress and partial state are exchanged, and how results return to the caller. They externalize coordination that would otherwise be buried in prompt conventions or framework-specific glue.

A2A ( Google, 2025a ) is the most visible current example. It standardizes capability discovery through artifacts such as Agent Cards and supports task-oriented communication, state updates, negotiation, and streaming progress between heterogeneous agents. Its importance is not only that agents can message one another, but that delegation becomes structured: the caller can discover what another agent offers, hand off work under a known contract, and track execution without relying on hard-coded assumptions.

Other protocols make different trade-offs. ACP ( IBM Research, 2025 ) emphasizes lightweight adoption through familiar REST/HTTP patterns and fits settings where compatibility with existing services matters more than rich negotiation. ANP ( Chang et al., 2025 ) pushes in the opposite direction, aiming at open, Internet-scale interoperability with decentralized identity, cross-domain discovery, and secure end-to-end communication.

Taken together, these protocols show that multi-agent systems need more than message transport. They need standardized semantics for delegation, identity, status, and handoff. That is what lets coordination scale from local orchestration to open agent ecosystems ( Yang et al., 2025a ; Ehtesham et al., 2025b ) .

#### 5.2.3 Agent-User Protocols

Agent-User Protocols formalize the boundary between agent runtimes and user-facing systems. They address a different problem from tool or agent-agent protocols: not how an action is executed elsewhere, but how execution state, outputs, and interface structure are exposed to humans in a form that frontends can render and users can understand ( Google, 2025b ; CopilotKit, 2025 ) .

A2UI ( Google, 2025b ) represents the interface-generation branch. It lets an agent describe UI structure in a constrained declarative format that host applications can render safely across platforms. The protocol matters because it treats interface construction itself as governed output rather than arbitrary HTML-like text.

AG-UI ( CopilotKit, 2025 ) represents the streaming-state branch. It standardizes typed execution events such as run start, text emission, tool call arguments, tool call results, completion, and error. Frontends can subscribe to that event stream and render runtime status without learning each framework’s private event format.

These two directions are complementary. A2UI externalizes interface composition; AG-UI externalizes the live state transitions behind that interface. Together they show how protocolization makes human-agent interaction more observable, reusable, and portable across hosts.

#### 5.2.4 Other Protocols

Beyond general interaction families, some protocols target high-risk vertical workflows where generic interfaces are not enough. UCP ( Google, 2026 ) does this for agentic commerce by standardizing catalogs, requests, and checkout flows so that agents, merchants, and payment providers can interoperate without bespoke integration for every store. AP2 ( Google Cloud, 2025b ) does the same for payments, emphasizing authorization, signatures, auditability, and proof-bearing transaction objects such as IntentMandate, PaymentMandate, and PaymentReceipt.