Hermes Agent를 검증 가능한 에이전트 운영체제(Agent Operating System)로 변환하기

내가 만든 것

나는 또 다른 챗봇을 만든 것이 아닙니다.

나는 Hermes Agent를 중심으로 한 메모리 위생 시스템(memory hygiene system)을 구축했습니다. 이는 에이전트에게 무엇을 기억할지, 무엇을 기술(skill)로 전환할지, 무엇을 리포지토리(repo)에 기록할지, 무엇을 작업 시스템(task system)에서 추적할지, 그리고 무엇을 뒤에 남겨둘지를 알려주는 워크플로우입니다.

핵심 아이디어는 간단합니다:

에이전트 메모리는 하나의 바구니가 아닙니다.

채팅 기록(chat history), 전역 메모리(global memory), 프로젝트 상태(project state), 재사용 가능한 절차(reusable procedures), 작업 소유권(task ownership), 그리고 공개적인 부수 효과(public side effects)를 모두 동일한 것으로 취급하면 장기 실행되는 에이전트 작업은 깨지게 됩니다. 이것들은 서로 다른 수명(lifetimes)을 가집니다. 이 모든 것을 하나의 "메모리"에 넣는 것은 드리프트(drift)를 유발합니다.

그래서 나는 Hermes Agent를 중심으로 작은 리포지토리 로컬 하네스(repo-local harness)와 운영 규율을 구축했습니다.

Hermes Agent는 내가 도구 호출(tool-calling) 작업을 위해 사용하는 로컬 에이전트 런타임(local agent runtime)입니다: 터미널 명령, 파일 편집, 브라우저/검색 워크플로우, 지속성 메모리(persistent memory), 재사용 가능한 기술(reusable skills), 예약된 작업(scheduled jobs), 그리고 게이트웨이 통합(gateway integrations) 등을 포함합니다.

Multica는 능동적인 작업 소유권 및 라우팅을 위해 사용하는 외부 작업 레이어(external task layer)입니다. 이 설정에서 Multica는 현재 작업의 진실의 원천(source of truth)으로서 로컬 Hermes 칸반(Kanban)을 대체했습니다.

이 시스템은 에이전트 작업을 내구성이 있는 레이어(durable layers)로 분리합니다:

레이어	책임
Hermes memory	안정적인 사실(Stable facts)만 저장
...

운영 규칙:

안정적인 사실을 위한 메모리. 재사용 가능한 절차를 위한 기술(Skills). 프로젝트 상태를 위한 리포지토리(Repos). 작업 소유권을 위한 Multica. 기록을 위한 세션 검색(Session search). 부수 효과(side effects)를 위한 인간의 승인.

이것이 Hermes를 채팅 어시스턴트에서 작은 에이전트 운영 레이어(agent operating layer)로 변화시킵니다.

전 / 후

전	후
채팅에 묻혀 있는 작업 상태	Multica에 존재하는 작업 상태
...

중요한 변화는 더 많은 메모리를 갖는 것이 아닙니다. 각 종류의 상태를 적절한 내구성을 가진 레이어로 라우팅(routing)하는 것입니다.

최저 내구 레이어 규칙 (The lowest durable layer rule)

핵심 규칙은 다음과 같습니다:

정보를 예상 수명에 비해 충분히 내구성이 있는 가장 낮은 레이어에 저장하라.

예시:

• 안정적인 사용자 선호도(user preference)는 Hermes 메모리(memory)로 이동합니다.
• 반복되는 절차(procedure)는 Hermes 기술(skill)이 됩니다.
• 프로젝트 컨벤션(convention)은 AGENTS.md 또는 CLAUDE.md에 저장됩니다.
• 현재 작업 소유권(task ownership)은 Multica에 속합니다.
• 과거 문맥(historical context)은 세션 검색(session search)에 남을 수 있습니다.
• 공개적인 부작용(side effects)은 인간의 승인(human approval)이 필요합니다.

이렇게 함으로써 메모리가 잡동사니 서랍(junk drawer)으로 변하는 대신 유용하게 유지됩니다.

데모 (Demo)

이 아키텍처는 의도적으로 작게 설계되었습니다:

Multica 작업 레이어 (task layer) ←→ Hermes Agent ←→ 세션 검색 (Session search)
                         ↓
                  증거 루프 (Evidence Loop)
...

Hermes의 라우팅(routes)은 내구성이 있는 레이어(durable layers)를 거친 후 증거 루프(evidence loop)를 통해 작동합니다. 외부 부작용(external side effects)은 인간 승인 게이트(Human Approval Gate)에서 차단됩니다.

구체적인 작업은 다음과 같았습니다:

저장소 로컬 에이전트 상태(repo-local agent state)를 위한 반복 가능한 컨벤션을 생성하고, 이를 검증하며, 작업 소유권(task ownership)을 채팅 외부로 유지하라.

워크플로우:

