AI 에이전트 하나로는 부족하다: 1,000개를 운영하는 법

URL: https://www.youtube.com/watch?v=kiClTcJUnhc
날짜: 2026-10-17
채널: AI Engineer (@aiDotEngineer)
원제: Why One AI Agent Isn’t Enough (And How to Run 1,000)
발표자: CJ Avilla, Harrison Stall (Anthropic)
영상 발행일: 2026-10-16 · 재생 시간: 1시간 41분 43초

📌 핵심 질문 / 핵심 논점

==한 명의 에이전트가 모든 일을 머릿속에 붙잡고 끝까지 수행하는 방식은 규모가 커지는 순간 병목이 된다. 일을 독립적인 맥락과 검증 단계로 나누고, 리드 에이전트가 동적으로 위임하는 Flows가 대규모 자동화의 실행 모델이다.==

• 단일 에이전트는 작업량이 늘수록 누락·자기평가 편향·목표 이탈에 취약해진다.
• Flows는 작업을 계획, 병렬 조사, 격리된 검토·검증 단계로 분해하고 개별 에이전트를 그 단위에 배치한다.
• 에이전트 수를 늘리는 것만으로는 충분하지 않으며, 예산·권한·샌드박스·자격 증명·감사 로그를 함께 설계해야 한다.

프로젝트 전체의 일관성을 한 사람이 유지하는 방식은 작은 팀과 분명한 경계가 있는 일에 강하다. 복잡한 작업에서는 신뢰받는 유지관리자에게 변경을 모아 올리는 리눅스식 계층 구조가 확장성을 만든다. Flows는 이 조직 원리를 에이전트에 적용해, 한 리드가 계획을 세우고 필요한 수의 하위 에이전트를 각 단계에 투입하며, 각 스레드의 기록을 추적·중단·재개할 수 있게 한다. 비용은 더 들 수 있지만 누락을 줄이고 깊이를 높인다. 대규모 병렬 작업일수록 맥락 분리, 독립 검토, 최소 권한, 비밀정보 분리, 내구성 있는 이벤트 기록이 함께 필요하다.

1. 조직 규모와 소프트웨어 개발의 역사

1.1. 개념적 일관성을 유지한 소규모 개발

1. 켄 톰프슨의 한 달과 유닉스

   1. 1969년, 벨 연구소에서 켄 톰프슨은 아내와 한 살 아들이 한 달 동안 캘리포니아에 간 사이 집중할 시간을 얻었다.
   2. 커널·에디터·어셈블러 등을 각각 일주일 단위로 나눠 만들겠다고 계획했고, 한 달이 끝날 무렵 유닉스를 만들었다.
   3. 전체 프로젝트를 한 사람이 머릿속에 담아 처음부터 끝까지 실행하는 성질을 **개념적 일관성(conceptual integrity)**이라 부른다. 작은 규모에서는 이 방식이 빠르고 응집력 있는 결과를 낳는다.

2. OS/360과 브룩스의 외과 수술팀 비유

   1. IBM의 OS/360은 하드웨어를 업그레이드할 때마다 관련 소프트웨어를 새로 써야 했던 문제를 해결하려는 대규모 운영체제 프로젝트였다.
   2. 초기에 대략 **5,000 인년(person-years)**의 일이 필요하다고 추산하고 약 1,000명의 엔지니어를 투입해 짧은 기간에 완수하려 했다.
   3. 프로젝트 관리자 프레드 브룩스는 경험을 《맨먼스 미신(The Mythical Man-Month)》에 정리했다. 효과적인 한 형태는 수술팀처럼 한 명의 책임자 주위에 약 10명의 전문 인력을 두는 구조다.
   4. 각자는 언어 전문가, 보조자, 부조종사 등 전문 역할을 맡지만, 최종 책임자가 전체 설계와 판단의 일관성을 유지한다. 이런 소규모 집중팀은 기적 같은 결과를 낼 수 있지만, 같은 구조를 그대로 거대 규모로 늘리기는 어렵다.

1.2. 리눅스가 별형에서 신뢰 네트워크로 바뀐 과정

1. 리누스 토르발스의 패치 병목

   1. 발표 당시 사례로 든 Linux 7.2는 9주 동안 개발됐고, 300개 회사의 약 2,600명 개발자가 기여했다.
   2. 1998년 무렵 커널 메일링 리스트에서 리누스는 패치를 보냈는데도 반영되지 않았다고 재촉하는 메일을 계속 받았고, 결국 “휴가를 갈 테니 받은 편지함에서 나를 내버려 두라”는 취지로 한계에 이르렀다.
   3. 패치가 모두 한 사람에게 직접 몰리는 별형(star) 구조에서는 최종 검토자가 병목이 된다. 수많은 에이전트의 PR을 한 사람이 승인하는 상황도 같은 병목을 재현한다.

2. 유지관리자 계층이 만든 확장성

   1. 다음 날 래리 맥보이는 “문제는 리누스가 확장되지 않는다는 것”이라고 지적하며 버전 관리 도구를 제안했다.
   2. 약 2002년 무렵 리누스도 직접 모두 받는 방식의 한계를 받아들이고, 신뢰할 수 있는 유지관리자가 각자 변경을 검토한 뒤 예외적인 사안만 위로 올리는 네트워크형 구조로 이동했다.
   3. 최종적으로 리누스가 메인 브랜치에 반영하는 권한은 유지하되, 각 단계에서 직접 보고하는 사람 수를 줄였다. 발표 자료의 비교에서는 별형이 약 36명의 기여자를 한 중심점에 모으는 반면, 계층형 구조는 각 층에서 많아야 4명 안팎만 다음 단계에 변경을 보고한다.
   4. 목표는 책임자의 판단력을 없애는 것이 아니라, 그 판단이 꼭 필요한 변경만 위로 올라오도록 신뢰와 검토의 층을 만드는 것이다.

2. Claude Managed Agents와 Flows의 실행 모델

2.1. 왜 단일 에이전트와 기존 오케스트레이션이 막히는가

1. 사람이 직접 만든 멀티 에이전트 하네스의 운영 부담

   1. 사용자는 이미 매우 복잡한 오케스트레이션을 직접 구축하고 있다. 에이전트가 100개 중 하나라도 두 시간 뒤 종료되면 컨테이너 재시작, 중단 지점 복원, 전체 토폴로지 상태 파악을 처리해야 한다.
   2. 한 명의 조정 에이전트가 예컨대 60개 하위 에이전트의 진행을 계속 기억하는 것도 규모의 한계다. 그래프의 각 노드를 일일이 조회할지, 모든 정보를 조정자에게 통과시킬지도 별도 설계 부담이다.
   3. 장시간 실행을 유지하려고 노트북을 살짝 열어 두거나 공원에서 화면을 보며 “승인, 승인”을 누르는 식의 운용은 사회적 규모의 과제를 처리할 기반이 되지 못한다.

