에이전트 메모리 프레임워크 — 4종 비교와 선택 가이드

TL;DR

• 한 주 사이에 네 메모리 framework이 같은 자리에 모였다. agentmemory(8.3k★·2.5개월·MCP 서버형 메모리 엔진) · hermes-agent(149k★·셀프-개선 런타임) · Mem0(55.6k★·메모리 API layer) · Letta/MemGPT(22.7k★·stateful 에이전트 플랫폼). 모두 같은 한 주에 GitHub 트렌딩과 평가 페이퍼(LongMemEval-V2·MEME·MemPrivacy) testbed에서 만났다.
• layer 분담이 분명해졌다 — 메모리 인프라 vs 메모리 런타임. agentmemory와 Mem0는 메모리 인프라(에이전트에 얹어 쓰는 외부 엔진)이고, hermes-agent와 Letta는 메모리 런타임(메모리가 박힌 full agent runtime). 같은 카테고리지만 디자인 가정이 직교.
• 각 layer 안의 두 framework이 결정적 디자인 차이를 가진다. 인프라 layer — agentmemory는 12 자동 hook + SQLite + BM25+vector+graph fusion, Mem0는 manual add() API + Qdrant/pgvector + vector+graph. 런타임 layer — hermes-agent는 200+ 모델 + 7 backend + 6 메시징 플랫폼, Letta는 Postgres + vector DB + 자기 런타임 lock-in.
• 결합 가능성이 layer에 따라 다르다. 메모리 인프라(agentmemory/Mem0)는 어떤 에이전트 위에도 얹을 수 있다 — Claude Code·Cursor·hermes-agent 자체에도 통합 가능. 메모리 런타임(hermes-agent/Letta)은 자기 안의 메모리를 본체로 두지만 외부 메모리 엔진을 플러그인으로 받을 수 있다. 즉 인프라 1 + 런타임 1 조합이 자연.

1. 한 주 동안 벌어진 일

어느 일요일. rohitg00/agentmemory가 GitHub 트렌딩에 들어왔다. 출시 2.5개월 만에 8.3k 스타, "#1 코딩 에이전트 영속 메모리"라는 self-claim과 함께 95.2% R@5(LongMemEval-S) 같은 벤치 수치를 마케팅 본체로 들고 나왔다. 같은 날 MemPrivacy 페이퍼(MemTensor + Tongji)가 arXiv에 올라가면서 LangMem·Mem0·MemoBase를 PII 보호 testbed로 채택해 raw masking은 26-42% 유틸리티 손실, MemPrivacy는 1.6% 이내임을 측정했다.

이틀 뒤, 화요일. NousResearch/hermes-agent가 "당신과 함께 성장하는 에이전트" 태그라인으로 하루 2k 스타 급증. 출시 10개월 차 149k 스타에서 한 주 동안 두 자릿수 % 성장.

그 다음 날, 수요일. 같은 날 평가 페이퍼 두 개가 동시에 publish됐다. LongMemEval-V2(UCLA)가 AgentRunbook-R/C 자체 baseline을 제시하면서 Mem0·Letta 류 RAG-based 시스템을 간접 비교 대상으로. MEME(KAIST + 튀빙겐 + NAVER)가 Mem0·Graphiti·MD-flat·Karpathy Wiki를 6 메모리 시스템 testbed로 채택해 전 시스템이 의존성 추론(Cascade 3%·Absence 1%)에서 동시 붕괴함을 보였다.

다섯 신호를 한 주로 묶으면 한 흐름이 보인다. agentmemory와 hermes-agent가 트렌딩 자리를 가져가는 동시에, 평가 페이퍼 셋이 Mem0·Letta·LangMem·Graphiti를 testbed로 끌어들여 객관 측정의 대상으로 묶었다. 두 흐름은 우연히 겹친 게 아니다 — 카테고리가 충분히 성숙해서 클레임 비교 대신 증거 비교가 가능해진 시점이라는 신호. 진입자는 벤치 수치를 들고 들어오고(agentmemory의 R@5 95.2% self-publish), 평가 도구는 기존 framework을 자기 비교 대상으로 박는다.

Agent Framework 시리즈가 정리한 4 메타프레임이 4개월 사이 동시 등장한 모먼트와 같은 패턴이다. 메타프레임 카테고리가 그랬듯, 메모리 framework 카테고리도 측정 가능한 layer가 형성되자 동시 진입이 가속하는 같은 국면에 도달한 것.

