01 / Brief
Experience should
change the next attempt.
Muscle Memory explores how real tool-use episodes can become useful procedural guidance. Built around Letta agents, it connects remembered methods, observed actions and explicit outcome checks rather than treating every fluent retrospective as a lesson.
Why it matters
The core design problem is evidence: distinguish recording an experience, delivering a relevant method, applying it and checking its effect. Those are separate events. Making that distinction visible is as important as the memory itself.
My scope
Independent product design, Letta-native tooling and an evidence-led research programme, developed with my agent collaborators. The mod’s operational behaviour and the research’s causal claims are deliberately kept separate.
02 / Decisions
The choices behind
the experience.
- 01
Record the work, not just the story.
Tool activity and explicit closes form an inspectable episode. Unreported work is not silently converted into a successful learning event.
- 02
Improve existing guidance first.
Distillation, deduplication, sanitisation and review are used to keep the skill shelf useful instead of growing a second junk drawer.
- 03
Separate a held check from improvement.
A file check can establish that an artifact exists. It cannot, by itself, establish that memory caused a better result. Product and research claims need evidence appropriate to their scope.
03 / Craft
Inside the learning contract
The product and the research ask related but different questions. Can an agent use a relevant method in real work? And what evidence would show that the method actually helped?
- 01
Observe
Record the actual attempt and its tool evidence.
- 02
Match
Deliver relevant procedural guidance, or abstain.
- 03
Act
Distinguish seeing a method from applying it.
- 04
Check
Close the episode with an honest outcome and bounded effect checks.
A mod, not just a document library.
The installed workflow exposes recall and close tools, connects to the agent’s lifecycle, and shows the current episode in the terminal UI. The point is to make useful guidance available where the work happens—not require the agent to browse a growing folder and hope it finds the right note.
The episode is the unit of accountability.
A stored method, a delivered suggestion, an actual application and an observed effect are recorded as different things. A successful tool response is not silently treated as a successful real-world outcome, and a loaded skill does not automatically earn reuse credit.
A held check has a narrow meaning.
For example, a file-content check can establish that a specified artifact contains a specified value. It does not establish that the memory system caused an improvement. Keeping that distinction is a product-design decision as much as an evaluation decision.
Research needs its own proof.
The research programme asks about treatment versus control, the runtime used, the memory path and the verifier. Results from a particular mechanism or harness are not automatically promoted into claims about the installed product. Review-scoped research figures are intentionally not reproduced here.
The toolkit
- Letta-native integration
- TypeScript mod tools, lifecycle events and visible runtime feedback connect the workflow to real agent execution.
- Explicit verification
- Outcome records and bounded checks make successes, failures and unknowns inspectable.
- Research boundaries
- Controlled comparisons and verifier-backed procedures are kept distinct from ordinary product telemetry.
04 / Evidence
See the actual work.
The research site and source repository document different parts of the work. A recorded episode or a verified artifact is not a promise of autonomous improvement.
The portfolio demonstrates a real procedural-memory tool and the discipline used to investigate it. It does not claim that recording more episodes guarantees learning, or that the installed product has a proven general improvement rate.