2. Claude Managed Agents의 기본 단위

   1. Claude Managed Agents는 에이전트 수명주기를 API가 관리하는 제품 표면이다. 에이전트 리소스에는 스킬·도구·MCP 서버 등을 정의하고, 세션은 실제 일을 맡기는 요청에 해당한다.
   2. 상태가 있는 API 리소스와 내구성 있는 이벤트 로그로 실행 과정을 실시간 관찰할 수 있다.
   3. 5월에 소개한 첫 멀티 에이전트 방식에서는 주 에이전트가 사용할 하위 에이전트를 미리 정의하고, 각 에이전트의 스레드와 메시지를 직접 다뤄야 했다. 운영체제 프로세스와 스레드처럼 맥락은 분리되지만, 상태 공유에는 스레드 사이 메시지 관리가 필요했다.

3. Flows가 담당하는 동적 계획과 위임

   1. 리드 에이전트가 먼저 “백만 줄짜리 Python 모노레포를 Rust로 옮긴다” 같은 목표를 받고 계획을 세운다.
   2. 계획의 각 단계에서 필요한 에이전트를 스스로 만들고 줄인다. 예를 들어 첫 단계는 파일을 읽는 여러 탐색 에이전트, 다음 단계는 조사 결과를 분류하는 에이전트, 그 다음은 결과를 검토·작성하는 에이전트가 될 수 있다.
   3. 작업은 분리되고 검증 가능한 단위로 진행된다. 사용자가 에이전트 간 연결 그래프를 일일이 설계하지 않아도 모델이 목표에 맞춰 위임과 단계를 조직한다.
   4. 동적 워크플로는 Claude Code에서 인기를 얻은 자기 오케스트레이션 방식과 같은 계열이며, 내부적으로 JavaScript 엔진을 사용해 map-reduce, ask 등의 활동을 엮는다. Claude Code에서 터미널 대화로 쓰던 패턴을 제품/API에 통합하는 것이 Managed Agents Flows다.

2.2. 실행 감시, 비용 통제, 중단과 재개

1. 이벤트 스트림과 세션 가시성

   1. 실행 전체를 하나의 내구성 있는 이벤트 스트림으로 볼 수 있고, 각 스레드에서 발생하는 도구 호출·결과·메시지 전달과 수신을 실시간으로 확인할 수 있다.
   2. 콘솔에서는 토폴로지와 각 에이전트의 상태를 보고, 개별 하위 에이전트와 리드 사이에서 어떤 페이로드가 오갔는지 살펴볼 수 있다.
   3. 같은 공개 API를 활용해 직접 UI를 만들 수도 있다. 채팅 화면, 에이전트 그래프, 도구 호출 상세, 차트 같은 생성형 UI까지 구성할 수 있다.

2. 예산·중단·재개

   1. 세션 시작 전에 토큰/비용 예산을 제한해 과도한 실행을 막을 수 있다. 모델은 예산을 의식하며 행동하도록 설계된 것이 아니라, 예산은 일차적으로 지출 가드레일이다.
   2. 예산에 도달하면 budget reached 이벤트가 발생한다. 예산을 늘리면 이미 수행한 일을 버리지 않고 이어갈 수 있다. 예시로 5달러 도달 시 멈추고 검토한 뒤 추가 비용을 허용하는 흐름을 들었다.
   3. API로 실행 도중 사용자 인터럽트를 보내 방향을 바꾸거나 중지할 수 있다. 실행 결과가 잘못된 방향이라면 즉시 중단해 지출과 위험을 제한한다.
   4. 예산을 모델에게 직접 알려주면 최신 모델이 불안해하며 작업을 위축시킬 수 있어, 모델 자율성보다 외부 가드레일로 쓰는 편이 낫다는 설명이다.

3. 지원하는 통합 지점

   1. 콘솔에서 템플릿을 골라 실험한 다음, 준비가 되면 자신의 애플리케이션·내부 프로세스·CI에 API를 통합한다.
   2. 시장 개장 직전 매일 실행하는 주식 분석, Slack 입력이나 GitHub 웹훅으로 시작하는 버그 탐지처럼 일정·웹훅 기반 반복 작업이 대표 사례다.
   3. Claude Code를 대화형으로 직접 쓰는 것과 달리, Managed Agents는 스케줄이나 제품 이벤트를 통해 반복 실행할 API를 제공한다. 모델의 일회성 상호작용을 제품 기능으로 확장하는 차이다.

3. 데모와 실제 워크플로 구성

3.1. 주식 관심 목록 스캐너

1. 콘솔에서 템플릿을 실행

   1. Cloud Console의 Manage Agents 화면에는 빠른 시작 템플릿과 Dynamic Workflow가 있다. 금융 분야 참석자를 위해 주식 관심 목록 스캐너 템플릿을 골랐다.
   2. 화면 설정은 multi-agent-2026-10-01 유형과 에이전트의 역할을 정하는 시스템 프롬프트를 사용한다. 세션을 시작하려면 먼저 Claude가 작업할 컴퓨터 역할의 환경(environment)을 만들거나 기존 환경을 선택한다.
   3. 데모 관심 종목은 Apple, Nvidia, Amazon, JPM, XOM, COST였다. 세션 목록에서 리드 에이전트, 실행 환경, 실시간 처리 상태를 확인했고, 다른 완료된 실행에서는 단계별 결과를 살펴봤다.
   4. 복잡도에 따라 각 단계에서 동시에 실행되는 에이전트 수를 조절할 수 있다. 시연한 이전 실행은 각 단계에 대략 6개의 동시 에이전트를 사용했다.

2. 티커별 분할과 독립 검토

   1. 단일 에이전트에 전체 티커를 던지면 각각을 충분히 조사하기 어렵다. Flows는 목록을 나눠 티커마다 스캔 에이전트를 배정한다.
   2. 스캔 에이전트는 자기 티커 하나만 보는 독립 맥락에서 조사한다. 다른 티커나 그 검색 결과에 영향을 받지 않는다.
   3. 스캔 이후 검토 단계는 다시 별도 맥락에서 결과를 평가하고, 필요한 경우 스캔 결과를 보고서 작성에 넘긴다.
   4. 개별 티커별 깊이와 완전성을 높이는 대신 단일 에이전트 실행보다 비용이 커질 수 있다. 충분한 결과가 중요한 작업에 비용을 투입하는 구조다.

