AI 에이전트가 오래 돌수록 컨텍스트 윈도우가 노이즈로 가득 차는 문제는 모델이 아니라 아키텍처 문제다. 저자는 모든 에이전트(코디네이터·워커·리뷰어)가 동일한 단일 루프를 돌며 차이는 모델·툴·시스템 프롬프트·턴 한계라는 '설정'뿐이라고 정리하고, 멀티에이전트 오케스트레이션의 3가지 패턴(Delegation / Swarm / Coordinator)을 단계별 복잡도 그라디언트로 제시한다. 핵심 엔지니어링 포인트는 프롬프트 제약이 아니라 **툴 파티셔닝** — 코디네이터에게는 spawn 툴만, 워커에게는 실행 툴만 줘서 '바쁜 매니저'와 '무한 위임' 실패 모드를 구조적으로 차단한다.

• •모든 에이전트가 동일한 루프(프롬프트→LLM→툴→반복)를 돌며, 차이는 모델·툴·시스템 프롬프트·턴 제한 등 '설정'뿐이다.
• •3가지 오케스트레이션 패턴: Delegation(1:1 포커스 위임), Swarm(병렬 팬아웃·팬인), Coordinator(research→synthesis→implementation→verification 4단계).
• •툴 파티셔닝이 핵심 — 코디네이터에는 spawn·메시지·취소 툴, 워커에는 쉘·파일·검색 툴. 양측 겹치지 않게 분리하면 '바쁜 매니저'·'무한 위임' 실패가 구조적으로 불가능.
• •프롬프트 제약이 아닌 툴 제거가 guardrail — 긴 컨텍스트·피로한 모델이 규칙을 합리화해 깨는 것을 원천 차단한다.
• •가장 흔한 실수는 잘못된 패턴이 아니라 '오케스트레이션이 불필요한데도 오케스트레이션하는 것' — 단일 에이전트 5턴이면 끝날 일은 그냥 단일로 간다.