Anthropic에서 Claude Managed Agents를 만든 엔지니어링 팀을 이끄는 Priyanka와 같은 팀의 Gabe(자막 표기 Gabe Semach)가 2시간짜리 워크숍을 진행한다. AI Engineer 채널은 이 워크숍을 1부, 2부, 3부, 4부로 나누어 올렸고, 이 노트는 네 편을 하나로 묶었다. 1부에서 Priyanka가 Managed Agents의 아키텍처가 어떻게 바뀌었는지 설명하고, 2부와 3부에서 Gabe가 금융 리서치 에이전트를 직접 만들어 보인다. 2부 중간과 3부 후반, 4부 전체는 청중과 나눈 질의응답이다.
워크숍이 다루는 질문은 프로덕션 에이전트를 어떤 인프라 위에 올려야 하는가이다. Priyanka의 답은 하네스에는 모델에 대한 가정이 담겨 있고 그 가정은 결국 낡는다는 관찰에서 출발한다. 모델이 바뀔 때마다 하네스를 고쳐야 하므로, 세션 기록과 에이전트 루프(두뇌), 샌드박스와 도구(손)를 서로 분리된 인터페이스로 설계해야 한다는 것이다. Anthropic은 처음에 모든 것을 컨테이너 하나에 넣었다가 운영 문제를 겪고 이 구조로 바꿨다. 개발자는 이 구조 위에서 환경, 에이전트, 세션이라는 기본 단위에 스킬, 서브에이전트, 메모리 스토어, 아웃컴(outcomes), 배포(deployments), 드리밍(dreaming)을 조합해 자기 제품을 만든다.
질의응답에서 발표자들이 거듭 강조하는 관점은 두 가지다. 모델이 똑똑해질수록 사람이 정해 둔 제약은 걷어 내야 하고, 무엇이 효과가 있는지는 평가(eval)로 판단해야 한다. 발표자들은 멀티테넌시와 자격 증명 관리, Claude Code나 Claude Cowork와의 차이처럼 실제로 제품을 만들 때 부딪히는 질문에도 이 관점을 바탕으로 답한다.
하네스는 모델의 빈틈에 대한 가정을 담고 있어서 모델이 바뀔 때마다 다시 맞춰야 한다
Priyanka는 에이전트를 '도구를 쓰면서 루프를 도는 모델'로 정의한다. 모델이 다음 행동을 정하고, 작업이 끝날 때까지 도구를 반복해서 호출한다. 하네스는 이 모델을 감싸는 층이다. 도구 호출 루프를 돌리고 컨텍스트를 관리하면서 모델이 스스로 하지 못하는 부분을 대신 메운다. 그래서 하네스에는 모델이 무엇을 못 하는지에 대한 가정이 들어간다.
Priyanka가 드는 예는 Sonnet 4.5의 '컨텍스트 불안(context anxiety)'이다. Sonnet 4.5는 컨텍스트 한도에 가까워졌다고 느끼면 작업을 서둘러 마무리하려 했다. 그래서 Sonnet 4.5용 하네스에는 컨텍스트를 초기화하는 장치를 넣어야 했다. 하지만 다음 모델인 Opus 4.5에는 이 문제가 없었으므로 초기화 장치도 필요 없었다. 하네스를 만드는 사람은 모델마다 다른 가정을 담아 두고 새 모델이 나올 때마다 그 가정을 갱신해야 한다. Priyanka는 좋은 하네스를 만드는 일이 중요한 이유가 여기에 있다고 말한다.
Anthropic이 하네스를 어떻게 갱신하는지는 4부의 질의응답에서 나온다. 발표자들에 따르면 Anthropic은 새 모델을 외부보다 먼저 받아 볼 수 있으므로, 관리형 서비스를 운영하는 입장에서 하네스에 담긴 가정을 최대한 일찍 고치고 더 이상 필요 없는 장치를 걷어 낸다. 이 작업은 모두 평가를 기준으로 이루어진다. 내부 도구로 여러 데이터 세트를 만들고, 클라우드에서 세션 1만 개를 병렬로 실행해 결과를 평가한 뒤 프롬프트와 가정을 조정한다. 평가 대상은 코딩에 한정되지 않고 범용 작업 전반이다.
모든 것을 컨테이너 하나에 넣은 첫 설계는 잃어서는 안 되는 '애완동물'을 만들었다
에이전트에는 하네스 말고도 샌드박스, 즉 자기가 작성한 코드를 실행할 컴퓨터가 필요하다. 에이전트는 샌드박스에서 파일을 고치고 의존성을 설치한다. Claude Code가 좋은 예다. Claude Code는 사용자의 컴퓨터에서 로컬로 실행되는 하네스이며, 파일에 접근해 작업하면서 그 파일을 고친다. Priyanka는 에이전트가 쓴 코드는 신뢰할 수 없고 버그가 있을 수도 있으므로, 프로덕션 에이전트에서는 코드를 컨테이너 안에 가두어 실행해야 한다고 강조한다. 샌드박스는 서로 격리하고 작업마다 별도 컨테이너에서 실행해서, 문제가 생겼을 때 피해 범위(blast radius)를 줄여야 한다.
Anthropic은 작년 12월에 첫 아키텍처를 얼리 액세스 고객에게 내놓았고, 피드백을 받은 뒤 새 아키텍처로 방향을 바꿨다. 첫 아키텍처에서는 세션 로그와 하네스, 샌드박스 실행이 모두 컨테이너 하나에 들어 있었다. 여기서 세션은 작업 단위이고, 세션 로그는 그 세션에서 일어난 모든 일의 기록이다. 모든 것이 로컬에 있으니 설계해야 할 서비스 경계가 없었고, 파일 편집도 시스템 콜 하나로 끝났다.
문제는 이 구조가 애완동물이었다는 점이다. Priyanka는 예전 인프라 업계에서 쓰던 애완동물(pet)과 가축(cattle) 비유를 가져온다. 애완동물은 이름을 붙여 손수 돌보는 대상이라서 아프면 살려 내야 하고, 잃어서는 안 된다. 가축은 서로 바꿀 수 있어서 하나가 쓰러지면 다른 것으로 대체하고 넘어간다. 데이터베이스 샤드가 하나뿐이라서 그것이 죽으면 제품 전체가 멈춘다면 애완동물을 키우는 셈이다. 마스터와 레플리카를 두어 마스터가 죽어도 레플리카를 올리면 된다면 가축이다.
애완동물이 된 컨테이너는 여러 문제를 낳았다. 먼저 디버깅이 어려웠다. 모든 것이 컨테이너 안에서 돌아가니 무엇이 문제를 일으켰는지 알 수 없었고, 패킷이 유실된 경우와 컨테이너가 죽은 경우가 겉으로는 거의 똑같이 보였다. 디버깅하려면 웹소켓으로 컨테이너 안에 스트림을 연결해야 했다. 고객 데이터가 그 컨테이너에 있었기 때문에 Anthropic이 안으로 들어가 조사할 방법도 없었다. 고객이 자기 VPC 안에 있는 MCP 서버에 연결해 달라고 하면 네트워크를 피어링하거나, 하네스를 고객에게 보내 직접 돌리게 해야 했다. 팀은 이 구조 안에서는 이런 문제를 해결할 방법을 찾지 못했고, 두뇌와 손을 분리하기로 했다.
세션, 두뇌, 손을 분리하자 세션 로그를 뺀 모든 구성 요소가 교체 가능해졌다
새 구조에서 에이전트는 독립된 인터페이스 세 개로 나뉘었다. 세션은 지금까지 일어난 모든 일을 추가 전용 로그(append-only log)로 기록한다. 두뇌(brain)는 하네스, 즉 Claude를 포함한 에이전트 루프다. 손(hands)은 샌드박스와 MCP 도구 호출처럼 필요할 때 프로비저닝되고 작업이 끝나면 사라지는 실행 수단이다.
이렇게 나누자 세션 로그를 뺀 모든 구성 요소가 가축처럼 교체 가능해졌다. 샌드박스가 죽으면 그 오류는 다른 도구 호출이 실패했을 때처럼 Claude에게 돌아가고, Claude가 샌드박스를 다시 시작할지 그냥 계속 진행할지 판단한다. 하네스가 죽으면 새 하네스 인스턴스를 시작하고 세션의 이벤트 로그를 읽어 마지막 이벤트부터 이어 가면 된다. 작업은 아무 일도 없었던 것처럼 재개된다. Priyanka는 이제 지켜야 할 것은 세션 로그 하나뿐이라고 말한다.
두뇌 하나가 여러 손과 연결될 수 있다. 에이전트 루프는 샌드박스 컨테이너를 호출할 수도 있고, 고객의 VPC나 MCP 서버를 호출할 수도 있다. 손은 모두 교체 가능하므로 여러 개를 연결해 쓸 수 있고, 아키텍처도 훨씬 유연해졌다.
Priyanka가 이 이야기에서 하나만 기억하라며 꼽는 교훈은, 하네스가 가정을 담고 있고 그 가정은 낡는다는 것이다. 그래서 팀은 가정보다 수명이 긴 인터페이스를 설계했다. 덕분에 컴팩션 전략을 바꾸거나 하네스를 통째로 교체해도 인터페이스와 아키텍처는 그대로 유지된다. 그 인터페이스가 정확히 무엇이냐는 청중의 질문에 Priyanka는 추가 전용 세션 로그, 교체 가능한 하네스, 그리고 샌드박스나 도구 호출처럼 모델에 필요한 것을 연결하는 손을 다시 꼽는다. 이 세 가지 덕분에 구조가 범용적이고 확장 가능해진다는 것이다.
Gabe는 2부 첫머리에서 첫 번째 설계와 두 번째 설계 사이에 세션 저장 방식이 어떻게 바뀌었는지 설명한다. 팀은 가능한 한 많은 것을 추상화해 별도 구성 요소로 나누었다. 그래서 앞으로 새로운 종류의 이벤트를 저장하게 되더라도, 세션 작업의 동작 방식과 강하게 결합되지 않은 채 저장 메커니즘을 확장할 수 있다. 인터페이스를 만들고 가상화하는 원칙을 서비스 경계뿐 아니라 이벤트 계층에까지 적용했다는 것이다.
이벤트 로그를 버리지 않으니 컴팩션 전략이 유연해지고, 손을 필요할 때만 실행하니 첫 응답이 빨라졌다
세션이 추가 전용 이벤트 로그를 갖고 있으므로 컴팩션 전략도 유연하게 바꿀 수 있다. Priyanka에 따르면 Managed Agents는 이벤트 스트림을 압축하거나 변경하지 않고 모든 이벤트를 저장해 둔다. 무엇을 컨텍스트에 넣을지는 컴팩션 전략이 정한다. 전체 이벤트 로그를 요약해 넣을 수도 있고, 마지막 N개 이벤트만 넣을 수도 있다.
두뇌와 손을 분리하자 응답 속도도 빨라졌다. 이제는 추론 호출을 곧바로 시작하고 샌드박스는 Claude가 필요로 할 때만 시작하므로, 첫 토큰을 받기 위해 컨테이너가 준비되기를 기다릴 필요가 없다. Priyanka는 이 변경으로 첫 토큰까지 걸리는 시간을 약 90% 줄였다고 말한다.
긴 세션도 이 구조 위에서 돌아간다. 3부에서 에이전트를 얼마나 오래 돌릴 수 있느냐는 질문에 발표자들은 Managed Agents가 컴팩션을 대신 실행해 주므로 며칠씩 돌릴 수 있다고 답한다. 프로덕션에서 일부 사용자가 10시간짜리 세션을 돌리는 것도 봤다고 한다. 매일 하는 작업이라면 반년 동안 계속 돌려도 영속 저장소가 감당한다는 것이 발표자들의 답이다. 4부에서도 6시간이 넘게 걸리는 세션을 위해 따로 할 일은 없으며, 세션은 그냥 계속 돌아간다고 말한다.
자격 증명은 샌드박스에 들어가지 않고 밖으로 나가는 지점에서 주입된다
첫 설계에서는 자격 증명이 샌드박스 안에 있었으므로 프롬프트 인젝션에 더 취약했다. 새 구조에서는 자격 증명이 샌드박스에 절대 들어가지 않는다. 샌드박스가 토큰이나 접근 권한이 필요한 외부 엔드포인트나 MCP를 호출하면, 그 요청은 프록시를 거치고 프록시가 토큰을 넣은 뒤에 외부로 나간다. Priyanka는 Claude가 토큰을 한 번도 보지 못하므로, 프롬프트 인젝션으로 토큰을 출력하거나 파일에 쓰라고 시켜도 Claude가 그렇게 할 수 없다고 설명한다.
2부에서 SEC 데이터를 가져오는 데 자격 증명이 필요하냐는 질문을 받자, Gabe는 이 원리를 구현한 볼트(vaults)를 소개한다. SEC는 호출하는 사람의 이름과 이메일만 요구하므로 데모에서는 이를 프롬프트에 넣었지만, 실제 프로덕션이라면 볼트를 쓴다. 비밀 값을 환경 변수로 주입하도록 정의하되, 실제 값 대신 자리 표시자(placeholder)를 넣는다. Claude가 그 환경 변수를 쓰면 자리 표시자가 그대로 나가고, Anthropic이 외부로 나가는 지점(egress)에서 이를 실제 값으로 바꾼다. 이 교체는 그 비밀 값에 허용한 호스트 도메인으로 가는 요청에서만 일어난다. SEC 전용으로 지정한 값을 Claude가 anthropic.com 호출에 쓰려 하면 교체하지 않고, SEC를 호출할 때만 교체한다.
Priyanka는 볼트를 쓰는 방법을 덧붙인다. 콘솔에서 볼트를 만들고 이름을 붙이면 ID가 나오고, 세션에 그 ID를 넣으면 Anthropic이 그 정보로 MCP나 CLI를 인증한다. 예를 들어 Google Workspace CLI를 샌드박스에 설치하고 API 키를 환경 자격 증명으로 넘길 수 있으며, 볼트는 OAuth 자격 증명도 지원한다. Gabe는 콘솔에서 볼트 하나에 여러 자격 증명을 묶을 수 있고, Notion처럼 OAuth 설정이 미리 준비된 서비스도 있다는 것을 보여 준다. 세션에 볼트 ID를 넣으면 그 안의 자격 증명이 모두 세션에 연결되고, 지정한 도메인을 호출할 때마다 자리 표시자가 실제 자격 증명으로 바뀐다.
사내 데이터와 특수한 실행 환경은 터널과 자체 호스팅 샌드박스로 연결한다
Gabe에 따르면 Managed Agents는 Anthropic의 자체 인프라에서 돌아가며, AWS 크레딧을 쓰고 싶다면 AWS용 Claude Platform을 쓸 수 있다. 사용자가 직접 마련한 샌드박스를 쓸 수도 있다. Modal, Daytona, 자막에서 Burcell로 표기된 제공자 같은 여러 업체의 샌드박스를 쓰거나, Google Cloud와 AWS에서 자기 샌드박스를 돌릴 수 있다.
회사 데이터를 CLI나 MCP로 에이전트에 노출하려 할 때 안전한 방법을 묻는 질문에, 발표자들은 몇 가지 길을 제시한다. 데이터에 API를 감싼 CLI나 MCP로 접근할 수 있는 경우에는, MCP를 만들고 인증용 볼트를 연결해 두면 에이전트가 그 MCP를 직접 호출한다. MCP를 인터넷에 노출하고 싶지 않다면 MCP 터널(MCP tunnels)로 사내 네트워크에서 Anthropic 네트워크로 터널을 연다. 그 방법도 받아들이기 어렵다면 사내 네트워크와 피어링된 자체 호스팅 샌드박스를 연결해 쓰면 된다. 에이전트는 사용자가 관리하고 호스팅하는 그 샌드박스를 호출해 사내 애플리케이션과 서비스에 접근한다.
계산 자원을 조정할 때도 같은 방식을 쓴다. 4부에서 메모리를 더 많이 쓰거나 GPU가 필요한 경우를 묻는 질문에, 발표자들은 지금 Anthropic이 제공하는 샌드박스는 모두 같은 사양이므로 자원을 따로 할당하려면 자체 호스팅 샌드박스를 쓰라고 답한다. GPU를 제공하는 Modal과 연동하는 퍼스트파티 통합 기능과 쿡북이 마련되어 있어서, 에이전트 루프를 Anthropic 샌드박스 대신 Modal 인스턴스에서 돌릴 수 있다. 문서에는 Modal과 Daytona, 자막에서 EB2로 표기된 제공자 등 여러 샌드박스 제공자와 통합하는 쿡북이 있다.
에이전트를 쓰려면 환경과 에이전트 정의, 세션을 차례로 만든다
Priyanka는 핵심 API를 세 단계로 소개한다. 첫 단계에서는 환경 API(v1/environments)로 샌드박스의 템플릿을 만든다. 환경에는 네트워크 설정이 들어가며, 네트워크를 제한 없이 열지 특정 도메인이나 MCP로만 제한할지 정한다. 컨테이너에 설치할 패키지도 여기서 정의한다. 질의응답에 따르면 패키지는 환경을 만들 때 설치되고, 캐시되어 샌드박스를 다시 시작할 때마다 재사용된다. 지금은 npm, cargo, pip처럼 공개 저장소에서 받을 수 있는 패키지여야 하지만, 파일이나 GitHub 저장소를 세션에 직접 올려 설치하는 방법도 있다.
두 번째 단계에서는 에이전트를 만든다. 워크숍 예제에서는 에이전트 이름을 joke teller로 짓고, 모델은 Opus, Haiku, Sonnet 가운데 하나를 고른다. 시스템 프롬프트에는 '너는 코미디언이니 주제에 맞는 새로운 농담을 찾아 잘 전달하라'는 지시를 쓴다. 도구로는 bash, read, write, grep 등이 들어 있는 기본 도구 모음인 agent toolset을 준다. Priyanka는 거의 모든 에이전트에 이 도구 모음이 필요하다고 말한다. 세 번째 단계에서는 에이전트 ID와 환경 ID를 넘겨 세션을 만든다. 세션은 작업 단위이며, 처음 만들어졌을 때는 유휴(idle) 상태로 있다가 이벤트를 받아야 일을 시작한다.
2부 초반에 Priyanka는 콘솔의 빠른 시작(quick start)으로 같은 과정을 코드 없이 보여 준다. '주제를 주면 농담을 해 주는 에이전트를 만들어 달라'고 입력하면, Claude가 시스템 프롬프트와 이름, 설명을 쓰고 모델을 고른다. 에이전트 생성 버튼을 누르면 v1 agents 엔드포인트가 호출된다. 이어서 환경을 만든다. Priyanka는 데모에서는 네트워크를 제한 없이 열었지만 프로덕션 에이전트라면 접근 가능한 도메인이나 MCP 서버를 제한해야 한다고 덧붙인다. 세션을 시작해 고양이 농담을 요청하자 모델이 잠시 생각한 뒤 농담을 내놓는다.
Priyanka는 이렇게 만든 에이전트가 이미 클라우드에서 돌아가고 있으며, 개발자는 세션을 시작하고 이벤트를 보내고 이벤트를 받기만 하면 된다고 말한다. 인프라, 호스팅, 하네스, 샌드박스 관리, 확장, 이벤트 로그 저장은 Anthropic이 맡으므로 개발자는 그 위에 제품을 만드는 데 집중할 수 있다.
세션과 주고받는 모든 소통은 이벤트 스트림 하나로 이루어진다
세션의 이벤트 스트림에는 사용자가 보내는 이벤트와 에이전트가 돌려주는 이벤트가 함께 오간다. 사용자가 분산 시스템에 관한 농담을 해 달라는 사용자 메시지를 보내면 에이전트가 농담으로 답한다. 커스텀 도구(custom tool)를 정의해 두면 Claude가 스트림에 agent.custom_tool_use 이벤트를 올리고, 사용자는 그 이벤트를 받아 처리한 결과를 user.custom_tool_result 이벤트로 돌려준다. 이 밖에도 세션에 오류가 생기면 session.error 이벤트가 오고, 세션이 일하지 않을 때는 session.status_idle 이벤트가 온다. 작업을 멈추거나 세션을 끝내고 싶으면 user.interrupt 이벤트를 보낸다.
Gabe는 2부에서 이 스트림을 활용해 채팅 화면을 만든다. 채팅창에서 엔터를 누르면 백엔드가 입력 내용을 사용자 메시지 이벤트로 세션에 보내고, API에서 받은 SSE 스트림을 다시 브라우저로 전달해 화면에 그린다. Gabe는 채팅형 애플리케이션을 만들려면 여기서 멈춰도 되지만, Managed Agents의 핵심은 몇 분이 아니라 몇 시간, 며칠, 몇 주, 몇 달씩 걸리는 비동기 작업을 돌리는 데 있다고 말한다.
진행 중인 세션에도 메시지를 보내 작업 방향을 바꿀 수 있다. 콘솔에서 서브에이전트 기록을 보다가 잘못된 방향을 발견하면 어떻게 고치느냐는 질문에, 발표자들은 새 사용자 메시지 이벤트를 보내 에이전트를 조종(steer)하면 된다고 답한다. 메시지는 큐에 쌓이므로 한 번에 열 개를 보내도 괜찮다. 다만 특정 시점으로 되돌렸다가 다시 진행하는 기능은 아직 없다. 발표자들은 이를 세션 포킹(session forking)이라 부르며, 여러 고객이 요청한 기능이라 로드맵에 올라 있다고 말한다.
메시지를 보낼 수 없는 예외는 커스텀 도구 결과를 기다릴 때다. 4부에서 발표자들은 모델이 커스텀 도구 결과를 기다리는 동안에는 실행을 멈추고, 이벤트 순서를 지키기 위해 다른 메시지를 막는다고 설명한다. 이때 메시지를 보내면 400 오류가 돌아온다. 이 제약을 피하는 방법으로 발표자들은 코디네이터 패턴을 제안한다. 커스텀 도구를 서브에이전트에 정의하면 메인 코디네이터 에이전트는 언제든 메시지를 받을 수 있다. 서브에이전트는 기술적으로는 다른 스레드에서 돌지만 같은 세션에 속하며, 사용자는 메인 스레드와만 메시지를 주고받으면 된다. Anthropic이 ID를 보고 메시지를 알맞은 곳으로 전달하기 때문이다. 메인 스레드가 유휴 상태여도 서브에이전트는 계속 일할 수 있으므로, 메인 에이전트가 늘 대화에 응하게 하고 싶다면 이 패턴이 잘 맞는다.
긴 작업의 진행 상황도 이벤트 스트림으로 확인한다. 세션에 속한 events API를 조회하면 되고, 사람에게 상태를 알리는 커스텀 도구를 만들어 두면 Claude가 진척이 있다고 판단할 때마다 그 도구를 호출해 상태를 알려 준다.
관측성(observability)도 이벤트를 바탕으로 확보한다. 3부에서 텔레메트리 계측이 기본으로 들어 있느냐는 질문에, 발표자들은 세션에서 일어난 모든 이벤트를 볼 수 있다고 답한다. 콘솔의 transcript 화면은 이벤트를 보기 좋게 정리해 보여 주고, debug 화면에는 모델 호출이 언제 시작되고 끝났는지까지 모든 이벤트가 나오므로 지연 시간 지표도 얻을 수 있다. 무엇을 관측할지는 미리 정해 두지 않았으며, 모든 이벤트를 받아 사용자 쪽에서 걸러 쓰면 된다. 이벤트를 OTEL 같은 자체 관측 스택으로 내보내고 싶다면 API로 커넥터를 쉽게 만들 수 있다. 발표자들은 요구 사항이 사람마다 달라서 특정 방식을 강요하고 싶지 않다고 말한다.
스킬과 서브에이전트, 메모리 스토어로 에이전트를 더 유능하게 만든다
Gabe가 2부와 3부에서 만드는 예제는 리서치 데스크라는 금융 리서치 애플리케이션이다. 워크숍 저장소에는 실습을 단계별로 안내하는 스킬이 들어 있어서, Claude Code에서 workshop start를 입력하면 여섯 막으로 나뉜 실습이 시작되고 workshop next를 입력할 때마다 다음 막으로 넘어간다. 처음에 만드는 것은 환경과 기본 에이전트다. 환경은 SEC를 비롯한 몇몇 웹사이트에만 접근을 허용하고, SEC를 호출하는 Python 패키지를 설치한다. 에이전트에는 프롬프트와 기본 도구만 있고, 스킬이나 서브에이전트 조율은 없다.
다음 단계에서 Gabe는 에이전트의 능력을 강화한다. 먼저 SEC 웹사이트에서 종목별 공시를 가져와 특정 공시 양식(form)을 분석하는 스킬을 준다. 스킬에는 Python 패키지를 쓰는 방법과 EDGAR 식별 정보로 호출해야 한다는 내용이 들어 있다. 그다음 에이전트의 새 버전을 만들어, 일을 맡길 수 있는 전문 서브에이전트 여러 개와 자기 자신에 대한 참조를 넣는다. 자기 참조를 넣으면 메인 에이전트가 같은 프롬프트를 가진 자기 복사본을 서브에이전트로 실행할 수 있다. 어떤 작업이 생길지 미리 알 수는 없지만 서브에이전트를 실행해 일을 나누고 싶을 때 쓸모가 있다. Gabe는 자주 받는 질문이라며, 이때 세션 기록은 복사되지 않고 도구 설명과 스키마, 프롬프트만 서브에이전트에 넘어간다고 강조한다.
마지막으로 메모리 스토어를 연결한다. Managed Agents는 여러 세션이 함께 쓰는 장기 메모리 스토어를 지원하며, 데모에서는 각 세션이 서로 다른 금융 상품에 대해 배운 내용을 이 스토어로 공유한다. Gabe는 이 장기 메모리로 며칠, 몇 달, 몇 년에 걸쳐 에이전트를 계속 개선할 수 있다고 말한다. Priyanka는 한 세션에 메모리 스토어를 여러 개 연결할 수 있으므로, 사용자 단위 메모리와 조직 전체 메모리를 함께 연결해 양쪽 메모리에 모두 내용을 쌓을 수 있다고 덧붙인다.
메모리가 Anthropic 인프라에 저장된다면 사용자가 Anthropic에 얼마나 종속되느냐는 질문에 Gabe는 모든 것이 API 기반이므로 메모리를 꺼내 다른 시스템에 넣을 수 있다고 답한다. 세션 안에서 다른 메모리 제공자를 기본으로 지원하지는 않지만, MCP나 커스텀 도구를 만들어 연결하면 된다. Priyanka도 모든 것이 API 호출이라 종속되는 부분이 없고, 데이터를 가지고 어디로든 옮길 수 있다고 말한다.
스킬은 계속 고쳐 쓸 수 있는 산출물(live artifacts)이다. Gabe는 데모에서 스킬에 새 공시 양식을 분석하는 기능을 추가하고, 이후 그 스킬을 참조하는 새 세션은 모두 갱신된 내용을 받는다는 것을 보여 준다. 이전 세션이 작업을 어떻게 수행했는지 살펴보고 스킬을 개선할 수도 있다.
아웃컴은 에이전트가 루브릭에 비추어 스스로 작업을 검수하게 만든다
Gabe는 채팅이 아니라 비동기 작업을 맡기는 방법으로 아웃컴(outcomes)을 소개한다. '이 금융 상품을 조사해서 내가 정한 형식으로 보고서를 만들어 달라'는 식의 작업이 그 예다. Gabe는 Anthropic이 자기 감독(self-supervision)을 구현한 방식이 바로 아웃컴이라고 설명한다. 아웃컴에는 작업과 그 작업을 평가할 루브릭을 함께 준다. Claude는 작업을 마쳤다고 판단하면 서브에이전트에게 루브릭과 결과물을 보여 주고, 작업을 올바르게 끝까지 해냈는지 평가하게 한다. 기준을 충족하면 작업이 끝나고, 충족하지 못하면 다시 시도한다. 데모 애플리케이션은 종목 하나에 대한 세션을 시작할 때마다 루브릭과 최대 반복 횟수, 작업 설명을 담은 사용자 정의 아웃컴 이벤트를 보낸다.
Gabe가 전날 미리 돌려 둔 Nvidia 세션이 이 흐름을 보여 준다. 아웃컴에 담긴 작업은 Nvidia의 최신 SEC 분기 공시를 분석하는 것이었다. 지시에는 EDGAR 식별 정보의 위치, 메모리에 이전 분석이 있으면 다시 조사하지 말고 그것을 쓰라는 안내, 관심 있는 최신 공시 양식을 찾아 분석하라는 요구가 들어 있었다. 결과물은 두 가지였다. 하나는 메모리에 그 회사에 관한 노트를 쓰는 것이었고, 다른 하나는 정해진 구조의 스코어카드를 지정한 위치에 파일로 저장하는 것이었다.
Claude는 메모리에서 노트를 찾지 못하자 일의 대부분을 서브에이전트에게 맡기기로 하고, 재무 정보 추출 에이전트와 위험 평가 에이전트를 실행했다. 콘솔에서는 서브에이전트마다 작업이 별도의 스레드로 표시되어 전체 과정을 볼 수 있다. 서브에이전트들이 일을 마치고 메인 에이전트에 알리자, 메인 에이전트가 다시 작업을 시작해 결과를 받아 정리하고 JSON 스코어카드를 만든 뒤 메모리를 갱신했다. 그러고 나서 자기 감독이 시작되었다. 검증용 서브에이전트가 루브릭을 보고 세션의 작업과 산출물을 분석한 끝에, 스코어카드가 제출되었고 수치가 잘 정의되었으며 메모리 갱신도 올바르다고 판정했다.
검수는 세션 전체 수준에서만 이루어진다. 채점자가 메인 에이전트 수준에만 있는데 서브에이전트의 작업은 어떻게 채점하느냐는 질문에, Gabe는 서브에이전트가 서로 협업하며 세션의 컨텍스트와 능력을 보강하는 역할을 하고 아웃컴은 세션 전체를 대상으로 정의한다고 답한다. 메인 에이전트가 서브에이전트를 써서 일을 끝내고 완료를 선언하는 구조이며, 서브에이전트 단위의 아웃컴은 아직 지원하지 않는다.
Gabe는 4부에서 아웃컴이 아주 긴 세션을 돌리는 가장 좋은 방법이라고 말한다. 종료 기준을 정의하면 Claude가 그 기준을 충족할 때까지 계속 일하기 때문이다. 무언가를 통째로 다시 만드는 큰 작업이라도 루브릭에 맞을 때까지 끈질기게 반복한다. 3부에서 발표자들은 에이전트가 기대대로 동작하는지 확인하려면 수행할 작업 유형별로 평가를 돌려 보라고 권한다. 정확한 루브릭과 최대 반복 횟수를 정해 원하는 결과가 나올 때까지 에이전트를 이끄는 아웃컴도 좋은 방법이라고 함께 말한다.
여러 세션을 엮는 하네스와 정기 실행은 개발자가 API로 조립한다
3부에서 하네스를 어떻게 정의하느냐는 질문을 받자, 발표자들은 정의가 사람마다 다르다고 인정한다. Managed Agents에서 말하는 하네스는 주로 도구 루프를 실행하고 컨텍스트와 세션 상태를 관리하며 원하는 일을 에이전트가 해낼 수 있게 하는 부분이다. 반면 대부분의 개발자가 말하는 하네스는 여러 에이전트와 세션을 하나의 작업 단위로 엮어 더 큰 작업을 해내는 조율 구조에 가깝다. Managed Agents는 세션 하나를 작업 단위라는 기본 요소(primitive)로 제공하고, 개발자는 그것으로 자기 하네스를 만든다.
Gabe는 이를 맵리듀스 형태의 다중 세션 오케스트레이션으로 보여 준다. 앞에서 에이전트에 넣어 둔 dispatch analysis라는 커스텀 도구가 여기에 쓰인다. Google과 Microsoft를 분석해 달라고 하면 메인 에이전트는 자기가 가진 정보를 확인한 뒤 두 종목에 대해 dispatch analysis를 호출하고, 개발자의 서버는 종목마다 별도 세션을 시작한다. 각 세션 안에서는 다시 서브에이전트들이 협업하고, 아웃컴으로 스스로 검수하며, 메모리 스토어로 서로 배운다. 결과가 모두 나오면 모아서 점수로 정리한다. Gabe는 종목을 10개, 100개씩 한꺼번에 분석하고 싶을 때 이 방식을 쓰면 된다고 말한다.
정해진 일정에 따라 반복하는 작업은 배포(deployments)로 처리한다. 관심 있는 회사 목록을 매일 오전 9시나 매월 1일에 분석하고 싶을 때 쓰는 기능이다. 배포는 에이전트 정의와 실행 일정, 처음 보낼 메시지를 받고, 메모리 스토어나 GitHub 저장소, 파일 같은 리소스도 함께 받는다. 데모에 나온 research desk weekly memo 배포는 매월 1일 오후 1시쯤 지정한 세션을 실행하도록 설정되어 있고, 콘솔에서 바로 실행할 수도 있다. Gabe는 콘솔로도 플랫폼을 다룰 수 있지만 Anthropic이 의도한 주된 사용 방식은 API와 SDK이며, 모든 기능은 조합해서 더 큰 애플리케이션을 만드는 구성 요소라고 강조한다. 데모에서도 배포 목록을 보고 검색하고 실행하는 UI를 직접 만들었다.
배포와 메모리는 다른 개념이다. 배포가 특정 시점의 에이전트 전체를 찍어 둔 스냅숏이냐는 질문에, 발표자들은 배포는 특정 에이전트의 세션을 일정에 따라 실행하는 방법일 뿐이라고 답한다. 리서치 데스크 에이전트에게 분기마다 Nvidia를 조사하게 하면 분기마다 세션이 하나씩 만들어져 보고서를 낸다. 모든 세션에 걸쳐 상태를 유지하는 것은 메모리 스토어이며, 메모리 스토어는 독립된 개체여서 필요한 세션에 연결해 쓸 수 있다.
에이전트 설정도 코드로 관리할 수 있다. 4부에서 에이전트 설정을 CI/CD로 관리하는 방법을 묻자, 발표자들은 API를 감싼 CLI(자막 표기 Ancho CLI)를 소개한다. 이 CLI는 YAML을 입력으로 받아 Terraform 같은 방식으로 리소스를 관리할 수 있으므로, 오래 유지할 리소스를 YAML로 코드베이스에 두고 변경할 때마다 CI/CD가 이 CLI로 리소스를 갱신하게 만들 수 있다. 발표자들은 Anthropic도 오래 쓸 리소스가 필요하면 이렇게 코드로 체크인해 관리한다고 말한다.
확장 설정은 따로 할 필요가 없다. 쿠버네티스의 HPA처럼 최소 파드 수나 타임아웃 같은 확장 매개변수를 정할 수 있느냐는 질문에, 발표자들은 속도 제한(rate limit)은 있지만 세션은 원하는 만큼 만들 수 있다고 답한다. 확장은 Anthropic이 모두 관리하므로 개발자는 API를 호출하기만 하면 된다.
드리밍은 지난 세션 기록을 분석해 메모리를 고쳐 쓴다
Gabe는 3부에서 자기 개선 기능인 드리밍(dreaming)의 연구 프리뷰를 보여 준다. 드리밍을 실행하려면 메모리 스토어와 모델을 고르고, 필요하면 맞춤 지시를 주거나 기본 프롬프트를 쓰면 된다. 데모에서는 그 메모리 스토어를 쓴 지난 30일치 세션을 분석 대상으로 삼았다. 드리밍을 시작하면 Managed Agents에서 세션 하나가 시작되고, 그 세션이 여러 서브에이전트를 실행해 지난 세션 각각의 기록을 분석한다. 메모리 스토어에 필요한 정보가 모두 담겼는지, 어떤 세션이 문제를 겪었는지, 거기서 배울 점이 있는지, 같은 일이 여러 번 일어났는지, 지시를 고칠 수 있는지를 따진다.
데모에서 드리밍은 워크숍에서 만든 스킬의 작성 방식에서 몇 가지 빈틈을 찾아냈다. 그러고는 메모리 스토어를 갱신해, 스킬이 있더라도 이번에 배운 사실로 스킬에 담긴 지식을 보충하라고 적어 두었다. 지금 드리밍은 메모리 스토어에만 적용된다. 하지만 Gabe는 앞으로 드리밍이 스킬과 에이전트 프롬프트, 서브에이전트 프롬프트, 에이전트 정의까지 직접 개선하도록 기능을 넓히면 에이전트가 계속 학습하게 할 수 있으리라고 말한다.
드리밍이 실제 결과를 얼마나 바꾸는지는 평가로 확인한다. 드리밍은 여러 방향으로 갈라질 수 있는데 평가와 자동으로 연결해 더 나은 방향을 고르는 기능이 있느냐는 질문에, 발표자들은 드리밍의 동작부터 설명한다. 드리밍할 기간을 정하면 드리밍은 그 기간의 기록을 모두 보고 사용자가 하려던 작업을 분석해, 그 작업에 더 맞춘 새 메모리 스토어를 만든다. Anthropic은 드리밍이 더 나은 결과를 내는지 자체 평가로 확인하며, 드리밍으로 만든 새 메모리 스토어를 써서 평가 점수가 크게 오른 고객도 있었다. 그래도 발표자들은 결국 모든 판단의 기준은 평가라며 자체 평가 세트를 갖추라고 권한다. 드리밍은 아직 초기 단계의 실험적인 연구 프리뷰이고, 대체로 성능이 올랐지만 그냥 믿으라고 말할 수는 없다는 것이다. 질문한 청중은 아홉 세션은 어떤 방식이 틀렸다고 하고 한 세션만 옳다고 하는 경우처럼, 평가 없이 드리밍에만 기대면 놓치는 통찰이 있을 수 있다고 우려한다.
모델이 똑똑해질수록 사람이 정한 제약은 걷어 내고 평가로 판단해야 한다
에이전트 A가 B와 C에게 일을 넘기는 식으로 오케스트레이션 구조를 정의할 수 있느냐는 질문에, 발표자들은 지금은 서브에이전트를 두고 Claude에게 원하는 바를 말하면 된다고 답한다. 발표자들이 보기에 사람에게는 Claude가 하는 일과 그 방식을 제한하고 싶은 욕구가 있다. 그러나 Anthropic은 Claude가 똑똑해질수록 그런 가드레일을 계속 걷어 내고, Claude가 최선이라고 판단하는 방식대로 일하게 두었다. 사람이 서브에이전트 세 개가 최선의 구조라고 생각하더라도, Claude에게 구조를 정하게 하면 실제로는 Claude가 정한 구조가 더 나은 성능을 낸다는 것이다. 그래프 형태의 워크플로를 UI에서 짜는 기능은 아직 없다.
스킬과 멀티 에이전트 중 무엇을 골라야 하느냐는 질문에도 같은 관점이 이어진다. 질문한 청중은 새 모델이 나올 때마다 새로운 하네스와 도구에 투자하는 일에 지쳤다고 털어놓는다. 답한 발표자는 하네스를 두껍게 할지 얇게 할지, 스킬을 두껍게 할지는 계속 바뀌는 문제라고 말한다. Claude가 똑똑해질수록 사람이 정해 주던 경계와 도움은 점점 사라지므로, 오늘 필요한 것이 내일은 필요 없을 수 있다. 재미없는 답이지만 평가를 돌려 보라는 것이 결론이다. 지금은 스킬이 모델에 필요한 정보를 주는 좋은 추상화이지만, 이 발표자는 스킬도 점점 얇아져 결국 모델이 특별한 지시 없이 스스로 해내게 되리라고 예상한다. 그리고 작업에 따라 다르겠지만 자기 생각으로는 멀티 에이전트가 더 쓸모 있어 보인다고 덧붙인다.
에이전트끼리 루프에 빠져 토큰을 과도하게 쓰지 않게 하는 장치가 있느냐는 질문에, 발표자들은 그 부분은 개발자가 오케스트레이션하면서 정할 몫으로 남겨 둔다고 답한다. Anthropic은 세션당 비용이나 토큰 사용량에 상한을 거는 예산 통제를 검토하고 있지만 아직 제공하지는 않는다.
평가를 어떻게 만들지에 대한 조언은 4부에서 나온다. 발표자들이 가장 강조하는 것은 평가에 쓸 데이터의 품질이다. Claude Code는 평가를 꽤 잘 만들어 주지만, 나쁜 데이터를 넣으면 나쁜 결과가 나온다. Anthropic도 처음 세운 평가 방식 가운데 일부는 정의가 엉성해서, 100%가 나와도 그 점수가 실제 성능에서 무엇을 뜻하는지 알 수 없었다. 그래서 데이터를 반복해서 다듬고 문제를 올바르게 설정하는 일이 중요하다. 다른 발표자는 과거 세션과 그 결과를 살펴보고 점수를 매겨 보는 것이 데이터 세트를 만드는 좋은 방법이라고 덧붙인다.
멀티테넌시는 워크스페이스를 기본 단위로 설계한다
복잡한 조직에서 여러 에이전트를 분리하고 권한을 나누는 방법을 묻자, 발표자들은 지금 제공하는 기본 단위는 워크스페이스라고 답한다. 고객을 서로 다른 워크스페이스에 두고, 특정 사용자에게 특정 워크스페이스에 접근할 권한을 주는 방식이다. 워크스페이스 안에 있는 모든 것에는 그 워크스페이스에 속한 모든 사람이 접근할 수 있으므로, 발표자들은 더 세밀한 RBAC가 부족하다는 점을 인정하고 로드맵에 올려 두었다고 말한다.
리소스는 계정이 아니라 워크스페이스에 묶이며, 워크스페이스 안의 API 키는 모두 그 리소스에 접근할 수 있다. 조직의 Claude Platform 관리자가 워크스페이스를 만들고 누가 어디에 접근할지 정하므로, 접근 통제 요구에 맞춰 워크스페이스를 설계하면 된다. 메모리는 이 사람과, MCP 연결은 저 사람과 나누는 식의 부분 공유를 플랫폼이 세밀하게 지원하지는 않는다. 다만 그 위에 통합을 만드는 개발자는 최종 사용자가 무엇을 공유받을지 꽤 세밀하게 제어할 수 있다.
SaaS처럼 고객이 여러 테넌트로 나뉘는 경우에 대해 Gabe는 최종 사용자의 API 키를 받아 쓰는 방식(bring your own key)은 좋은 멀티테넌시 모델이 아니라고 말한다. 에이전트가 개발자의 키가 아니라 최종 사용자의 키로 돌아가서 개발자가 관측성을 잃기 때문이다. 대신 워크스페이스를 테넌시의 기본 단위로 삼으라고 권한다. Priyanka는 두 가지 방식을 비교한다. 모든 고객의 데이터를 워크스페이스 하나에 두고 어떤 에이전트가 어떤 고객에 대응하는지 개발자 쪽에서 매핑할 수도 있고, 고객마다 워크스페이스를 만들 수도 있다. 후자는 워크스페이스마다 에이전트를 다시 만들어야 해서 더 복잡해진다.
4부에서 발표자들은 격리 수준에 따른 선택지를 더 제시한다. 고객마다 에이전트를 따로 정의하면 데이터가 분리되고, 고객마다 워크스페이스를 둘 수도 있으며, 완전한 격리가 필요하다면 고객마다 조직(org)을 둘 수도 있다. 다른 고객과 데이터를 공유하면 안 된다는 법적 요구가 있다면 고객별로 워크스페이스를 나누어야 하며, 리소스도 워크스페이스 단위로 할당된다. 에이전트를 한 번만 만들어 여러 고객이 함께 쓰게 하고 싶다면, 에이전트 정의를 YAML로 코드에 두고 CI에서 여러 워크스페이스의 정의를 한꺼번에 갱신하는 도구를 쓸 수 있다. 에이전트는 시스템 프롬프트와 모델 이름, 도구를 묶은 템플릿이므로 워크스페이스마다 복사해 두면 된다. 모든 고객을 워크스페이스 하나에 둔다면 에이전트 하나를 함께 쓰고, 세션의 메타데이터 필드에 고객 ID를 넣어 어떤 세션이 어느 고객에 속하는지 관리한다.
Managed Agents는 Claude Code에서 영감을 받았지만 제품을 만드는 기반이 되는 범용 API다
Agent SDK와 무엇이 다르냐는 질문에 발표자들은 Agent SDK가 Claude Code를 헤드리스로 묶은 것이라고 설명한다. Agent SDK는 바이너리 형태의 Claude Code라서 원하는 곳 어디서나 실행할 수 있다. Managed Agents는 Agent SDK에서 얻은 이점과 교훈을 반영하면서도 하네스를 코딩 전용이 아닌 범용으로 다시 만든 제품이고, Anthropic 클라우드에서 완전히 호스팅된다. 이 하네스는 Claude Code의 하네스에서 많은 영감을 받았으며, Managed Agents 팀은 개선 사항을 두고 Claude Code 쪽과 자주 소통한다.
1년 넘게 Claude Code로 비슷한 일을 해 왔다는 한 청중은 Managed Agents가 Claude Code 위에 그대로 만든 것이냐고 물으며, 지금처럼 개방적인 구조를 유지해 달라고 당부한다. 발표자들은 Claude Code 하네스를 참고했다고 인정하면서도 차이를 설명한다. Claude Code 하네스는 코딩 작업에 잘 맞춰져 있고 다른 작업에서는 그만큼 유연하지 않다. Claude Code가 바로 쓸 수 있는 제품을 주려 한다면, Managed Agents는 개발자가 자기 컨텍스트와 정보, 능력을 가져와 그 위에 무언가를 만들게 하는 API다. Priyanka는 Claude Code가 터미널 도구인 반면 Managed Agents는 확장 가능하고 신뢰할 수 있는 API 제품이자 인프라여야 하므로, 워크숍 첫머리에서 설명한 운영 문제를 해결하는 데 공을 들였다고 덧붙인다.
Claude Cowork와의 차이는 Priyanka가 설명한다. Cowork는 개인용 에이전트를 만드는 도구이고, Managed Agents는 팀이나 조직 안에서 쓰거나 최종 고객에게 내놓을 에이전트를 만드는 도구다. 개인용 에이전트라면 Cowork가 여전히 좋은 선택이다. 엔지니어가 아닌 사람에게 API 제품은 부담스러울 수 있지만, 콘솔에 있는 빠른 시작 기능에서는 만들고 싶은 에이전트를 Claude에게 말하기만 하면 된다. Claude Code에 익숙하다면 자연어로 첫 에이전트를 만들도록 안내하는 Managed Agents 스킬도 있다. Cowork에서 만든 것을 Managed Agents로 옮기고 싶다면, Cowork에서 한 작업과 API를 호출하는 스킬을 함께 Claude에게 주고 변환을 맡기면 된다고 발표자들은 말한다.
이용 조건에 관한 질문도 이어진다. Managed Agents는 Bedrock에서는 쓸 수 없지만 AWS용 Claude Platform에서는 쓸 수 있고, 거기에도 콘솔이 있다. Anthropic이 아닌 회사의 모델은 쓸 수 없고 Claude 모델만 지원한다. 콘솔 가입은 무료이며, API 키를 만들어 토큰 사용량만큼 비용을 낸다. 막 출시된 새 모델(자막 표기 sunet five)도 Managed Agents에서 바로 쓸 수 있다. 민감한 데이터 때문에 사내에서 직접 운영하고 싶어 하는 기업의 온프레미스 요구에 대해 발표자들은 많은 기업 고객이 요청해서 진지하게 검토하고 있지만 지금 공유할 내용은 없다고 답한다.
실제 제품은 개발자가 자기 UI를 만들고 Managed Agents API를 호출해 완성한다
고객에게 대규모로 배포하는 방법을 묻는 청중에게 발표자들은 Managed Agents가 이미 프로덕션에서 대규모로 쓰이고 있다고 답한다. Notion의 외부 에이전트가 Managed Agents 위에 만들어졌고, Atlassian의 Jira 통합도 이를 활용한다. 보통은 개발자가 고객에게 배포할 제품과 UI를 만들고, 실제 에이전트 실행과 상태 관리는 Anthropic API를 호출해 처리한다.
Slack 같은 채팅 채널에서 여러 사람이 함께 쓰는 Claude Tag 같은 에이전트도 만들 수 있다. 스레드마다 세션을 하나씩 대응시키고, 사용자가 메시지를 보낼 때마다 보낸 사람이 누구인지 함께 담아 user.message 이벤트로 세션에 넣으면 된다. 세션 사이에 메모리를 공유해 서로 배우게 하고, Slack에 글을 올리는 도구를 주어 에이전트가 언제 글을 올릴지 스스로 정하게 한다. 발표자들은 에이전트의 응답을 그대로 채널에 옮기기보다 명시적으로 올리게 하는 편이 낫다고 말한다. Claude Tag처럼 만들려면 Slack 채널마다 에이전트를 하나씩 두고, 각 에이전트가 별도 메모리를 가지며 자기 채널의 메시지에만 접근하게 하면 된다.
에이전트가 쓴 코드를 검토하는 문제도 Managed Agents로 풀 수 있다. 에이전트로 코드를 대량으로 만들다 보니 리뷰가 병목이 되는데 어떻게 하느냐는 질문에, 발표자들은 원래 이 워크숍에서 다루려던 주제가 바로 그것이었다고 말한다. PR이 올라오면 여러 세션과 서브에이전트를 실행해 변경 사항을 평가하고 버그를 찾는 통합을 만들 수 있다. Anthropic 내부에서도 이런 에이전트 덕분에 PR마다 들이는 시간과 버그 수가 줄고 품질이 높게 유지된다. 그래도 타이핑이라는 제약이 사라져 하루, 한 시간, 1초 동안 만들 수 있는 PR 수가 폭발적으로 늘어난 상황에서 리뷰가 그 속도를 어떻게 따라갈지는 아직 풀리지 않은 문제이며, 발표자들은 Managed Agents가 그 답의 일부라고 본다.
리뷰를 반복하더라도 결국 실제로 실행해 확인하는 단계가 필요하다. 발표자들은 샌드박스 안에서 애플리케이션을 돌리고, Claude가 QA 에이전트처럼 자기가 만든 변경 사항을 스스로 검증하게 할 수 있다고 말한다. 지금은 사람이 샌드박스에서 돌아가는 애플리케이션 화면에 직접 들어가 볼 수 있는 터널 기능이 없으므로, Claude가 브라우저로 직접 써 보며 검증하고 영상을 돌려줄 수도 있다는 것이다.