3. 단계별 모델·컴퓨트 배분과 평가

   1. 인터넷을 폭넓게 훑는 저렴한 스캔 단계에는 Haiku를 쓰고, 티커마다 2개의 Haiku 에이전트를 붙일 수 있다.
   2. 결과를 읽고 중요한 세부사항을 놓치지 않는 검토 단계에는 더 많은 컴퓨트와 Fable을 배정하고 티커별 2~3개의 검토 에이전트를 둘 수 있다.
   3. 한 흐름 안에서 단계별로 모델·병렬도·투자량을 늘리거나 줄이며 비용과 품질을 맞춘다.
   4. 중요 업무라면 대표 입력을 모은 평가 세트(eval set)로 원하는 동작을 검증하는 것이 좋다. 주식 스캐너 사례에서는 스캔 단계보다 검토 단계에 더 많이 투자할 때 세부 발견력이 높아졌다.

3.2. API 구성, 사전 설정, 샌드박스

1. 최소 호출 구성

   1. 에이전트를 만들 때 멀티 에이전트 설정을 켠 뒤, 첫 이벤트를 리드 에이전트에 보내 “워크플로를 실행하라”고 요청하면 Flows가 시작된다.
   2. 가장 간단한 방식은 특정 하위 에이전트를 미리 지정하지 않고 모델이 작업 중 필요한 구성을 만들도록 두는 것이다.
   3. 더 전문화된 역할이 필요하면 Yahoo Finance, 뉴스 소스, SEC EDGAR 조사 등 특정 작업을 잘 아는 에이전트를 사전 구성할 수 있다.

2. 리소스 확장과 환경 선택

   1. 커스텀 스킬, MCP 서버, 환경 안에서 실행되는 도구를 에이전트에 연결할 수 있다.
   2. Anthropic이 관리하는 환경 대신 자체 인프라에서 샌드박스를 운영하는 것도 가능하며, Flows는 자체 호스팅 환경에서도 지원된다. 다만 Managed Agents의 일부 기능은 자체 호스팅 환경에서 완전히 지원되지 않을 수 있다.
   3. 로컬 Mac이나 다른 외부 컴퓨터에서 작업해야 한다면 커스텀 도구로 모델이 요청을 보내게 하고, 애플리케이션이 해당 컴퓨터에서 작업한 뒤 결과를 모델에 반환한다.

3. 프롬프트 작성과 반복 개선

   1. 시작부터 모든 에이전트와 단계를 세세하게 지정하기보다, 목표·관심사·제약을 알려 주고 모델이 처음 흐름을 설계하게 한 뒤 결과를 보며 다듬는 편이 효과적이었다.
   2. 템플릿은 콘솔뿐 아니라 Claude Code용 Claude API 스킬에서도 제공된다. Claude API 스킬의 Ant CLI 명령을 사용하면 Claude Code가 API에 에이전트·세션 등 리소스를 만들고 관리할 수 있다.
   3. Claude Code는 로컬 또는 클라우드에 설정된 실행 환경에서 별도로 동작하고, 그 환경에서 Managed Agents API를 호출한다. Claude Code 자체와 Managed Agents 세션은 구분되는 시스템이다.
   4. Max 구독과 Team 구독에는 API 크레딧이 연결되는 선택지가 소개됐다. 행사 참석자용 50달러 실험 크레딧 QR도 제공했고, 발표 당시에는 Max 5X에 월 100달러, Team에 최대 월 500달러 수준의 크레딧을 언급했다.

4. 사용 사례와 협업 방식

4.1. Bug Hunter: PR 검토를 다단계로 분해

1. 코드 변경을 독립 조각으로 검토

   1. PR의 변경 코드를 여러 조각(slice)으로 나누고, 각 조각을 독립된 맥락의 검토 에이전트에 맡긴다.
   2. 첫 검토자는 성능 문제·회귀·실제 오류 가능성을 후보로 기록한다. 다음 검토 단계에서는 후보마다 동의하는지, 근거가 약한지를 별도로 판별한다.
   3. 통합 단계가 실제 문제일 가능성이 큰 후보만 남기고, 검증 단계(prover)가 저장소를 내려받아 버그를 재현하거나 영향 여부를 확인한다.

2. 사람의 코드베이스 맥락을 보완

   1. 사람은 PR에 포함되지 않은 코드의 다른 부분까지 알고 있어 “이 변경이 먼 곳의 동작을 깨뜨릴 것”이라는 가설을 세울 수 있다. Bug Hunter는 후보를 제시해 인간 검토자가 이런 검증을 더 빠르게 하게 돕는다.
   2. 결과를 보고서로 내거나 PR 인라인 코멘트로 올리고 심각도·우선순위를 표시할 수 있다.
   3. 하네스는 PR마다 저장소를 컨테이너에 다시 마운트한다. 이는 CI 작업마다 Git 저장소를 체크아웃하는 것과 같다.
   4. 여러 저장소의 의존관계가 중요하면 Bazel처럼 정돈된 빌드 구성을 사용하거나, 오래 걸리는 의존성 그래프를 미리 만들어 파일로 세션에 넣어 두면 흐름을 최적화할 수 있다.

4.2. Explainer Studio: 연구에서 영상 제작까지

1. 여러 작업 단계를 연결하는 제작 흐름

   1. 동적 워크플로가 제품 설명을 조사하고, 계획·탐색·팩트체크를 거쳐 브리프를 만든다.
   2. 브리프를 제작 단계에 넘기면 장면별로 만들고 애니메이션화한다. 별도 단계에서 음향 효과·보이스오버·대본 등을 구성해 최종 영상을 만든다.
   3. 이 흐름으로 Cloud Devs가 게시하는 제품·기능 애니메이션 중 다수를 제작한다. 수년 전 약 20시간 걸렸을 애니메이션 작업을 작은 프롬프트 하나에서 시작할 수 있게 된 사례다.

2. 브랜드 적용과 출력 범위

   1. 영상은 Anthropic 브랜드 색상과 서체까지 적용할 수 있다. Claude Design에서 디자인 시스템을 만들고 이를 Flows에 전달해 자체 브랜드 규칙을 따르게 할 수 있다.
   2. 데모 영상이 YouTube에 자동 게시되지는 않는다. 청중이 게시 방법을 묻자 아직 지원되지 않지만 지원하면 좋겠다는 반응이 나왔다.
   3. 행사장에서 “자전거가 어떻게 만들어지는지”와 “변기가 어떻게 작동하는지” 중 볼 주제를 묻자 변기 작동 설명이 근소하게 선택됐다. Claude 로고와 Anthropic 서체가 영상에 자동으로 반영된 점도 웃음과 함께 언급됐다.
   4. 같은 제작 흐름은 연구 설명, 제품 소개, 온라인 영상 등 반복적인 콘텐츠 생성에도 활용할 수 있다.

