A Bounded Memory System, Not an Autonomous Oracle

AutoHarness is best understood as an attempt to make procedural memory governable inside Claude Code. The final question is not whether it can make an agent remember an instruction, and not even whether it can make the agent correct. The useful question is whether a correction can travel through a bounded, inspectable loop—learning from work, passing a controlled write boundary, returning through a recall surface, and generating enough evidence for its own maintenance. That is the standard this series supports for deciding whether the design is worth adopting.

The control loop is the product

A developer's testing correction shows why the parts belong together. An agent writes parameterized tests but omits readable identifiers for the cases. The developer explains the repository convention and asks for a correction. In an ordinary session, that exchange has immediate value and uncertain future value. It may disappear when the session ends, or it may be saved as a note that never reaches the agent at the moment of a related task.

AutoHarness gives the correction a path. Work activity closes an episode boundary; capture retains a bounded, redacted slice; reflection interprets the slice and compares it with the existing skill library; stage_skill places a proposal in a durable queue; the promoter decides whether the proposal is allowed to change a live, self-authored skill; session-start recall gives the rule a chance to enter a later task; use, view, and patch signals describe what happens next; lifecycle and curator passes keep both the individual entry and the larger library within bounds.

That chain is more important than any one component name. Capture does not need to decide whether the testing convention is wise. Reflection does not need filesystem authority. Promotion does not need to understand every nuance of the task in order to reject unsafe structure or unauthorized ownership. Recall does not need to prove that the rule is correct. Lifecycle does not need to claim that a low-use skill is false. Each boundary narrows one problem so that the system does not ask one model response or one counter to answer every question at once.

The result is a particular kind of memory. It is not a hidden model update, because the learned rule remains a human-readable skill. It is not a transcript archive, because the active body is kept at rule altitude and the detail sits in evidence or support material. It is not a static documentation folder, because the library can be patched, consolidated, measured, and archived in response to later work. AutoHarness is trying to make memory change without making change opaque.

The loop also explains why the design begins and ends with ownership. A correction can be specific to one project, while a general technique may belong more broadly. The project and global layers give those scopes different blast radii. The self-authored marker prevents the plugin from treating the host's entire existing skill collection as its property. The operator can therefore ask not only “what did the system learn?” but also “where is this lesson allowed to act?” A memory that is correct in one repository can still be wrong as a global instruction.

The same structure makes failures diagnosable. If the episode never closes, the lesson was not captured. If the bounded handoff omits the relevant context, reflection may produce a weak proposal. If the proposal is rejected, the live tree should remain unchanged and the run account should say why. If the skill lands but is never surfaced, storage succeeded while recall failed. If it is surfaced and viewed but not loaded, visibility occurred without formal adherence. If it is merged, archived, or restored, the ledger and sidecar should preserve that history. The loop turns one vague failure—“the agent forgot”—into several different conditions that can be tested and repaired.

flowchart TD Learn["Correction in real work"] --> Capture["Bounded and redacted episode"] Capture --> Propose["Model proposes a reusable lesson"] Propose --> Write["Queue and deterministic write authority"] Write -->|accepted| Recall["Owned skill and recall surface"] Write -->|rejected| Account["Visible rejection account"] Recall --> Signals["Use, view, and patch evidence"] Signals --> Maintain["Lifecycle and curator maintenance"] Maintain --> Recall Maintain --> Archive["Reversible archive"] Signals --> Decide["Operator outcome judgment"] Decide --> Validate["Open validation: correctness, integration, security"]