스케줄에 따라 실행되는 에이전트에게 '침묵'은 '없음'을 의미해야 한다

Locus는 자체적인 컴퓨터(브라우저, 파일 시스템 및 터미널을 가진 컨테이너)에서 작동하는 영구적이고 이름이 지정된 AI 팀원을 제공합니다. 사용자의 API 키, 사용자의 하드웨어, 계정이나 중앙 서비스가 필요 없습니다. 또한 사용자가 지켜보지 않아도 스케줄에 따라 실행될 수 있습니다.

마지막 부분이 흥미로운 설계 문제입니다.

승인 레이어와 이것이 통과시키는 이유

Operative가 수행하는 모든 도구 호출은 실행되기 전에 분류기(classifier)를 거칩니다. 삭제, 유출(exfiltration), 게시, 원격 접근 및 권한 변경은 높은 위험에서 멈춥니다. 설치 및 시스템 쓰기는 중간 위험에서 멈춥니다. 읽기(Reads)와 GET 가져오기(GET fetches)는 바로 통과합니다.

마지막 줄은 의도적인 설계 결정이며 사람들이 논쟁하는 부분입니다. 모든 것에 대해 물어보는 것이 쉬울 것이고, 그것은 더 나쁠 것입니다. 지속적으로 발생하는 프롬프트는 사람을 읽지 않고 프롬프트를 무시하도록 훈련시키며, 일단 그 습관이 생기면 이 레이어는 장식품에 불과합니다. 읽기를 통과시키는 것이 삭제 시 중단할 권리를 확보해 줍니다.

같은 정신으로 두 가지 작은 선택이 더 있습니다:

• 거부는 오류로 던져지는 것이 아니라 도구 결과(tool result)로 주입됩니다. 모델은 거부되었음을 보고하고, 작동하지 않은 내용을 보고하며, 모호하게 실패하거나 같은 장소에 도달하기 위해 다른 경로를 시도하는 대신 그렇게 합니다.
• 전체 명령이 아닌 프로그램 이름에 대한 '항상 허용(Always allow)' 키를 사용합니다. 정확한 문자열을 승인한다는 것은 그 문자열을 승인한다는 의미이며, 플래그가 하나 변경된 다음 호출은 사용자가 결코 내리지 않은 새로운 결정입니다.

그리고 스케줄러를 추가하면 모든 것이 망가진다

루틴(Routines)은 아무도 없는 새벽 3시에 동일한 Operative와 동일한 도구로 실행됩니다. 그렇다면 스케줄된 실행이 승인에 부딪히면 어떻게 될까요?

매력적인 답변들은 모두 잘못되었습니다. 자동 승인은 안전 레이어가 필요할 때만 존재하는 것처럼 만듭니다. 중간 위험만 자동 승인하면, 아무도 읽지 않는 두 번째로 느슨한 정책을 발명한 것입니다. 대기열에 넣고 기다리면, 에이전트가 완료되지 않은 작업을 8시간 동안 붙잡고 있게 됩니다.

침묵은 동의가 아닌 거절이다. 승인이 필요한 루틴이 5분 이내에 답변을 받지 못하면, 중단하고 needed_approval을 기록하며 보고합니다. 행동하지 않습니다.

단일 턴 경로로 인해 정책이 표류할 수 없음

루틴이 요청하는 사람과 다르게 조용히 행동할 수 없는 이유는, 그것이 표류할 두 번째 구현체가 없기 때문입니다. 인간의 메시지, 예약 실행(scheduled run), 다른 Operative로부터의 인계는 모두 동일한 턴 코드를 구동합니다. 승인, 도구 전송(tool dispatch), 메모리 쓰기, 오류 처리: 하나의 경로입니다.

이것은 깔끔함처럼 들리지만 실제로는 안전 속성(safety property)입니다.