이 한 주의 흐름이 이 글이 다루는 4 framework이 같은 자리에서 만난 이유다. agentmemory(2026-02 출시)·hermes-agent(2025-07)·Mem0(2023-06)·Letta(2023-10) — 출시 시점은 3년 차이지만 같은 한 주에 모두 같은 벤치·같은 트렌딩·같은 비교 표에 묶였다. 그 대목에서 layer 분담이 보이기 시작했다.

2. 레이어 분류 — 메모리 인프라 vs 메모리 런타임

네 framework을 그들이 푸는 layer로 정렬하면 두 갈래로 갈린다.

메모리 인프라는 외부 엔진이다. 에이전트(Claude Code·Cursor·OpenCode·hermes-agent까지)에 얹어 쓰는 도구. 사용자가 어떤 에이전트 환경을 쓰든 같은 메모리가 흐른다. 메모리 런타임은 에이전트 자체가 본체다. 메모리는 그 안에 박혀있고 사용자가 런타임을 메인 환경으로 들여야 동작.

두 layer가 분리 가능한 책임이라는 점이 본 글의 핵심 단정. 메모리 layer 위에 어떤 에이전트 런타임을 얹을지가 사용자 결정. agentmemory + hermes-agent 같은 cross-layer 결합이 동시 운영 가능한 것은 둘이 다른 layer를 잡기 때문 — 같은 layer 안의 둘(agentmemory + Mem0 또는 hermes-agent + Letta)은 직접 충돌.

2.1. Capture·Storage·Retrieval·Lifecycle 4축 매트릭스

네 framework을 Agent Memory 카테고리 인덱스가 깐 Capture·Storage·Retrieval·Lifecycle 4축으로 정렬:

각 layer 안의 두 framework이 4축 모두에서 다른 답을 가진다는 점이 표에서 드러난다. 인프라 layer에서 agentmemory와 Mem0는 capture·storage·retrieval·lifecycle 네 축 모두에서 직교. 런타임 layer에서 hermes-agent와 Letta도 마찬가지.

2.2. 메타축 — 운영 결정에 영향을 주는 자리

4축 외에 layer 결정과 사용 환경 선택에 직결되는 메타축:

벤치 self-claim 수치는 직접 비교 불가하다는 점을 의식. LoCoMo와 LongMemEval-S는 서로 다른 task. 각 framework이 어느 벤치를 자기 self-claim에 쓰는지가 디자인 정체성을 가리킨다. LongMemEval-V2(2026-05-13)·MEME 같은 공통 벤치 위에 4 framework이 다 평가되어야 객관 비교가 가능 — 2026 Q3 시점에 누적될 대목.

3. 메모리 인프라

3.1. agentmemory — Karpathy Wiki를 확장한 메모리 엔진

rohitg00/agentmemory — 8.3k★(2.5개월), 2026-02 출시. iii-engine 기반 MCP 서버형 메모리 엔진. README 한 줄:

"Persistent memory for Claude Code, Cursor, Gemini CLI, Codex CLI, Hermes, OpenClaw, pi, OpenCode, and any MCP client." — README

핵심은 MCP를 통해 16+ 에이전트 환경에 즉시 통합된다는 점. README의 Works With Every Agent 표가 명시적으로 16개 에이전트 환경을 나열 — Claude Code·OpenClaw·Hermes·Cursor·Gemini CLI·OpenCode·Codex CLI·Cline·Goose·Kilo Code·Aider·Claude Desktop·Windsurf·Roo Code·Claude SDK + REST API.

agentmemory의 self-positioning에는 인용 근원이 명시되어 있다: "Karpathy의 LLM Wiki 패턴을 확장 — confidence scoring · lifecycle · knowledge graphs · hybrid search". 즉 Karpathy가 깐 markdown 위키 패턴에 시스템적 메커니즘 4개를 추가한 것이 본체.

디자인 메커니즘 6개:

1. 자동 capture — 12 hook. Claude Code의 12 hooks + MCP + skills 자동 통합, Codex CLI의 6 hooks + MCP + skills. 사용자 manual call 0회가 디자인 목표.
2. 하이브리드 retrieval — BM25 + Vector + Graph (RRF fusion). 3 retriever를 Reciprocal Rank Fusion으로 결합. agentmemory 자체 측정 LongMemEval-S R@5 95.2% — BM25 단독 86.2%, +9%p 향상.
3. 0 외부 DB — SQLite + iii-engine. self-hosted가 기본. embedding model은 all-MiniLM-L6-v2(로컬, 무료, API 키 불필요).
4. 4-tier consolidation + decay + auto-forget. 메모리 lifecycle이 4-tier로 자동 합치고, 시간 decay가 적용되고, 자동 forget까지. agent-curated가 아니라 engine-side automation.
5. multi-agent 조정 — MCP + REST + leases + signals. 복수 에이전트가 같은 메모리 서버에 동시 접근할 때의 lease + signal 메커니즘.
6. 실시간 viewer. 로컬 포트 3113에 web viewer가 메모리 상태를 실시간 표시. 세션 replay tab에서 prompt·tool call·tool result·response를 시간축 스크럽 가능 (0.5×~4× 재생).

토큰 효율 — 디자인의 단정성: agentmemory 자체 계산표:

99% 토큰 절감을 self-claim. 메타프레임 카테고리(ECC §2.1 토큰 디폴트)의 baseline 깎기와 정확히 같은 대목이지만 메모리 layer에서 진행.

한계:

• 출시 2.5개월 — production 검증 표면이 짧다. 12 hook의 capture 정확도, RRF fusion의 long-tail edge case, multi-agent lease + signal의 동시성 안정성에 대한 외부 검증 자료는 v0.9.0 시점 아직 부족. production 도입 시 frozen v0.9.0 권장.
• LongMemEval-S(V1) 측정만 self-publish. V2(2026-05-13 출시)에서는 아직 측정 안 됨.
• 12 hook의 capture 정확도를 외부에서 검증한 자료는 없음 — engine-side automation의 일반적 trade-off.

3.2. Mem0 — Universal memory layer

mem0ai/mem0 — 55.6k★, 2023-06 출시(~3년). "Universal memory layer for AI Agents". 카테고리에서 가장 오래된 player.

디자인 요약:

• API layer — mem0.add() · mem0.search() · mem0.update(). 에이전트가 명시적으로 호출.
• vector + graph 검색 — Qdrant/pgvector + graph store. agentmemory의 BM25 추가 fusion과 차별점.
• 외부 DB 의존 — Qdrant·pgvector·Neo4j 등. self-hosted든 cloud든 DB가 필수.
• lifecycle: passive extraction — 사용자 발화에서 수동 extraction 후 저장. 자동 hook 없음.

Mem0는 카테고리 시작점에 가깝다 — "메모리 layer를 분리하자"는 디자인 가정 자체를 카테고리화한 player. 3년 전 출시가 이 디자인 가정을 최초로 명시한 지점이다.

MemPrivacy 논문 §4가 Mem0를 세 testbed 중 하나로 채택해 PL2-PL4 보호 시 -0.73% 정확도 손실을 측정한 대목. Mem0가 객관 평가의 베이스라인이 됐다는 점이 카테고리 성숙도의 직접 신호.

한계:

• Qdrant·pgvector·Neo4j 등의 외부 DB 운영 부담이 agentmemory의 0 외부 DB와 명확히 차별. self-hosted Mem0 운영 vs cloud Mem0 사용의 결정 비용이 추가로 들어감.
• manual add() API는 capture가 사용자 책임. 에이전트 코드 안에 언제 무엇을 저장할지 명시 호출이 필요 — agentmemory의 12 hook과 디자인 가정이 정반대.

4. 메모리 런타임

4.1. hermes-agent — 셀프-개선 에이전트 런타임

NousResearch/hermes-agent — 149k★(2025-07 출시 후 ~10개월), Nous Research 본체 프로젝트. README 첫 줄:

"The only agent with a built-in learning loop — it creates skills from experience, improves them during use, nudges itself to persist knowledge, searches its own past conversations, and builds a deepening model of who you are across sessions." — README

agentmemory가 외부 메모리 layer라면 hermes-agent는 학습 루프가 박힌 full agent runtime. 디자인 본체가 다르다.

핵심 학습 루프 5 요소:

1. agent-curated memory with periodic nudges — 에이전트가 자기 메모리를 큐레이트. 주기적으로 자기에게 "이거 기억해둘 만한 거 아닌가"하고 nudge.
2. 자율 skill 생성 — 복잡한 task 완료 후 재사용 가능한 skill을 자동 생성. 외부 dev가 spell-out하지 않은 자체 학습.
3. skill self-improvement during use — 한 번 만든 skill을 사용하면서 자기 개선. 사용 빈도·결과를 피드백 루프로 반영.
4. FTS5 session search + LLM summarization — SQLite FTS5 풀텍스트 검색 + LLM 요약으로 과거 대화 자체를 검색. 대화가 memory가 되는 디자인.
5. Honcho dialectic user modeling — Honcho 라이브러리 통합으로 사용자에 대한 진화하는 모델을 별도 유지. 즉 task 메모리와 user 메모리가 분리.

메모리 외 핵심 기능:

• 200+ 모델 지원 — OpenRouter·OpenAI·Anthropic·Nous Portal·NovitaAI·NVIDIA NIM·Xiaomi MiMo·z.ai/GLM·Kimi·MiniMax·HuggingFace. hermes model 한 줄로 전환.
• 메시징 게이트웨이 — Telegram·Discord·Slack·WhatsApp·Signal·Email + CLI. 6개 플랫폼 동시 운영. 음성 메모 transcription도 지원.
• 7개 터미널 backend — local·Docker·SSH·Singularity·Modal·Daytona·Vercel Sandbox. Daytona/Modal은 serverless persistence(idle 시 hibernate, on-demand wake).
• cron 스케줄러 — 자연어로 "매일 아침 8시 보고서" 같은 작업 등록. unattended 실행.
• 서브에이전트 + RPC — 격리 서브에이전트가 zero-context-cost turn으로 multi-step 파이프라인 압축.
• agentskills.io 호환 — 오픈 표준에 명시적 호환. 고수 스킬팩 글이 정리한 스킬 생태계와의 연결.

RL 학습 표면 — environments/ 디렉토리에 Atropos RL environments가 있어 batch trajectory generation + RL 학습 코드가 같이 들어있다. Nous Research가 다음 세대 tool-calling model 학습을 hermes-agent로 한다는 신호 — 즉 hermes-agent는 단지 사용자 도구가 아니라 학습 데이터 generator.

한계:

• 149k★이지만 enterprise commercial 운영에는 들어가지 않는다 — 개인 사용자/연구자 중심.
• full agent runtime이라 기존 에이전트 환경(Claude Code 등)에 얹어 쓰는 모드가 아니다. hermes 자체를 메인 환경으로 들여야 의미.
• cross-platform 메시징 게이트웨이의 PII·secrets 전송 표면은 MemPrivacy 글이 잡은 지점과 정면. WhatsApp·Telegram·Signal 같은 외부 메시징 인프라에 민감 정보가 흐를 가능성 — 개인 환경에서는 통제 가능하지만 기업 도입은 추가 보안 review 필요.

4.2. Letta/MemGPT — Stateful 에이전트 플랫폼

letta-ai/letta — 22.7k★, 2023-10 출시(~2.5년). MemGPT 페이퍼(Packer et al., 2023)의 후신. "Platform for building stateful agents".

디자인 본체:

• OS 메타포 — core memory(컨텍스트 안)와 archival memory(외부 vector DB)를 OS의 RAM/디스크처럼 분리. 에이전트가 자기 메모리를 직접 swap.
• stateful agent runtime — 에이전트 인스턴스가 영구 state를 유지. 세션 사이 상태 손실 없음.
• agent self-edits — 에이전트가 자기 core memory를 직접 수정. agentmemory의 외부 hook 모델과 정반대.
• 외부 DB 의존 — Postgres + vector DB. enterprise-grade 운영 가정.

Letta의 핵심 단점은 Letta 런타임 lock-in이다. Claude Code·Cursor 같은 기존 에이전트 환경에 얹어 쓸 수 없다 — Letta가 런타임 본체가 되어야 한다. agentmemory README 비교 표가 명시적으로 "Framework lock-in: High (must use Letta)"로 표기한 대목.

hermes-agent가 Letta의 직접 후신에 가까운 위치 — self-improving agent runtime이지만 모델·터미널·메시징 게이트웨이를 모두 교체 가능하게 디자인. 즉 MemGPT가 깐 OS 메타포 위에 plugin 가능성을 얹은 형태.