1. Multica 이슈(issue)가 작업을 정의했습니다.
2. Hermes가 세션 검색(session search)을 통해 이전 문맥(prior context)을 복구했습니다.
3. Hermes가 저장소 로컬 하네스(repo-local harness) 파일들을 작성했습니다:

• AGENTS.md
• CLAUDE.md
• agent-progress.md
• AGENT_LESSONS.md
• session-handoff.md
• feature_list.json
• .agent-harness/validate_feature_list.py
  1. 재사용 가능한 절차(reusable procedure)가 Hermes 기술(skills)로 승격되었습니다.

2. 프로젝트 특정 상태(project-specific state)는 저장소(repository)에 유지되었습니다.
3. 활성 소유권(active ownership)은 Multica에 유지되었습니다.
4. 하네스(harness)는 테스트와 검증 명령(validator command)을 통해 검증되었습니다.

Multica에서의 작업 소유권(Task ownership): 저장소 하네스 설정(repo harness setup)과 검증기 테스트 스위트(validator test suite)는 완료되었으나, 기술 승격(skill promotion)과 DEV.to 제출은 아직 진행 중입니다.

핵심은 에이전트가 파일을 수정했다는 점이 아닙니다. 핵심은 워크플로 (workflow)가 각 종류의 정보를 올바른 지속성 계층 (durability layer)에 강제로 할당했다는 점입니다.

증거 루프 (Evidence loop)

워크플로는 다음 루프를 사용합니다:

의도 (Intent) -> 도구 작업 (Tool action) -> 산출물 (Artifact) -> 검증 (Verification) -> 증거 보고서 (Evidence report) -> 외부인 경우 승인 (Approval if external)

예시:

• 리포지토리 (repo) 업데이트는 변경된 파일을 읽거나 차이점 (diff)을 확인하여 검증됩니다.
• 하네스 (harness) 업데이트는 테스트를 실행하여 검증됩니다.
• 작업 완료는 Multica 댓글이나 연결된 산출물 (artifact)을 통해 검증됩니다.
• 재사용 가능한 절차는 커밋된 Hermes 기술 (skill)을 통해 검증됩니다.
• 리포지토리 푸시(push)나 포스트 게시와 같은 공개적인 작업은 승인 게이트 (approval gate)에서 멈춥니다.

이는 에이전트 계약 (agent contract)을 "나 믿어줘, 내가 했어"에서 "여기 산출물 (artifact)이 있고, 이것이 어떻게 검증되었는지에 대한 내용이 여기 있어"로 변화시킵니다.

코드 (Code)

리포지토리 (Repository): https://github.com/Levash0v/verifiable-agent-harness

공개된 산출물 (artifact)은 의도적으로 작게 구성되었지만, 실제 프로젝트의 형태를 갖추고 있습니다:

templates/      AGENTS.md, CLAUDE.md, handoff files
examples/       feature_list.example.json
agent_harness/  validator
...

각 리포지토리는 작은 운영 계약 (operating contract)을 갖게 됩니다.

templates/AGENTS.md 발췌본:

# 에이전트 가이드 (Agent Guide)

이 리포지토리는 리포지토리 로컬 에이전트 하네스 (repo-local agent harness)를 사용합니다. 이 파일들을 에이전트 작업 상태의 진실의 원천 (source of truth)으로 취급하십시오:
...

해당 계약은 다음 에이전트 세션이 채팅으로부터 프로젝트를 재구성할 필요가 없음을 의미합니다. 리포지토리가 자체적인 운영 상태 (operating state), 즉 현재 기능, 검증된 진행 상황, 리포지토리별 교훈을 보유하기 때문입니다.

이 리포지토리는 단순한 문서가 아닙니다. 실행 가능한 검증기 경로 (executable validator path)를 가지고 있습니다:

python3 -m agent_harness validate examples/feature_list.example.json
python3 -m unittest discover -s tests -v

이 하네스(harness)는 실행 가능합니다: 기능 목록 검증기(feature list validator)를 통과하며, 테스트 스위트(test suite)는 유효한 프로젝트 상태 파일과 유효하지 않은 파일 모두를 검증합니다.

이는 의도적으로 작게 구성되었습니다. 목표는 관습(convention)을 단순히 서술적인 것에 그치지 않고, 실행 가능하고 테스트 가능한 것으로 만드는 것입니다.

나의 기술 스택 (My Tech Stack)

• Hermes Agent — 에이전트 런타임 (agent runtime), 메모리 (memory), 기술 (skills), 도구 (tools), 세션 검색 (session search), 예약된 작업 (scheduled jobs), 게이트웨이 (gateways)
• Multica — 활성 작업 소유권 (active task ownership) 및 라우팅 (routing)
• Python — 리포지토리 하네스 검증기 (repo harness validator)
• unittest — 검증 테스트 (validation tests)
• Markdown — 리포지토리 로컬 운영 계약 (repo-local operating contracts)
• JSON — 기계 판독 가능 기능 상태 (machine-readable feature state)
• Git / GitHub — 버전 관리된 리포지토리 아티팩트 (versioned repo artifacts) 및 증거 추적 (proof trail)
• DEV.to — 게시 및 챌린지 제출

