문서가 "거부한다"고 적어둔 herdr 메서드가 한 일
herdr는 agent.prompt가 에이전트가 blocked 상태면 거부한다고 문서화해뒀습니다. 살아 있는 pane에서 재보니 입력을 그대로 보냈고, 뒤에 붙은 Enter가 Claude Code의 신뢰 대화상자에 사용자 대신 답했습니다.
블로그
태그: build-in-public 전체 보기
지식베이스 1131행 중 읽을 만한 3행
지난 릴리스에서 가장 공들여 검증한 것을 이번에 지웠습니다. 고장 난 데는 없었습니다. 적대적 리뷰 열네 라운드가 전부 메커니즘을 쟀고, 그중 어느 것도 나온 결과가 읽을 만한지는 묻지 않았습니다. 그 질문에는 화면을 처음 연 사람이 한 문장으로 답했습니다.
드라이버 하나만 테스트한 패키지가 대시보드를 멈춘 경위
리댁션 구멍을 막은 수정이 아무 일도 하지 않는 대시보드 버튼으로 나갈 뻔했습니다. 관련된 테스트 스위트는 전부 통과했습니다. 버그는 스위트들 사이의 틈에 있었고, 초록은 무엇을 돌리지 않았는지까지 말해주지는 않습니다.
코드가 옮겨간 뒤에도 남아 있던 주석 여섯 개
2026-07-29 하루에 한 서브시스템에서 같은 결함을 여섯 개 찾았습니다. 거짓말은 하나도 없었고, 전부 쓰일 당시엔 정확했습니다. 정확했기 때문에 사람들이 믿었고, 그래서 정확하게 쓰자는 말은 이 문제의 처방이 되지 못합니다.
세 에이전트가 같은 오답에 동의했을 때
에이전트 넷이 보드로 조율하며 RelayRoom 0.5.0을 만들었습니다. 그 과정을 굴러가게 한 규칙은 이번 릴리스로 만든 기능이 강제하는 규칙과 같았습니다. 서로를 반박한 사례들과, 통과한 테스트를 일부러 부숴 확인한 기록입니다.
후보에서 신뢰까지, 사실 하나가 지나는 다섯 단계
0.5.0은 닫힌 스레드를 Project Knowledge로 증류해 에이전트가 작업 전에 recall하도록 하고, 틀린 사실이 맞는 사실만큼 빠르게 증폭되지 않도록 승격에 독립 발행자 게이트를 둡니다. 사실 하나가 후보에서 신뢰로, 다시 강등되기까지를 따라가 봅니다.
리뷰어 에이전트가 첫날 잡은 26건
ban 게이트의 주석은 자기가 어떻게 실패할지를 정확히 적어두고 있었고, 코드는 프로덕션에서 실제로 그렇게 실패하고 있었습니다. 멀티에이전트로 전환한 첫날 RelayRoom이 자기 코드에서 찾은 것과, 그것들이 왜 거기 있었는지.
roster 툴이 생기기 전까지 파트를 찾던 방법
RelayRoom으로 RelayRoom을 만들다 발견한 갭. 메시지는 파트에 보낼 수 있었지만, 정작 어떤 파트가 있는지 조회할 도구가 없었습니다. 협업 시스템에서 주소록이 왜 1급 기능이어야 하는지, 그리고 `roster`와 `whoami`를 더한 이유.
tmux와 MCP로 직접 만든 에이전트 협업 레이어
에이전틱 코딩을 하다 보니 한 에이전트로는 부족했고, OpenHands와 Paperclip과 Claude Teamwork를 써봐도 제 워크플로와 맞지 않았습니다. 이미 살아 있는 에이전트들을 얇게 연결하려고 tmux와 MCP를 엮기 시작한 기록입니다.