MEME 논문이 Letta 자체는 아니지만 Letta 디자인 본체인 agent self-edits를 file-based agent(MD-flat, Karpathy Wiki) 로 측정한 대목. Cascade 3%·Absence 1%로 동시 붕괴 — agent self-edit 모델이 의존성 추론에서는 무력. Letta 사용자가 의식할 발견.

한계:

• 기존 에이전트 환경에 얹어 쓸 수 없다는 점이 Claude Code·Cursor 같은 환경에 익숙한 사용자에게는 진입 비용. enterprise stateful 에이전트가 본체인 환경에서만 lock-in이 정당화.
• Postgres + vector DB 같은 enterprise infrastructure 운영 가정이 개인·작은 팀에는 부담.
• agent self-edits가 의존성 추론에서는 MEME 페이퍼가 입증한 대로 무력(Cascade 3%·Absence 1%). 의존성이 중요한 도메인(프로젝트 관리·관계형 데이터)에서 경고 표면.

5. 결합과 충돌 — 같은 프로젝트에서 같이 쓸 때

네 framework이 서로 다른 layer를 잡으므로 결합 가능성과 충돌 표면도 layer에 따라 다르다.

5.1. 메모리 인프라 + 메모리 런타임 — 자연스러운 결합

agentmemory가 자기 README에 Hermes 통합을 명시:

"Hermes: MCP + plugin" — agentmemory README · Works With Every Agent

즉 agentmemory 메모리 엔진을 hermes-agent 런타임의 외부 메모리로 쓰는 결합이 first-class 지원. 이 결합에서:

• agentmemory의 BM25+Vector+Graph hybrid retrieval이 hermes의 FTS5 단독보다 강한 대목에서 사용.
• hermes-agent의 Honcho user modeling과 skill self-improvement는 agentmemory가 다루지 않는 영역.
• agentmemory의 12 hook 자동 capture가 hermes 세션의 agent-curated memory + periodic nudge와 중복될 수 있다 — 어느 capture가 정본인지 명시 결정 필요.

대응: hermes-agent의 내장 메모리는 user modeling만 담당, 작업 메모리는 agentmemory에 위임. 즉 layer 분담이 capture 단위에서도 적용.

5.2. 같은 layer 안의 둘 — 직접 충돌

메모리 인프라 둘 같이 쓰기 (agentmemory + Mem0) — 같은 layer의 두 framework이라 직접 충돌. 어느 게 정본이 될지 결정 안 됨. agentmemory의 자동 hook과 Mem0의 수동 API가 같은 정보를 두 군데에 누적.

메모리 런타임 둘 같이 쓰기 (hermes-agent + Letta) — 직접 충돌. 둘 다 런타임 본체가 되려는 디자인이라 동시 운영 불가. 단, agentmemory 같은 외부 메모리 엔진을 공통 메모리 layer로 둘 수 있다 — 즉 둘 사이의 마이그레이션 path가 외부 메모리를 통해 가능.

대응: 같은 layer는 하나만. 사용 시나리오에 따라 §6에서 어느 게 맞는지 결정.

5.3. 메타프레임 + 메모리 framework 결합

Agent Framework 시리즈의 4 프레임(Superpowers·GSD·gstack·ECC)이 모두 자기 메모리 메커니즘을 가진다는 점을 카테고리 인덱스가 정리했다. 이 4 프레임 위에 agentmemory 같은 외부 메모리 엔진을 추가로 깔 수 있는지가 결합 가능성 지점.

• Superpowers — 사용자 작업 메모리 자체가 없으므로 agentmemory를 같이 깔면 Superpowers의 빈 자리를 정확히 채운다. 자연 결합.
• GSD — .planning/ markdown state가 본체. agentmemory와 capture 단위 직교 — GSD는 phase boundary, agentmemory는 12 hook. 두 capture가 같은 정보를 다르게 저장할 수 있어 대응 분리 필요.
• gstack — /learn 사용자 명시 + 도메인 스킬 자동. agentmemory의 12 hook 자동이 gstack의 명시 디자인 가정과 충돌 가능. 대응: agentmemory hook 일부만 활성화.
• ECC — instinct v2 자동 추출 + 신뢰도 점수. agentmemory의 4-tier consolidation과 직접 경쟁. ECC 사용자는 둘 중 하나만 켜는 게 합리적.