4.3. 다른 통합 및 공유 패턴

1. 제품 기능·자동화에 임베드

   1. 고객에게 에이전트를 그대로 노출하기보다 자체 웹사이트나 앱 뒤에 API를 붙여 제품 기능으로 제공하는 패턴이 일반적이다.
   2. 예를 들어 프로젝트 관리 앱에서 칸반 카드를 옮길 때 백그라운드에서 세션이나 Flows를 실행하도록 만들 수 있다.
   3. GitHub 웹훅, Slack 입력, 예약 실행은 대화형 터미널 밖에서 반복 작업을 시작하는 트리거가 된다.

2. 리소스 공유와 플러그인

   1. Terraform Provider로 에이전트를 만들 수 있고 콘솔에서 API 리소스를 내보내 다른 곳에 올릴 수도 있다.
   2. 다른 사용자에게 에이전트를 공유하는 단일 클릭 기능은 당시 없었다. 리소스 본문을 다른 곳으로 옮기는 방식으로 공유를 구현한다.
   3. 플러그인의 구성 요소인 스킬과 도구는 API 리소스에 이미 붙일 수 있다. 반대로 만든 워크플로를 플러그인으로 포장하는 기능은 없으며, 실행에서 만들어진 프롬프트를 텍스트로 가져와 Claude Code 등에 넣는 우회 방법이 있다.
   4. 마크다운 파일로 간단한 지시를 전달하는 일회성 작업은 가능하지만, 복잡한 API 리소스가 필요 없는 단순 작업에는 Managed Agents가 과한 추상화일 수 있다.

5. 단일 에이전트의 세 가지 실패 양상

5.1. 에이전트의 태만(agentic laziness)

1. 검사 대상이 많을 때 조기 종료

   1. 50개 서비스를 확인해 장애 원인을 찾으라고 했는데 처음 35개가 정상이라면, 단일 에이전트는 나머지도 괜찮을 것이라고 스스로 결론 내리고 확인을 중단할 수 있다.
   2. 여러 하위 에이전트를 두더라도 각자 일부 항목만 살핀 뒤 조정자에게 돌아오거나, 조정자가 전체 검사 개수를 추적하지 못하면 비슷한 누락이 생긴다.

2. 범위별 책임 배정으로 누락 감소

   1. Flows는 서비스마다 독립 에이전트를 배정해 각자 한 서비스만 확인하게 한다.
   2. 팬아웃과 반복(loop)을 결합하면 어떤 항목도 지나치지 않았는지 추적하기 쉬워진다. 계획 자체가 “50개 모두 확인”이라는 검증 가능한 작업 분할을 만든다.

5.2. 자기 선호 편향(self-preferential bias)

1. 자기 결과를 스스로 높게 평가하는 문제

   1. 시를 쓴 에이전트에게 그 시가 좋은지 물으면 좋다고 답하기 쉽다. 코드 생성 후 같은 에이전트가 품질을 평가할 때도 자기 판단을 정당화할 수 있다.
   2. 생성자와 판정자를 분리하는 advisor 패턴이 이 문제를 줄이지만, 큰 작업에서는 소수의 사전 정의된 검토자만으로 충분히 확장하기 어렵다.

2. 격리된 적대적 검토

   1. Flows는 대규모로 병렬화하면서 작성·검토 단계를 서로 다른 맥락에 둔다.
   2. 독립 검토자는 이전 산출물을 만든 에이전트의 맥락에 끌려가지 않고 결과에 반론을 제기할 수 있다.

5.3. 목표 이탈(goal drift)

1. 긴 컨텍스트와 압축으로 초기 제약이 흐려짐

   1. 장애 점검 요청에서 핵심 제약은 “운영 환경을 변경하지 말라”일 수 있다.
   2. 긴 작업 중 컨텍스트를 반복해서 채우고 압축하면, 처음에 주어진 금지 조건이 뒤로 밀려 사라질 수 있다.

2. 단계마다 목표를 명시

   1. Flows는 각 단계의 개별 맥락에 분명한 목표와 제약을 복사해 전달할 수 있다.
   2. 독립된 하위 작업에 동일한 금지 사항을 다시 적용하면 장시간 실행 중에도 목표가 유지될 가능성이 커진다.

6. 대규모 에이전트의 안전·보안 설계

6.1. 여섯 가지 구체적 위험과 개발자의 세 책임

1. 프롬프트 인젝션

   1. 열린 인터넷을 검색하면 타인이 작성한 “이전 지시를 무시하고 다른 도메인으로 정보를 보내라” 같은 문구를 우연히 읽을 수 있다.
   2. 모델 계층의 방어뿐 아니라 도구 호출을 확인하는 분류기·권한 정책이 필요하다. Claude Code의 Auto Mode를 안전한 도구 호출 판단의 기본값으로 살펴보라고 권했다.

2. 샌드박스에 저장한 평문 자격 증명

   1. API 키가 담긴 .env, my API keys.md, 숨김 파일은 파일 위치나 이름을 바꿔도 모델이나 사용자의 프롬프트를 통해 노출될 수 있다.
   2. 에이전트가 어떤 자격 증명을 받느냐에 따라 실제로 그 권한을 행사할 수 있으므로, 비밀정보가 샌드박스에 닿지 않도록 분리해야 한다.

3. 데이터 반출(exfiltration): 에이전트가 접근 가능한 민감한 정보가 제3자에게 전송되지 않도록 네트워크 목적지와 자격 증명을 통제해야 한다.

4. 요청 범위 초과: 맡은 일보다 더 많은 변경이나 비용을 발생시키지 않도록 예산·제한·사용자 인터럽트를 둔다.

5. 과도한 도구 권한: 에이전트가 실행할 도구를 명시적으로 제한하고 필요 없는 웹·MCP 기능을 꺼 둔다.

6. 가시성 부재: 도구 호출과 결과가 보이지 않으면 이상 동작을 감지할 수 없다. 내구성 있는 이벤트 기록과 실시간 감시를 구성한다.