Hermes Agent 활용 방법

Hermes Agent는 오케스트레이터 (orchestrator)이자 검증기 (verifier)로서 프로젝트의 동력을 제공했습니다.

나는 Hermes의 메모리 (memory)를 안정적인 사실, 즉 사용자 선호도, 환경 정보, 그리고 장기적인 워크플로우 관습 (workflow conventions)을 위해서만 사용했습니다.

나는 Hermes의 기술 (skills)을 절차적 메모리 (procedural memory)로 사용했습니다: 리포지토리 하네스 설정, 게시 워크플로우, 클린 상태 체크 (clean-state checks), 작업 인계 패턴 (task handoff patterns), 그리고 작업 중 발견된 디버깅 또는 라우팅 절차 등이 이에 해당합니다.

나는 세션 검색 (session search)을 과거 회상 (historical recall)을 위해 사용했습니다: 이전의 결정, 과거의 구현 시도, 그리고 리포지토리나 작업을 업데이트하기 전의 컨텍스트 재구성 (context reconstruction) 등이 포함됩니다.

나는 Hermes의 도구 (tools)를 구체적인 작업을 위해 사용했습니다: 파일 읽기 및 편집, 터미널 명령 실행, 차이점(diff) 확인, 검증기 실행, 그리고 테스트 출력 검증 등이 있습니다.

리포지토리 로컬 상태 (Repo-local state)는 다음과 같은 파일들에 저장됩니다:

AGENTS.md
CLAUDE.md
feature_list.json
...

Multica는 활성 작업 소유권 및 라우팅을 처리합니다: 무엇이 작업 중인지, 누가 소유하고 있는지, 무엇이 승인을 필요로 하는지, 그리고 어떤 결과가 보고되었는지를 관리합니다.

외부 부작용 (External side effects)은 게이트(gated)를 통해 제한됩니다: GitHub 푸시, DEV.to 게시, 소셜 포스트, Discord 메시지, 인프라 배포, 그리고 되돌릴 수 없는 작업 댓글 등이 이에 해당합니다.

Hermes는 초안 작성, 편집, 검증 및 스테이징 (stage)을 할 수 있습니다. 인간은 공개적인 행동을 승인합니다.

가장 큰 변화는 운영 규율 (operating discipline)이었습니다:

• Hermes는 메모장(scratchpad) 용도로 전역 메모리 (global memory)를 사용하는 것을 중단했습니다.
• 반복된 수정 사항은 채팅 기록 속으로 사라지는 대신 기술 (skills)로 변환되었습니다.
• 프로젝트 규칙은 리포지토리 로컬 파일 (repo-local files)로 이동했습니다.
• 작업 소유권 (task ownership)은 로컬 칸반 (local Kanban)에서 Multica로 이동했습니다.
• 완료 주장 (completion claims)은 증거에 기반한 보고서 (evidence-backed reports)가 되었습니다.

이를 통해 시스템은 덜 마법적이고 더 신뢰할 수 있게 되었습니다.

한계점 (Limitations)

이것은 그 자체로 완전한 에이전트 플랫폼은 아닙니다.

• 하네스 (harness)는 관례 (conventions)를 검증하며, 의미론적 정확성 (semantic correctness)을 검증하는 것은 아닙니다.
• Multica는 외부 조정 레이어 (external coordination layer)이며, 리포지토리 템플릿에 필수적인 요소는 아닙니다.
• 외부 효과 (external effects)에 대해서는 여전히 인간의 승인이 필요합니다.
• 증거의 품질은 파일, 작업, 기술에 대한 규율 있는 업데이트에 달려 있습니다.

이는 의도된 사항입니다. 시스템의 경계 영역 (boundaries)이 지루하게 설계된 이유는, 바로 그 경계 영역이 장기 실행 에이전트 (long-running agents)들이 보통 실패하는 지점이기 때문입니다.

다음 단계 (Next steps)

다음으로, 더 많은 검증기 (validators), Hermes / Claude Code / Codex를 위한 더 풍부한 핸드오프 (handoff) 예시, 더 엄격한 승인 프로토콜, 그리고 반복된 작업으로부터 기술 승격 (skill promotion)이 이루어지는 더 많은 사례를 추가하고 싶습니다.

이번 빌드를 통해 얻은 교훈은 간단합니다:

에이전트 메모리는 마법의 공책처럼 취급될 것이 아니라, 인프라 (infrastructure)처럼 설계되어야 합니다.

Hermes는 저에게 기본 요소 (primitives)들을 제공했습니다: 메모리 (memory), 기술 (skills), 도구 (tools), 세션 검색 (session search), 예약된 작업 (scheduled jobs), 그리고 게이트웨이 (gateways).

하네스 (harness)는 이러한 기본 요소들을 운영 규율 (operating discipline)로 변환합니다.