11월 13일 Anthropic은 Claude 공식 블로그에 상주 에이전트(always-on agents)의 아키텍처를 해부한 글을 올렸다. 상주 에이전트가 실제로 24시간 내내 돌아가는 것은 아니다. 평소에는 잠들어 있다가 이벤트가 도착하면 깨어나 일을 하고 다시 잠든다. 모델의 판단력이 좋아지고 추론 비용이 낮아지면서 이런 에이전트는 시연 단계를 지나 실용 단계로 접어들고 있다. 장기 과제에서 Opus 5.5는 Opus 5보다 과제 하나를 해결하는 비용이 78% 낮다. Anthropic은 이미 고객들이 이런 경험을 자사 제품에 어떻게 구현하는지 묻고 있다고 밝혔다.
다섯 가지 기본 요소는 각각 무엇을 하나
상주 에이전트는 일반 에이전트와 같은 핵심 루프를 공유한다. 차이는 바깥 아키텍처에 있으며, 다섯 가지 기본 요소로 구성된다. 이벤트 인박스는 '받는' 역할을 한다. 웹훅, 예약 작업, 백그라운드 작업은 모두 먼저 이벤트를 데이터베이스 테이블에 쓰고, 중복을 제거한 뒤 워커가 꺼내 실행한다. 덕분에 두 이벤트가 동시에 도착해 실행이 충돌하거나, 충돌로 이벤트가 사라지는 일을 막을 수 있다. 타이머는 '능동성'을 맡으며, 후속 조치와 일정 두 종류가 있다. 전자는 에이전트가 스스로 정한 마감 시간이고, 후자는 일일 브리핑 같은 고정된 주기의 반복 작업으로, 스케줄러가 주기적으로 조회해 실행한다.
메모리는 여러 번으로 나뉜 실행 사이에서 연속성을 유지한다. 다른 곳에서 다시 찾을 수 없는 것만 저장하며, 사용자 지침, 사용자 메모, 이미 보낸 메시지, 작업 진행 상황 네 가지로 나뉜다. Anthropic 자사 제품에서는 파일 디렉터리로 구현돼 있다. 권한은 가장 위험한 부분이다. 무인 실행은 사용자의 자격 증명을 쥐고 있기 때문에, Anthropic은 요청이 나가기 전에 프록시를 통해 자격 증명을 주입하고, 자동 모드에서 고위험 작업을 차단하며, 도구 호출을 연기해 사용자 확인을 받은 뒤 이어가라고 권한다. 아웃박스는 결과를 사용자에게 전달하는 속도를 조절한다. 너무 자주 보내면 방해가 되고, 너무 조용하면 놓친다. Anthropic은 먼저 조용히 시작한 뒤 서서히 사용자의 관심을 얻어가라고 권한다.
누가 쓸 수 있고, 한계는 어디인가
이 아키텍처는 기존 에이전트를 능동적으로 만들고 싶은 팀이나 상주 경험을 처음부터 구축하려는 팀에 맞는다. 대표적인 경우는 고객 후속 조치, 정기 브리핑, 무인 백그라운드 작업이다. 다만 이것이 해결하는 것은 언제 깨어나고, 깨어났을 때 무엇을 기억하며, 끝난 일을 어떻게 알리는가이지, 모델 자체의 능력 상한이 아니다. 세션이 너무 길어지면 압축하거나 다시 시작해야 하고, 남겨야 할 정보는 그때그때 메모리에 기록해야 한다. 매번 실행마다 컨텍스트 오버헤드도 생기므로, Anthropic은 초기 컨텍스트를 가볍게 유지하고 프롬프트 캐싱으로 비용을 낮추라고 권한다.
Anthropic은 이 글을 제품 발표가 아니라 구축 가이드로 자리매김했으며, 새 제품이나 출시일은 발표하지 않았다. 개발자는 다섯 가지 기본 요소를 기준으로 자사 아키텍처의 빈틈을 점검할 수 있고, 에이전트 프로토콜이 실제로 어떻게 동작하는지도 함께 참고하면 좋다.