7. 개발자의 역할은 “선언·격리·감지”

   1. 선언(declare): 에이전트의 정체성·역할·도구·권한·스킬을 정의한다.
   2. 격리(contain): 실행 환경의 물리적·네트워크 한계를 설정해 최악의 경우에도 피해 범위를 줄인다. 허용 도메인, 웹 검색과 웹 가져오기의 허용 여부 등을 환경 정책으로 구성한다.
   3. 감지(detect): 내구성 이벤트 스트림으로 실행을 관찰하고, 원하지 않는 방향이면 즉시 세션을 중단한다.

6.2. 추론하는 두뇌와 행동하는 손의 분리

1. Brain과 hands의 역할

   1. 두뇌(brain)는 추론 루프, 에이전트 하네스, 세션 상태를 담당한다.
   2. 손(hands)은 실제 컴퓨터에서 grep을 실행하거나, 로컬 Mac에서 커스텀 도구를 호출하는 등 현실 세계의 행동을 수행한다.
   3. 세션의 추론 상태와 행동 가능한 환경을 분리하면, 프롬프트가 바뀌어도 행동 환경 안의 비밀정보를 직접 읽어내는 경로를 줄일 수 있다.

2. 가짜 자격 증명과 egress 치환

   1. 컨테이너 내부에는 실제 서비스에서 동작하지 않는 가짜/대체 자격 증명 값을 둔다.
   2. 네트워크 요청이 egress proxy를 통과할 때만 해당 값이 진짜 키로 치환된다. 컨테이너 파일이나 에이전트에게 진짜 키를 주지 않는 구조다.
   3. 따라서 도구를 이용해 컨테이너의 대체 값을 읽더라도 외부 서비스 호출에 쓸 진짜 비밀은 얻을 수 없게 하는 것이 목표다.

6.3. 예산·중단·감사·권한 정책

1. Outcome과 예산을 함께 설정

   1. 원하는 결과와 기대 루브릭(outcome)을 정하고 세션 예산을 함께 전달한다.
   2. 1.25달러 예산 예시에서 한도를 넘으면 추가 비용을 허용할지, 그 결과로 세션을 끝낼지 선택할 수 있다.
   3. API 이벤트 user.interrupt로 실행을 중간에 멈춘 뒤 새 지시를 주거나 필요한 행동을 수행한다.

2. 이벤트 로그를 재검토하는 감사 에이전트

   1. 내구성 있는 기록에는 모든 이벤트가 남으므로 API로 전체 트랜스크립트를 가져올 수 있다.
   2. 별도 에이전트에 하루 또는 일주일치 실행 기록을 주고, 이상한 도구 호출·예상 밖의 파일 접근·정책 위반 가능성을 검토하게 할 수 있다.
   3. 실행 중 이벤트를 감시하는 것과 사후에 로그를 분석하는 방식을 함께 쓰면 실시간 대응과 장기 감사가 가능하다.

3. Auto Mode와 도구 최소화

   1. 사람이 반복해서 승인 요청을 받으면 약 **97%**의 도구 호출에 “승인”을 누르는 습관이 생긴다는 연구가 소개됐다.
   2. always ask를 계속 쓰면 사람은 점점 자동 승인하게 된다. auto mode로 전환하면 각 도구 호출이 안전한지 파괴적 행동인지 판단하도록 하며, 기존 통합에서 적용하기 쉬운 저비용 개선책이다.
   3. 에이전트가 인터넷에 접근할 필요가 없다면 웹 검색·웹 가져오기를 기본으로 끈다. MCP는 서버 전체를 신뢰하는 데 그치지 않고 개별 도구 단위로 켜고 끌 수 있다.
   4. 환경 방화벽에서 api.twilio.com만 허용하면 다른 사이트로 나가는 요청은 실제 네트워크 단계에서 실패한다.

6.4. Credential Vault 사례

1. Twilio API 키를 안전하게 전달하는 방식
   1. 위험한 방식은 세션에 .env 파일을 올려 Twilio 키를 평문 환경 변수로 노출하는 것이다.
   2. Credential Vault에 키를 등록하고, 네트워크 요청의 어느 위치에서 인증값을 써야 하는지 설정한다. 예를 들어 Bearer 인증 헤더인지, 요청 본문인지 정한다.
   3. 특정 자격 증명이 허용되는 호스트를 함께 지정한다. Twilio 키는 api.twilio.com 요청에서만 치환되고 임의의 다른 도메인에는 전달되지 않는다.
   4. 세션을 만들 때 Vault를 연결하면 플랫폼이 샌드박스의 대체 값과 egress 시점의 실제 키를 매칭한다.

7. 한계, 개선 루프와 참석자 질의응답

7.1. 규모, 루프, 기억, 자체 개선

1. 최대 1,000 에이전트와 운영체제 실험

   1. 발표 당시 Flows에서 1,000개 에이전트를 쓸 수 있다고 소개했다. 리드가 여러 흐름을 동시에 시작하거나 하나를 마친 뒤 다음 흐름을 시작할 수도 있다.
   2. 발표자는 금요일에 “켄 톰프슨이 일주일에 유닉스를 만들었다. Python 인터프리터가 있는 Unix 호환 운영체제를 만들고, 최대 1,000개 에이전트를 써도 된다”는 요청으로 프로젝트를 시작했다.
   3. GitHub 저장소를 연결했고, 당시 약 85시간 실행됐지만 발표 시점에도 완성되지 않았다. 이미 3~4개의 흐름을 거쳤고 저장소에는 약 1,000개의 커밋이 쌓였다고 했다.

2. 에이전트 수에 따른 수익 체감은 미정

   1. 조직의 직원 수처럼 하위 에이전트가 늘 때 조정 비용이 얼마나 커지는지에 대한 정량적인 답은 아직 없었다.
   2. 같은 100개 에이전트라도 조직화되지 않은 방식보다 단계·격리·게이트가 있는 Flows에 넣을 때 더 나은 결과를 얻는다는 설명이다.
   3. 흐름 예산을 두면 무한 루프나 폭주를 막을 수 있고, 모델은 오작동하는 하위 에이전트를 감지해 정리하는 데도 효과가 있었다는 내부 평가 경험을 언급했다.

3. 조건부 스킵과 적합한 작업 크기

   1. 외부 변화가 없으면 특정 단계를 건너뛰어 비용을 아끼는 범용 플랫폼 기능은 당시 없었다.
   2. 애플리케이션 계층에서 조건을 탐지해 어떤 Flows를 실행할지 결정하거나, 단일 흐름 안에서 조건부 실행을 지시해야 한다.
   3. 30초면 충분한 작업에 Flows를 쓰기보다, 단일 에이전트로 감당하기 어려운 야심찬 복합 과제에 적합하다.

