Kontexus-MCP는 Rust로 포팅된 WGM+FTM 이다
Harness의 빈 틈
Harness의 구조적 전제는 하나이다: 에이전트는 턴 단위로 존재하고, 세션이 끝나면 사라진다.
그 전제 위에서 harness는 실행 중인 것을 잘 다룬다. 컨텍스트를 유지하고, 도구를 붙이고, 병렬로 펼치고, 훅으로 개입 지점을 준다.
그러나 아래와 같은 틈이 있다:
| 빈자리 |
|---|
| 턴 사이 – 왜 그렇게 결정했는지 |
| 세션 사이 – 무엇이 있었는지 |
| 주체 사이 – 상대가 무엇을 하는지 |
| 작업 전후 – 끝났다는 확정 |
이 넷의 공통 성질은 모두 “실행 사이”라는 공통점을 가진다. Harness는 실행 중(in-flight)을 최적화하기 때문에, 빈자리는 실행이 멈춘 자리, 즉 경계에 있다. 그래서 빈자리를 한 문장으로 하면 — 경계에서의 상태 보존과 전달이라고 할 수 있다.
Kontexus-MCP가 메우는 것
하나. 저장이 실행 주체 밖에 있음
Harness의 기억은 에이전트 수명에 묶이지만, Kontexus의 기억은 파일시스템과 database에 있어 에이전트가 종료해도 남는다. 오늘 세션을 재시작했는데도 몇달 전, 몇일 전, 몇 시간전 태스크 내용과 채팅 내용은 그대로 있고 현재와 이어진다. 이건 성능 차이가 아니라 누가 문맥을 가지고 있느냐의 차이다.
둘. 식별자 체계 자체가 규격 T154/T154.1이 같은 태스크 식별자가 계층을 담고, 0,fbc,1aa(0<code class="" data-line="">→fbc → 1a → 1aa)가 스레드를 담는데 쓰일 수 있어서, 같은 호스트에서 다른 저장소 같에 AGENT가 노트 식별자 만으로 대화 Thread를 이어갈 수 있다 — 이름 규칙만으로 관계가 표현되니 별도의 결속 장치가 필요 없다.
셋. 지식을 공유하는 저장소가 규격화되어 있다.--storage <peer>로 다른 저장소를 같은 명령으로 읽기 때문에 AGENT끼리 소통하는데 불필요한 내용 전달이 필요없다. 상대가 직접 읽기 때문이다.
AGENT의 성실함에 기대지 않는다
태스크를 진행했다고 거짓말을 할 수가 없다. 그걸 증명해야 하기 때문이다. 온갖 Tool 호출 기록과 각각의 Tool Description, Skill Descriptions, 엉킨 채팅 내용등이 누적되가는 데이터 흐름속에서도 해야할 일을 쪼개고, 유지하고, 증명하게 한다. 단순히 AGENTS.md/CLAUDE.md/SOUL.md 로는 제어할 수 없는 상황에서도 AGENT가 지켜야할 선을 유지하게 해준다.
필요에 의한 프로젝트/저장소 연결
“한쪽이 다른 쪽에게 우리 소스가 변경됐으니, 네 쪽에 보정이 필요하니 적용하셈” 이라고 PUSH Message 보내면 —> 받은 쪽에서 사용자에게 허가를 받고 작업계획 수립한다 —> 아래 스샷은, 그 Push Message 받고 태스크 수립하고 돌리는 중을 타나낸다.
