에이전트의 환각으로 파이프라인 전체가 조용히 망가진 적 있나요?

원장 아이디어 진짜 흥미롭네요. 멀티 에이전트 설정에서 저를 가장 괴롭히는 게 바로 홉(hop) 사이에서 발생하는 조용한 컨텍스트 드리프트거든요. 서명할 대상(전체 스크래치패드, 도구 인자/반환값, 검색 문서 등)이나 최소 구조화 상태(입력, 출력, 결정)에 대한 권장 패턴이 있나요? 그리고 도구 오류나 재시도를 원장을 지저분하게 만들지 않고 어떻게 처리하는지도 궁금합니다. 저희도 비슷한 가드레일(상태 차이, 단계 확인)을 실험 중인데...

Relay는 원시 스크래치패드나 대화 기록 전체를 저장하는 대신, 최소한의 구조화된 상태(입력, 출력, 사실, 결정)를 서명하는 방식을 훨씬 선호함. 에이전트의 전체 기록을 저장하지 않고 에이전트가 가진 컨텍스트만 저장하는 식이지. 원시 사고 과정(스크래치패드)은 에이전트의 로컬 메모리 내에서만 일시적으로 유지해야 함. 핸드오프 시점이 되면 에이전트는 최종 결정과 추출된 사실을 나타내는 깔끔한 JSON 페이로드를 출력해야 해. 오직 이 최종 페이로드만 execute_step()으로 전달되고 서명됨.

Relay는 진짜 흥미로운 아키텍처네. 컨텍스트를 append-only ledger로 다루는 건 실패를 조용히 묻히게 하지 않고 눈에 보이게 만드는 구조적 제약이라 아주 좋아. 요즘 멀티 에이전트 툴링에선 보기 드문 방식임. 근데 하나 테스트해볼 점은, 암호화 서명으로 핸드오프 시점의 corruption은 잡겠지만 semantic drift는 어쩔 거임? 에이전트 1이 "confirmed"라는 키를 넘기면 에이전트 2는 이걸 "사용자 결제 승인"으로 해석하고, 에이전트 3이 그걸 실행해버리는 상황 같은 거.

1. 중요 키 누락: 에이전트 1이 {"actions": ["confirmed"]}를 전달했는데 에이전트 2가 "actions" 키를 통째로 날려버리면, Relay가 이걸 잡아내서 롤백함. 2. 엔티티 조작(환각): 새로 생성된 엔티티와 삭제된 엔티티 비율을 휴리스틱하게 검사함. 에이전트가 갑자기 1개를 삭제하면서 10개를 새로 만들어내면 환각으로 간주하고 플래그를 세움. 네 예시처럼 키는 그대로인데 값의 의미가 "확인됨"에서 "사용자 결제 승인"으로 변질되는 경우에는...