4. Prompt hill climbing과 Dreams

   1. Claude Code의 Claude API hill climb 스킬은 최적화 기준을 정하고 프롬프트를 반복 개선한다. Karpathy의 auto research 아이디어를 스킬로 활용하는 식으로 소개됐다.
   2. 실행 전체 트랜스크립트를 모델에 주고 어디서 과하거나 부족했는지 분석하게 할 수도 있다.
   3. Dreams/Dreaming은 여러 세션을 모아 기억 저장소를 개선하고, 예컨대 약 10회 실행 뒤 반복 경험에서 유용한 기억을 추출해 다음 실행에 반영하는 제품이다.
   4. 스스로 개선되는 예약 흐름을 만들 수는 있지만, 플랫폼에 “일정마다 자동으로 자기 자신을 개선하는” 내장 기능이 있는 것은 아니며 이러한 구성요소를 조합해야 한다.

5. 아이들과의 몸짓 게임 예시

   1. Haiku가 웹캠을 보고 아이들과 하는 몸짓 게임의 동작을 맞히는 도구를 만들었다. 노 젓기·테니스 같은 행동을 녹화해 프롬프트 개선에 사용했다.
   2. Hill climb는 문제에 따라 프롬프트 개선용 기록 인터페이스나 산출물을 만들고, 필요한 프레임 수·초당 프레임 등을 조정할 수 있다.
   3. 최적화가 끝나면 프롬프트뿐 아니라 작업에 맞춘 사람용 인터페이스가 나올 수도 있다.

7.2. 스레드 간 통신, 권한, 중간 상태

1. 맥락은 분리되지만 파일 시스템은 공유

   1. 하위 에이전트마다 데이터베이스상 별도의 세션 스레드와 컨텍스트 윈도우가 있다.
   2. 기본 컨텍스트가 서로 섞이지는 않지만 파일 시스템은 공유된다. 직접 메시지를 보내게 하는 API 추상화는 없고, 필요하면 파일에 기록해 협업할 수 있다.
   3. 각자 다른 시스템 프롬프트로 페르소나를 분리하고, 스레드 메시지 송수신 이벤트를 통해 리드와 하위 에이전트 사이의 전달을 확인할 수 있다.

2. 경로별 접근 제어와 도구 승인

   1. 특정 디렉터리만 사용하라고 프롬프트에 쓸 수 있지만, 당시 디렉터리 경로마다 직접 접근을 잠그는 전용 권한 계층은 없었다.
   2. 도구 권한을 구성해 파일 읽기 요청을 인간 또는 정책 시스템에 보내고, 특정 경로(/mount/fubar 등)에 대한 요청을 거부하는 방식으로 통제할 수 있다.
   3. 하위 에이전트가 사람이 승인한 후속 작업을 기다리게 하려면 “인간 피드백 요청” 커스텀 도구를 제공하고 호출 시 답을 반환하면 된다.

3. 장시간 실행의 중간 결과 확인

   1. 운영체제 프로젝트에서는 각 흐름이 끝날 때마다 Sonnet 5.5를 쓰는 문서 작성팀이 해당 단계의 구현 문서를 GitHub에 작성하도록 했다.
   2. 세션 출력 디렉터리의 다운로드 파일은 V1 Files API로 내구성 있게 보관할 수 있다. GitHub 커밋과 문서도 중간 진행 상태를 살피는 수단이다.
   3. 진행 중 새 정보가 생기면 세션을 중단하고 리드에게 제공할 수 있다. 리드는 지금까지의 상태를 확인해 그 정보를 반영한 새 흐름을 시작할 수 있다.
   4. 기존 흐름의 첫 계획 중간에 단일 단계를 삽입하고 이후 단계만 다시 돌리는 기능은 지원되지 않았다.

7.3. 이미지·텔레메트리·공유·운영 환경

1. 이벤트 스트림과 멀티모달 입력

   1. API는 실시간 스트리밍과 이후 목록 조회가 가능한 풍부하고 내구성 있는 이벤트를 제공한다. 도구 호출·결과가 발생하는 시점과 하위 에이전트가 리드로 돌아가는 순간을 추적할 수 있다.
   2. 이미지 입력은 지원하지만 게임 화면을 보고 실시간 행동을 반복하는 데는 지연 때문에 당시 사용자 경험이 좋지 않을 수 있었다.
   3. 반대로 게임 크래시 화면을 찍어 디버깅을 맡기거나, 이미지를 살펴보고 후속 작업을 하게 하는 용도는 가능하다.

2. 리소스 공유와 고객 노출

   1. Terraform과 콘솔 내보내기로 에이전트를 다른 환경에 옮길 수 있지만, 사람 간 원클릭 공유 버튼은 없었다.
   2. 보통은 자체 UI를 만들어 고객이 제품 안에서 에이전트를 사용하게 한다. 공개 API의 이벤트를 활용하면 도구 호출, 대화, 차트 등을 포함한 사용자 인터페이스를 구현할 수 있다.

3. 작업 규모와 모델 노력 설정

   1. 일의 규모에 따라 자동으로 처리 방식을 바꾸는 전용 설정값은 없지만 세션별 effort 설정과 일부 에이전트 필드를 재정의할 수 있다.
   2. 평범한 주식 검색이 1,000개 에이전트를 필요로 하지는 않고, 나비에–스토크스 방정식처럼 어려운 과학 연구는 더 강한 병렬화를 요청할 수 있다. 실제 적정 규모는 평가와 작업 특성으로 결정해야 한다.

7.4. 과학 연구와 기타 실무 질문

1. 과학적 발견의 시간 단축

   1. 나비에–스토크스 방정식 같은 과학 문제에 Flows가 쓰일 수 있는지 묻자, 어려운 문제에 테스트 타임 컴퓨트를 투입해 모델의 능력을 더 빠르게 끌어내는 방식이 과학 진보를 가속할 수 있다고 답했다.
   2. Anthropic 내부 연구 하네스의 구체적인 구성은 공개하지 않았지만, API 접근성을 통해 이러한 연구를 더 넓게 수행하게 하는 것이 초기 단계라고 했다.

2. 프라이빗 MCP와 VPN 뒤의 데이터

   1. VPN 뒤의 데이터나 내부 신원을 사용해야 한다면 MCP Tunnels를 통해 Cloudflare Tunnels 기반으로 프라이빗 MCP 서버에 연결할 수 있다.
   2. 내부 MCP 서버에서 실행 환경으로 연결을 만들어 공개 인터넷에 서비스를 노출하지 않고 접근을 제공한다.

