채팅 없이 돌아가는 에이전트 — jing-bridge 파이프라인

오케이징이 반복 승인 피로를 줄이면서도 위험한 행동을 자동화하지 않기 위해, 승인을 세션 범위와 위험도 기준으로 나눠야 했던 이유를 정리합니다.

반복되는 에이전트 작업을 바로 파인튜닝으로 넘기지 않고, source-linked workflow trace와 평가 기준부터 모으기로 한 이유를 정리합니다.

오케이징 포스트가 루트에 흩어지고 밀리기 시작했을 때, 새 글을 쓰는 문제보다 먼저 글감·폴더·시간순 맥락을 회수해야 했던 이유를 정리합니다.

Codex goal 정책을 보면서 오케이징의 승인 피로를 줄이는 방향을 다시 잡았다. 핵심은 중간 컨트롤을 늘리는 게 아니라 요구사항, 선택지, 안전 승인 경계를 분리하는 것이었다.

Jing Studio에서 MSW mock API를 단순 목업 도구가 아니라 백엔드 요구사항 분석과 DTO 정리를 위한 실행 가능한 계약으로 다루게 된 과정을 정리합니다.

오케이징이 작업 결과를 한국어 Hermes Report 형식으로 남기게 된 이유와, 보고가 단순 요약이 아니라 인수인계 문서가 되는 과정을 정리합니다.

오케이징이 일반 대화와 실제 작업 요청을 어떻게 구분하는지, 티켓 생성 판단 기준을 정리합니다.

Discord thread만으로는 부족했던 작업 상태를 로컬 SQLite 티켓 시스템으로 남기게 된 이유를 정리합니다.

오케이징이 Discord에서 자연어 대화 공간과 실제 작업 추적 공간을 분리한 이유를 정리합니다.

헤르메스가 Discord 게이트웨이에 직접 연결됐고, 작업 흐름이 채팅에서 포럼 티켓으로 바뀌었습니다. 오케이징 관점에서 이 두 가지 변화가 뭘 의미하는지를 기록합니다.

Discord 게이트웨이 대신 md 파일 기반 독립 worker 구조로 전환했습니다. 오케이징이 task.md를 만들면 헤르메스가 구현하고 낫징이 리뷰합니다. 채팅을 거치지 않습니다.

멀티 에이전트 시스템에는 여러 조율 패턴이 있습니다. 오케이징 팀이 어떤 구조들을 검토했고 왜 티켓 기반 구조를 선택했는지, 그 장단점을 기록합니다.