Enhancing LLM Agent Reliability Through Externalization
==Externalization enhances LLM agent reliability by moving fragile “in head” burdens (remembering, consistently executing procedures, and coordinating with tools/others) into persistent, explicit, governed infrastruct...
==Externalization enhances LLM agent reliability by moving fragile “in head” burdens (remembering, consistently executing procedures, and coordinating with tools/others) into persistent, explicit, governed infrastructure that reshapes the task into something the model can solve more reliably.==[:cite[2]{ln=4}][:cite[3]{ln=2}][:cite[3]{ln=5}][:cite[1]{ln=1}] 1) Reliability via representational transformation (change the task, not the model) Externalization is framed as a shift where infrastructure “transforms hard cognitive burdens into forms that the model can solve more reliably,” rather than merely adding components.[:cite[2]{ln=4}] This mirrors the cognitive artifact idea that an external aid can transform a difficult internal problem into an easier one (e.g., recall → recognition), making the same underlying cognitive capacity succeed more reliably.[:cite[4]{ln=2}][:cite[4]{ln=4}][:cite[4]{ln=6}] 2) Reliability via externalized memory (fixes continuity failures) Unaided LLMs have finite context windows and weak/absent session memory, creating a continuity problem.[:cite[3]{ln=2}] Memory externalization addresses the “temporal burden of agency” by relocating continuity, prior experience, user facts, and partial work from “an ephemeral prompt” into persistent state that can be written/updated/retrieved outside the model.[:cite[5]{ln=1}][:cite[5]{ln=2}][:cite[5]{ln=4}] 3) Reliability via externalized skills (reduces variance in long procedures) For multi step work, LLMs often “rederive” procedures instead of executing them consistently, creating a variance problem.[:cite[3]{ln=3}] Skill externalization targets this procedural burden: instead of reconstructing workflows/defaults/constraints every time, the agent can rely on externalized procedural expertise, reducing failures like “omitted steps, unstable tool use, and inconsistent stopping conditions.”[:cite[6]{ln=2}][:cite[6]{ln=3}][:cite[6]{ln=4}] 4) Reliability via externalized protocols (turn coordination into contracts) Tool/service collaboration is “brittle when left to free form prompting,” which is described as a coordination problem.[:cite[3]{ln=4}] Externalizing interaction rules into protocols converts ambiguous coordination into “governed contracts,” helping interactions become more deterministic and machine interpretable rather than ad hoc.[:cite[1]{ln=4}][:cite[7]{ln=4}] 5) Reliability via harness engineering (explicit control, constraints, observability, feedback) The paper argues many “largest gains in reliability” come not from changing the base model, but from changing the environment: “standardizing tool interfaces, constraining execution, instrumenting behavior, and routing work through explicit control logic.”[:cite[8]{ln=4}][:cite[8]{ln=5}] Harness engineering is presented as the unification layer that coordinates memory/skills/protocols into “governed execution.”[:cite[2]{ln=5}] It also explicitly relocates runtime reliability into harness logic, where “constraints, observability, and feedback loops can be made explicit.”[:cite[1]{ln=5}]