3. Anthropic 내부 사용과 내구성 이벤트의 UI

   1. 내부에서 Claude Tag 형태의 도구로 Jira와 최근 활동을 읽고 티켓 변경을 제안하는 자율 작업을 많이 한다고 했다. 매일 오전 6시에 실행하는 일정 요청도 언급했다.
   2. 이벤트를 활용해 각 Catan 플레이어가 왜 그런 선택을 했는지 설명하는 경쟁 시뮬레이션 사례도 있었다.
   3. 도구 호출을 열어 보고 차트와 기술적 분석을 생성하는 금융 대시보드 등, 이벤트 스트림에서 다양한 제품 UI를 만들 수 있다.

4. 책임과 보안에 대한 답변의 범위

   1. 악의적인 일이 발생했을 때 법적 책임이 누구에게 있는지 묻자 법률 자문은 할 수 없다고 선을 그었다.
   2. API로 제품을 제공하는 플랫폼 사업 전반과 비슷하게, 플랫폼과 제품의 각 계층이 위험을 줄이는 심층 방어(defense in depth)가 중요하다고 답했다.

7.5. Claude Code와 Flows 중 무엇을 쓸까

1. 일회성 대화와 재사용 가능한 제품 API

   1. Claude Code의 동적 워크플로는 노트북에서 터미널을 열어 사람이 직접 시작하고 지켜보는 일회성 작업에 적합하다.
   2. Managed Agents Flows는 반복 작업이나 정기 실행, 다른 제품 화면에 임베드할 API가 필요할 때 적합하다.
   3. Flows는 Claude Code의 Ultra Code식 자기 오케스트레이션 방법론을 API 층으로 일반화한 것으로 볼 수 있다.

2. 초기 프로세스 개선의 순서

   1. 결과를 검증하기 어렵거나 사람 취향이 중요한 일은 먼저 Claude Code로 과정을 함께 만들고 반복 개선한다.
   2. 충분히 좋은 절차를 만든 뒤, 그 과정을 스킬과 시스템 프롬프트로 인코딩해 Managed Agents Flows에서 재사용한다.
   3. Hill climb를 사람 중심의 선호 비교와 결합하면 결과를 두 개씩 제시하고 사람이 더 나은 것을 고르는 방식으로 프롬프트를 다듬을 수 있다.

주요 발언 모음

“The problem is that Linus doesn’t scale.” — 개인 중심 구조에는 확장 한계가 있다.

“Declare, contain, detect.” — 에이전트·권한을 선언하고, 실행 범위를 격리하며, 이벤트로 감지한다.

“The brain and hands should be separate.” — 추론 맥락과 실제 행동 환경을 분리한다.

“You can think of Claude Code as the one-off, and Claude Managed Agents as the reusable layer.” — 터미널의 일회성 실행을 제품 API의 반복 가능한 흐름으로 확장한다.

핵심 데이터 & 수치

• 1969년·한 달: 켄 톰프슨이 가족이 한 달간 떠난 동안 커널·에디터·어셈블러 등을 계획해 유닉스를 만들었다는 역사적 사례다.
• OS/360: 대략 5,000 인년과 약 1,000명 규모의 투입 추산으로 대형 프로젝트 조직의 비용을 설명했다.
• 외과 수술팀 비유: 한 책임자 주위 약 10명의 전문가가 역할을 나누고 전체 일관성을 유지한다.
• Linux 7.2: 9주, 300개 회사, 약 2,600명의 개발자 기여 사례로 신뢰 네트워크 구조를 설명했다.
• 초기 병목 비교: 조정자 하나가 약 60개 하위 에이전트를 추적하는 문제와, 별형 36명 대 계층형 단계별 약 4명이라는 그림을 비교했다.
• 주식 스캐너 데모: Apple·Nvidia·Amazon·JPM·XOM·COST 6개 종목, 각 단계 대략 6개 동시 에이전트로 실행했다.
• 모델 배분 예시: 티커당 스캔 에이전트 2개(Haiku), 검토 에이전트 2~3개(Fable)를 제안했다.
• 운영체제 실험: 최대 1,000개 에이전트, 약 85시간 실행, 3~4개 흐름, 저장소 약 1,000커밋이라고 발표자가 보고했다.
• 사용자 승인 피로: 반복 승인 요청에 사람이 약 97% 승인 버튼을 누른다는 연구 수치를 Auto Mode의 근거로 들었다.
• 예산 사례: 5달러 한도에서 일시 정지 후 증액·재개, 1.25달러 예산을 outcome과 결합하는 API 예시가 나왔다.
• 반복 기억 개선: 약 10회 실행 뒤 Dreams로 세션 경험을 정리해 기억 저장소에 반영하는 사례를 들었다.
• 영상 제작 시간: 수년 전 약 20시간 걸렸을 법한 애니메이션 작업을 작은 프롬프트에서 시작하는 흐름으로 줄였다고 했다.
• 제품 크레딧 발표: 행사 참석자에게 50달러 실험 크레딧, 구독 기반 Max·Team API 크레딧을 언급했다.

결론 및 시사점

1. 작업을 사람의 조직처럼 설계하라. 전체를 한 컨텍스트에 밀어 넣기보다 작업 단위를 나누고, 각 단위의 책임자와 검토자를 분리한다.
2. 에이전트 수보다 위임 구조와 격리가 중요하다. 같은 100개라도 단계·게이트·독립 맥락이 있는 흐름이 무질서한 병렬 실행보다 낫다.
3. 작업 크기에 맞춰 비용을 쓴다. 빠르고 싼 모델로 넓게 찾고 강한 모델로 좁혀 검토하며, 평가 세트로 품질을 확인한다.
4. 대규모 자동화는 권한을 좁히고 로그를 남겨야 한다. 평문 키를 샌드박스에 두지 말고 Vault·egress 치환·도메인 허용 목록·예산·Auto Mode를 함께 사용한다.
5. 복잡한 작업은 중간 관찰·중단·재개가 가능한 제품 API로 바꾼다. 일정·웹훅·앱 동작에 연결하고, 내구성 이벤트로 상태와 감사 흔적을 확인한다.
6. 프롬프트만으로 신뢰성을 보장하지 않는다. 조건부 실행, 경로 권한, 조직 프로세스 등 필요한 제어는 애플리케이션 계층과 운영 정책에서도 구현한다.
7. 반복 업무를 충분히 검증한 뒤 Flows로 옮긴다. 일회성 실험은 Claude Code에서 다듬고, 검증된 절차는 Managed Agents와 자체 UI에서 재사용한다.

20줄 핵심 요약

작은 소프트웨어는 한 사람이 전체 설계를 머릿속에 담는 개념적 일관성이 강점이지만, 대규모 작업에서는 그 사람이 곧 병목이 된다.