즉 메타프레임 + 외부 메모리 엔진 결합이 자연스러운 것은 Superpowers뿐. 나머지 셋은 이미 자기 메모리가 있으므로 agentmemory가 중복이 된다.

6. 사용 시나리오 — 5가지 권고

표면적으로 4 framework이 있지만, 사용 시나리오에 따라 선택은 명확하다.

6.1. Claude Code/Cursor 사용자 + 메타프레임 없음 → agentmemory

가장 단순한 경로. MCP 서버 한 번 띄우고 사용 중인 에이전트 환경에 통합. 자체 hook이 manual configuration 0회로 작동. 토큰 비용 절감(LLM-summarized 대비 ~98%)이 즉시 발휘되는 환경.

6.2. Superpowers 사용자 → agentmemory 보강

Superpowers는 사용자 작업 메모리가 없으므로 agentmemory가 정확히 빈 곳에 들어간다. MCP 서버 + Superpowers SessionStart 부트스트랩이 공존. 한 번 깔면 세션 간 작업 컨텍스트가 자동 누적.

6.3. GSD·gstack·ECC 사용자 → 외부 메모리 보강 신중

이미 자기 메모리 메커니즘이 있는 메타프레임이면 외부 엔진 추가가 capture 충돌을 만든다. 대안 두 가지:

• memory 엔진을 retrieval-only로 사용 — capture는 메타프레임에 맡기고 agentmemory의 hybrid retrieval만 활용.
• 메타프레임 자체 메모리만 사용 — 외부 엔진 추가 안 함. 메타프레임 디자인 가정 그대로 운영.

6.4. 개인 + cross-platform 메시징 → hermes-agent

개인 사용자가 Telegram·Discord·Slack에서 같은 에이전트와 대화하면서 모델 비용 통제가 필요하면 hermes-agent. 200+ 모델 + 6 메시징 플랫폼의 결합이 카테고리에서 가장 강력.

6.5. Enterprise + stateful 에이전트 → Letta

대규모 에이전트 운영, stateful 에이전트 인스턴스 다수, Postgres·vector DB 같은 enterprise infrastructure 운영 가능한 환경. Letta 런타임 lock-in이 부담이지만 enterprise 환경에서는 lock-in이 통제 가능. 단 의존성 추론이 핵심 도메인(프로젝트 관리·관계형 데이터)이면 MEME 페이퍼가 입증한 Letta self-edit의 Cascade 3%·Absence 1% 한계를 의식.

6.6. 연구·RL 학습 → hermes-agent

Atropos RL environments + batch trajectory generation. 학습 데이터 generator로서 hermes-agent의 위치가 다른 셋과 분명히 다르다.

참고

• rohitg00/agentmemory — v0.9.0(2026-04-18), 8.3k★ in 2.5개월. MCP 서버형 메모리 엔진
• agent-memory.dev — landing site
• npm @agentmemory/agentmemory — Node.js 패키지
• benchmark/COMPARISON.md — agentmemory 자체 비교 표
• NousResearch/hermes-agent — 149k★, 2025-07 출시. self-improving 에이전트 런타임
• hermes-agent docs
• plastic-labs/honcho — hermes-agent의 user modeling 라이브러리
• agentskills.io — hermes-agent가 호환하는 오픈 스킬 표준
• mem0ai/mem0 — 55.6k★, 2023-06 출시. Universal memory layer
• letta-ai/letta — 22.7k★, 2023-10 출시. MemGPT 후신, stateful 에이전트 플랫폼
• MemGPT 페이퍼 (Packer et al., 2023) — Letta의 디자인 본체

카테고리 인덱스 + 평가 페이퍼

• Agent Memory 카테고리 — Capture·Storage·Retrieval·Lifecycle 4축 분해
• 에이전트 메모리의 측정 — 평가 벤치의 등장 배경 및 범위 — LongMemEval-V2·MEME·MemPrivacy 분석
• LongMemEval-V2
• MEME
• MemPrivacy

시리즈 내 연결

• Agent Framework 시리즈 — 4 메타프레임의 메모리 메커니즘이 박혀있는 글들 (Superpowers·GSD·gstack·ECC)
• Agent Skill — 고수들의 스킬팩 — hermes-agent가 호환하는 agentskills.io 표준과 연결
• Agent Governance 카테고리 — 영속 메모리의 거버넌스 표면 (MemPrivacy 글이 다루는 자리)