Agent memory를 chat history로 착각하면 self-improvement가 작동하지 않는다. Chat history는 길어지고, 섞이고, 결국 compaction되거나 사라진다. 다음 실행이 실제로 읽지 않는 memory는 운영 자산이 아니다.
이 글에서 유용한 지점은 memory를 STATE.md, episodic memory, procedural skills로 나눈다는 점이다. 현재 상태는 STATE.md에, 과거 사례는 episodic memory에, 반복 가능한 절차는 skill에 둔다. 이렇게 나눠야 agent가 다음 실행에서 필요한 것만 읽고, 같은 실패를 반복하지 않는다.
Henry의 Hermes/wiki pipeline에도 그대로 적용된다. 일회성 작업 결과는 memory가 아니라 파일과 ledger에 남기고, 반복 절차는 skill로 승격해야 한다. Memory는 모든 실행에 주입되기 때문에 짧고 안정적인 판단 기준만 담아야 한다.
근거
원문은 working memory, episodic memory, procedural memory를 구분하고, 반복 가능한 실행 패턴을 Skills Library로 축적하는 구조를 제안한다.
연결된 생각
- 20260706-state-memory-skills-agent-loop — memory 계층화와 STATE.md 중심 loop.
- 20260706-self-improving-agent-system-stack — self-improving system의 상위 구조.
- 20260612-ai-agent-work-harness — agent가 반복 실행에서 안정성을 얻기 위한 harness.