Grok Bot에 메시지를 보내면 대화별 대기열과 중단 가능한 작업 흐름이 요청을 처리하고, 오래 걸리는 일은 별도의 보조 에이전트에 맡긴다. 이 글은 Lee Robinson의 발표를 바탕으로 작동 방식을 설명하며, 발표에서 다루지 않은 일부 구현 세부사항은 글쓴이의 추정이라고 밝힌다.

메시지 처리와 작업 흐름

앱은 서버 응답을 기다리지 않고 메시지를 바로 표시한 뒤 고유 ID를 붙여 저장한다. 서버는 이미 처리한 ID의 메시지를 걸러내므로, 연결이 불안정해 재전송되더라도 같은 메시지를 두 번 처리하지 않는다. 메시지는 대화별 대기열에 들어간다. 사용자가 직접 보낸 메시지는 진행 중인 에이전트 작업을 중단하지만, 보조 에이전트의 결과나 Slack 멘션, 예약된 워크플로는 대기열에 추가될 뿐 현재 작업을 끊지 않는다. 짧은 시간에 연달아 보낸 메시지는 하나의 차례로 묶일 수 있지만, 구체적인 시간 기준은 확인되지 않았다.

Grok Bot의 주 에이전트 작업 흐름은 Temporal을 사용하는 지속성 워크플로로 설명된다. 모델 호출과 도구 호출은 각각 단계로 기록되고, 완료된 단계의 결과는 저장된다. 따라서 작업이 중단되거나 서버가 오류를 내더라도 저장된 단계부터 이어갈 수 있다. 새 메시지가 현재 차례를 끊는 ‘중단 가능성’과 이미 완료한 작업을 보존하는 ‘지속성’은 별개의 속성이다.

Lee Robinson은 Temporal 사용 사실을 언급했지만 작업 루프의 구체적인 실행 방식은 설명하지 않았다. 글쓴이는 서버에서 공유 워커가 작업을 맡고, Temporal이 단계 배정과 기록을 담당할 것으로 추정한다. 차례가 끝나면 워크플로는 신호를 기다리며 멈추고, 에이전트는 약 2분 동안 아무 활동이 없으면 잠든다고 한다. 이때 작업 상태가 워커 메모리에 남지 않기 때문에, 글은 에이전트가 계속 대기하는 듯 보이면서도 실제로 계속 실행되지는 않는다고 설명한다.

빠른 작업과 가상 머신

주 에이전트는 요청을 직접 처리하거나 보조 에이전트에 넘긴다. Notion 페이지 편집이나 GitHub 댓글 수정처럼 빠른 작업은 주 루프에서 수행할 수 있다. 셸 명령은 가상 머신(VM)을 깨울 수 있어, 셸을 많이 쓰는 작업은 오래 걸리는 작업으로 분류해 보조 에이전트에 맡긴다고 설명한다. 보조 에이전트에는 일반 작업, 컴퓨터 사용, 비디오, 클라우드 코딩 유형이 있으며, 각각 별도의 지속성 워크플로와 도구를 사용한다. 작업을 마치면 결과를 대기열에 보낸다.

에이전트 루프가 공유 서버에서 실행되는 것과 달리 VM은 별도 작업 공간이다. 글에 따르면 대화와 워크플로 단계는 데이터베이스에, 파일·기억·기술은 객체 저장소에 보관된다. VM에는 작업 파일과 복사본이 있으며, 잠들 때 메모리와 디스크 상태를 스냅샷으로 저장한다. 이에 따라 로그인 세션 같은 상태를 유지하고 VM을 교체할 수 있다고 설명한다. 글은 이를 Firecracker 마이크로VM으로 추정하며, 약 125ms 만에 부팅할 수 있다는 내용도 덧붙인다.

사용자가 여러 Grok Bot을 만들어도 VM은 하나를 공유한다. 파일과 설치된 도구, 브라우저 로그인은 함께 쓰지만, 각 봇은 서로 다른 화면과 브라우저 창을 사용해 다른 봇의 화면을 보거나 조작하지 못한다고 설명한다. 각 봇의 대화와 기억, 루틴은 서버에서 따로 관리된다.

안전과 긴 대화 처리

Grok Bot에는 에이전트의 행동을 실행하기 전에 검토하는 별도의 모델이 있으며, 주로 셸 명령을 살핀다고 한다. 검토 대상은 사용자의 프롬프트가 아니라 에이전트가 하려는 행동이다. 이메일이나 웹페이지 등 외부 콘텐츠는 지시가 아닌 데이터로 취급한다. 이메일 전송이나 Slack 게시처럼 되돌릴 수 없는 작업은 초안으로 돌려 사용자 승인을 받는다고 설명한다.

모델 제공업체의 프롬프트 캐싱을 활용하기 위해 시스템 프롬프트와 도구 목록처럼 매번 같은 내용은 앞부분에 두고, 바뀌는 메시지는 뒤에 붙인다. 글은 대화 전체를 매 차례 다시 보내므로 캐시 적중이 비용과 응답 시간에 영향을 준다고 설명한다. 글쓴이는 과거 X 게시물에서 poteto의 AI 비용을 월 1,100만 달러로 추정했지만, 프롬프트 캐싱을 반영하면 실제 액수는 월 100만 달러에 더 가깝다고 정정한다. 이는 글에서 제시한 추정치다. 관련 X 게시물

기술과 도구 설명은 프롬프트에 간단한 이름과 설명만 넣고, 실제로 필요할 때 전체 내용을 불러온다. 주 에이전트의 문맥을 작게 유지하고 무거운 작업은 보조 에이전트에 넘기는 방식도 사용한다고 설명한다.

대화 문맥이 10만 토큰을 넘고 사용자가 10~60분가량 자리를 비우면 백그라운드에서 문맥을 압축할 수 있다. 글은 캐시가 아직 유지되는 동안 압축하면 비용을 줄일 수 있다고 설명한다. 문맥 한도에 도달하면 압축을 바로 수행하며 주 작업이 기다려야 한다. Grok Bot의 문맥 한도는 약 20만 토큰이라고 한다. 압축은 모델이 사용하는 작업 문맥에만 적용되며, 실제 대화 기록은 삭제되지 않아 전체 대화를 다시 볼 수 있다고 설명한다.

Grok Bot의 개선은 두 주기로 이뤄진다고 한다. 팀은 매일 버그를 찾아 하네스, 프롬프트, 추론을 수정하고 평가를 거쳐 배포한다. 몇 달 간격으로는 수집한 실패 사례를 바탕으로 새 모델을 훈련한다. 글쓴이는 에이전트가 빠른 작업과 보조 에이전트 중 무엇을 선택했는지 관찰하는 체계가 있을 것으로 추정하지만, 이는 확인된 설명이 아니다.

글의 끝에는 워커 운영 방식, 메시지 묶음 기준, 중단 시 도구 호출 처리, 보조 에이전트 간 관계, VM 복원 시간, 문맥 압축 방식 등 발표에서 답하지 않은 질문이 제시된다.