OS/360의 5,000 인년 추산과 리눅스의 유지관리자 계층은 사람의 협업 구조가 규모 확장에 필수임을 보여준다.

Claude Managed Agents Flows는 리드 에이전트가 계획을 세우고 작업 단계마다 필요한 하위 에이전트를 동적으로 구성하게 한다.

Flows는 독립 맥락과 단계별 검증으로 단일 에이전트의 태만, 자기평가 편향, 장기 작업 중 목표 이탈을 줄인다.

티커별 조사처럼 범위를 잘게 나누면 각 에이전트가 한 항목에 집중하고, 이후 별도 검토 단계에서 결과를 교차 확인할 수 있다.

저렴한 Haiku 에이전트로 폭넓게 조사하고 더 강한 모델과 병렬도를 검토 단계에 배정하면 비용과 품질을 조절할 수 있다.

콘솔 템플릿에서 흐름을 실험한 뒤 일정, Slack, GitHub 웹훅 또는 제품 API에 연결해 반복 작업으로 운영할 수 있다.

하나의 이벤트 스트림은 각 에이전트의 도구 호출·결과·메시지를 보존해 실시간 감시와 사용자 정의 UI 구성을 가능하게 한다.

비용 예산에 도달하면 세션을 멈추고 증액 후 이미 완료한 일을 보존한 채 재개할 수 있으며 사용자가 직접 인터럽트할 수도 있다.

Bug Hunter는 PR을 여러 조각으로 나눠 독립 검토와 재현 검증을 거친 오류 후보만 사람이 볼 수 있게 한다.

Explainer Studio는 조사·팩트체크·브리프·장면 제작·애니메이션·음향 단계를 연결해 제품 설명 영상을 만드는 데 쓰인다.

하위 에이전트는 세션 컨텍스트가 분리되지만 파일 시스템은 공유하므로 명시적 지시와 도구 권한으로 협업 범위를 제한해야 한다.

대규모 에이전트 실행에서는 프롬프트 인젝션, 키 유출, 데이터 반출, 권한 초과, 과소 감시를 함께 방어해야 한다.

선언·격리·감지 원칙은 역할과 권한 정의, 샌드박스·도메인 제한, 이벤트 로그 관찰과 실행 중단으로 구현된다.

Credential Vault는 컨테이너에 가짜 자격 증명만 노출하고 허용된 도메인으로 나가는 요청에서 실제 키를 치환한다.

Auto Mode와 최소 도구 권한은 사람이 무의식적으로 매번 승인하는 위험을 줄이고 필요 없는 네트워크 접근을 막는다.

발표자는 최대 1,000개 에이전트로 운영체제를 만드는 약 85시간짜리 실험을 진행했지만 당시 프로젝트는 아직 끝나지 않았다고 말했다.

에이전트 수를 늘릴수록 생기는 수익 체감은 정량화되지 않았으며 조직화된 단계와 격리가 무질서한 병렬 실행보다 낫다는 설명이 나왔다.

프롬프트 언덕 오르기와 Dreams는 과거 실행을 분석하고 반복 경험을 기억으로 축적해 워크플로를 점진적으로 개선하는 수단이다.

Claude Code는 일회성 대화형 실행에, Managed Agents Flows는 검증된 반복 업무를 API·일정·제품에 연결할 때 적합하다.

보충 질의응답: 구현상의 경계와 운영 선택

A. 플러그인·Claude Tag·마크다운 컨텍스트

1. 플러그인과 Flows의 관계

   1. 플러그인을 이루는 스킬·도구 등 개별 리소스는 API 에이전트에 연결할 수 있지만, Flows 자체를 플러그인으로 배포하는 기능은 당시 제공되지 않았다.
   2. 현재는 실행에서 생성된 텍스트 프롬프트를 Claude Code 등에 복사하는 방법을 쓸 수 있다. 제품 표면 사이의 경계는 앞으로 몇 달 동안 더 줄어들 수 있다고 언급했다.

2. Claude Tag는 별도 제품 표면

   1. Claude Tag는 Slack에서 정보를 연결하는 봇이고 Flows는 앱에 내장하는 API이므로 당시 직접적인 연동은 없었다.
   2. Flows로 Claude Tag와 비슷한 자동화 제품을 만들 수 있으며, Anthropic 내부에서도 Claude Tag가 Jira 활동을 읽고 티켓을 선제적으로 제안하는 일상 도구로 쓰인다고 했다.

3. 마크다운으로 필요한 맥락만 점진적으로 공개

   1. 관련 없는 문서까지 모든 하위 에이전트에 처음부터 넣지 말고, 인덱스 마크다운에서 커널·어셈블러·에디터 등 상세 파일로 연결해 각 에이전트가 필요한 내용을 선택적으로 읽게 할 수 있다.
   2. 이 방식은 토큰을 아끼고 업무별 맥락을 줄 수 있다. 단, API 키를 마크다운 파일에 넣어 에이전트에 주는 것은 안전하지 않다.

B. 토폴로지·정책의 현재 한계

1. 중첩 깊이

   1. 발표 초반에는 동적이고 복잡한 에이전트 망을 만들 수 있다고 설명했지만, 질의응답에서 당시 지원되는 실제 중첩은 한 단계라고 명확히 했다.
   2. 임의로 중첩되는 거대 팬아웃은 아직 지원되지 않으며, 안전성을 더 확보한 뒤 깊은 토폴로지를 확대할 수 있다고 했다.

2. 재사용 가능한 정책과 작업 규모 설정

   1. 업무의 크기에 따라 에이전트 수나 처리 방식을 자동으로 바꾸는 단일 노브는 없었다. 세션별 effort 설정과 에이전트 필드 재정의, 명시적 프롬프트, 평가가 선택지다.
   2. 흐름 자체를 예약 실행할 수는 있어도 예약 시점마다 자동으로 자기 자신을 고치는 제품 기능은 없다. 프롬프트 hill climb, Dreams, 애플리케이션 계층의 조건부 실행을 조합해야 한다.

3. 일반 코드 도구와 이미지 입력

   1. 게임 텔레메트리를 실시간으로 처리하려면 이벤트 스트림을 보고 애플리케이션에서 필요한 조치를 결정할 수 있다. 이미지 입력도 되지만 매 프레임을 처리하는 실시간 경험에는 지연이 부담이다.
   2. 반대로 크래시 화면을 첨부해 원인을 찾거나, 도구 호출을 열어 차트를 표시하는 디버깅·제품 UI는 적용하기 좋은 용도다.