Fold Subagents into the Main Agent Loop: 서브에이전트를 하나의 루프로 합쳐 품질과 속도를 높이는 법

기업이 팀마다 서브에이전트를 만들고 그 위에 orchestrator를 얹으면, 에이전트 설계가 조직도를 그대로 닮아 품질·비용·지연이 함께 나빠지기 쉽습니다. 하나의 모델이 하나의 context에서 skills와 tool search로 필요한 것만 불러 쓰는 편이 대개 낫습니다. 옮기려면 작은 end-to-end eval을 먼저 만들고, 서브에이전트를 한 번에 하나씩 접어 비교해야 합니다.

요약

Anthropic Applied AI 팀의 Diane Sarkis가 2026년 10월 22일 Claude 리소스에 올린 모범 사례 글입니다. 출발점은 여러 enterprise 배포를 비교한 관찰입니다. skills를 갖춘 단일 에이전트가 ‘프롬프트 하나에 모든 것을 넣는 설계’와 ‘서브에이전트 설계’보다 품질이 자주 높았고, 작업당 비용과 지연도 대개 낮았습니다. subagent(서브에이전트)는 자기 context 창·도구·지시문을 따로 가진 채 coordinator의 지휘를 받는 에이전트입니다. 저자는 서브에이전트가 검증·병렬 작업·권한 분리에는 여전히 효과적이라고 보면서도, 팀마다 하나씩 붙이면 설계가 조직도를 닮아 간다고 말합니다.

저자가 여러 enterprise 배포를 비교해 얻은 관찰. 수치 대신 방향만 정리했습니다.

대안은 progressive disclosure(필요할 때 조금씩 드러내기)입니다. 에이전트는 skill과 tool의 짧은 설명만 먼저 보고, 실제로 필요할 때 본문과 정의를 불러옵니다. 저자는 이 방식의 장점을 셋으로 듭니다. 앞 단계 결과를 한 context에서 서로 이을 수 있고, 긴 시스템 프롬프트 때문에 일을 쪼개야 했던 이유가 사라지며, Opus 4.5 이후 모델은 한 루프에서 훨씬 많은 일을 스스로 관리한다는 것입니다. 이행은 작은 end-to-end eval을 먼저 만들고, 서브에이전트를 하나씩 skill과 MCP tool로 바꾼 뒤, 접은 쪽 점수가 더 나쁠 때만 되돌리는 방식입니다. 아래에서 작동 방식, 저자의 사례, 실제 이행 절차를 차례로 정리합니다.

저자가 권하는 이행 원칙: 측정하고, 한 번에 하나만 바꾸고, 버티는 것만 남깁니다.

핵심 메커니즘

Single Agent Loop: 계획을 쓴 모델이 실행까지 하는 루프

무엇인가. 모델 하나와 context 창 하나가 열린 tool loop를 돌리고, 한도는 harness(에이전트를 감싸 실행을 관리하는 코드)가 정하는 구조입니다.

어떻게 작동하나. 매 턴 모델이 tool call을 한 묶음(batch)으로 냅니다. harness는 이를 병렬로 실행해 가공하지 않은 결과를 같은 모델에 돌려줍니다. 모델은 다음 묶음을 낼지, 사용자에게 물을지, 답할지를 정합니다. 모델이 답하거나 turn·cost budget에 닿으면 루프가 끝나고, 원하면 답 뒤에 목표 점검이나 verifier를 한 번 돌립니다. 가장 큰 변화는 계획입니다. 모델이 첫 턴에 계획을 context에 적고, 결과가 들어올 때마다 고칩니다. 계획을 쓴 모델이 곧 실행하는 모델이어서 도중에 계획을 바꿀 수 있습니다.

언제 쓰고 언제 안 쓰나. 여러 단계의 결과를 엮어야 하는 긴 작업, 대화를 끊지 않아야 하는 고객 접점 에이전트에 맞습니다. 아래 ‘Divide by Context’의 세 조건에 해당하면 서브에이전트를 남깁니다.

원문의 예. 예전 구조의 요소가 어디로 가는지는 아래 표와 같습니다. entity resolution은 요청 속 고객·상품을 내부 ID로 맞추는 단계입니다.

작은 예시(가상). 반품 문의가 오면 모델이 ‘주문 조회 → 반품 정책 skill 로드 → 환불 가능액 계산 → 사용자 확인’을 계획으로 적습니다. 조회 결과 부분 배송임을 알게 되면 그 자리에서 계획을 고칩니다.

계획을 쓴 모델이 곧 실행하는 모델이라, 결과를 보고 그 자리에서 계획을 고칩니다.

원문이 제시한 이동 경로를 표로 정리했습니다.

Progressive Disclosure: skills와 tool search로 필요한 것만 불러오기

무엇인가. context는 skills로, 도구는 tool search로 조금씩 드러내는 방식입니다.

어떻게 작동하나. 시스템 프롬프트에는 skill과 tool마다 짧은 설명만 실립니다. 모델이 이번 작업에 필요하다고 판단하면 그때 skill 본문(절차·규칙·참고 파일)이나 tool 정의를 불러옵니다(deferred loading). 그래서 에이전트 하나가 여러 종류의 일을 하면서도 긴 지시문을 처음부터 다 싣지 않습니다. 저자는 이것이 예전에 일을 서브에이전트로 쪼갰던 주된 이유를 없앤다고 봅니다.

언제 쓰고 언제 안 쓰나. 도메인과 절차가 많아 한 프롬프트에 다 넣으면 충돌하거나 비대해지는 경우에 씁니다. 거의 모든 요청에 필요한 정보는 지연 로드하지 않고 처음부터 싣습니다.

원문의 예. Anthropic은 Claude Code의 고급 모델용 시스템 프롬프트를 80% 넘게 줄였고, 그중 일부가 skills와 tools를 지연 로드로 바꾼 결과라고 밝힙니다.

작은 예시(가상). 보험 상담 에이전트에 약관 해석, 청구 접수, 해지 방어 등 skill 20개를 둡니다. 평소에는 각 skill의 설명 한두 줄만 보이고, 청구 문의가 들어오면 청구 접수 skill 본문만 열립니다.

짧은 설명은 늘 보이고, 본문과 정의는 필요할 때 들어옵니다. 아래 막대는 저자가 밝힌 '80% 이상' 축소를 표현한 것입니다.

Conway’s Law: 조직도를 닮아 가는 에이전트

무엇인가. 시스템 구조가 그 시스템을 만든 조직의 소통 구조를 닮는다는 법칙입니다. 에이전트에서는 팀마다 자기 에이전트를 만들고, 중앙 플랫폼 팀이 그 위에 orchestrator를 얹는 모습으로 나타납니다. orchestrator-subagent 구조일 수도 있고, 각 에이전트를 MCP tool로 노출한 단일 에이전트일 수도 있습니다.

어떻게 작동하나. 겉보기엔 가장 간단하지만 곧바로 다섯 가지 복잡성이 생깁니다(아래 표). 저자는 팀마다 시스템 프롬프트에 한 문장씩 보태 규칙이 엉킨 상태를 Frankenprompt라고 부릅니다.

언제 의심하나. 서브에이전트 목록에 팀 이름이 그대로 보이면 이 법칙이 작동하고 있다는 신호입니다.

원문이 꼽은 다섯 가지 복잡성. 서브에이전트 목록에 팀 이름이 보이면 의심해 볼 신호입니다.

Divide by Context: 나눌 때는 문제 유형이 아니라 컨텍스트로

무엇인가. 멀티에이전트를 택하더라도, 나머지 시스템에서 가져올 것이 적은 일만 떼어 주고 압축된 결과 하나를 돌려받도록 나누라는 원칙입니다.

어떻게 작동하나. 좋은 후보는 서로 독립적인 조사 경로, 인터페이스가 깔끔한 별도 컴포넌트, 블랙박스 검증입니다. 반대로 배송·결제·반품처럼 문제 유형으로 나누면, 에이전트끼리 정보를 주고받을 때마다 정확도가 떨어지는 telephone game(말 전달 놀이)이 됩니다. 시작은 generator-verifier나 orchestrator-subagent처럼 통할 만한 가장 단순한 패턴으로 합니다.

언제 서브에이전트를 남기나. 저자는 세 조건을 듭니다. 단일 루프가 context bloat(컨텍스트 비대)로 측정 가능한 성능 저하를 보일 때, 여러 작업을 새 context에서 병렬로 돌리고 끝나면 버려야 할 때, 단일 에이전트가 맞는 tool을 고르지 못하거나 시스템 프롬프트의 지시가 충돌할 때입니다. Anthropic도 자사 multi-agent research system처럼 병렬 조사가 필요한 곳에는 서브에이전트를 씁니다.

멀티에이전트를 택하더라도 경계는 컨텍스트 기준으로 긋습니다.

셋 중 하나라도 해당하면 서브에이전트를 유지합니다. 해당하지 않으면 접기 후보입니다.

Skills, MCP Tools, Knowledge Bases: 서브에이전트가 하던 일을 옮길 곳

무엇인가. 도메인 지식은 knowledge base, skill, MCP tool에서 꺼내 쓸 수 있습니다. 그래서 각 팀은 에이전트 대신 skill과 tool을 소유하는 쪽으로 바뀝니다.

어떻게 작동하나. 무엇을 어디에 담는지는 아래 표와 같습니다. 핵심은 MCP tool 설계입니다. tool 정의가 30~50개를 넘으면 선택 품질이 떨어지므로 API마다 tool을 두지 않고 사용자 의도 단위로 묶습니다. 필수 전제조건도 tool 안으로 옮깁니다. Y가 X의 결과를 필요로 하면 Y의 tool이 이를 확인해 모델이 따를 지시를 돌려줍니다. 사용자별 권한도 tool이 확인해 평이한 거절을 돌려주므로, 권한 수준마다 에이전트를 둘 필요가 없습니다.

누가 소유하나. 작은 중앙 팀 하나가 시스템 프롬프트와 end-to-end 품질을 맡고, 새 skill·tool·eval을 배포 전에 검수합니다. 팀마다 DRI(책임자)를 두어 자기 skill이 잘 짜였는지, 다른 skill과 겹치지 않는지, eval과 함께 배포되는지를 챙깁니다. 저자는 skill 라이브러리 관리도 skill을 쓰는 사람에게 돌려주고, 무거운 정리 작업은 skill을 만들고 시험하고 솎아 내는 skill(/skill-creator, /skill-doctor)에 맡기라고 권합니다.

서브에이전트 프롬프트는 skills로, API 호출은 MCP tools로, 참고 자료는 knowledge base로 옮깁니다.

팀들은 에이전트 대신 skill과 tool을 소유하고, 작은 중앙 팀이 전체 품질을 책임집니다.

Task-Completion Evals: 접을지 말지를 가르는 평가

무엇인가. 에이전트가 과제를 끝까지 해냈는지 보는 평가입니다. 이행의 첫 단계이자 모든 판단의 기준입니다.

어떻게 작동하나. 중앙 팀이 소유하는 공유 end-to-end 셋 하나와, 각 팀이 자기 skill과 함께 배포하는 작은 셋으로 구성합니다. 골든 예시 10개로도 시작할 수 있습니다. 처음에는 최종 메시지를 rubric(채점 기준표)으로 채점합니다. orchestrator가 남아 있는 동안은 routing 정확도, 즉 맞는 서브에이전트를 골랐는지도 봅니다. 서브에이전트를 접은 뒤에는 맞는 skill을 로드했는지, 맞는 tool을 불렀는지를 봅니다. 시간이 갈수록 task completion 평가로 옮겨 가는데, 설계끼리 비교할 때 가장 중요한 지표이기 때문입니다.

언제 어려운가. 내부 시스템을 재현하기 어렵거나 사용자 반응을 시뮬레이션하기 어려운 환경입니다. 저자는 중요한 이벤트에 timestamp를 남겨 두었다가 나중에 재생해 targeted eval로 돌리는 방법이 Anthropic 내부에서 통했다고 말합니다.

출발점은 최종 답 채점이고, 설계 비교의 기준은 task completion으로 옮겨 갑니다.

Staged Migration: 세 단계로 하나씩 접기

무엇인가. 이미 운영 중인 orchestrator와 전문 에이전트들을 한 번에 갈아엎지 않고, 단계별로 skill과 tool로 바꿔 가는 절차입니다.

어떻게 작동하나. ① 도메인 에이전트 합치기: 사용량이 많은 것부터, 서로의 출력을 잇거나 같은 데이터를 다루거나 자주 함께 불리는 전문가끼리 합칩니다. 운영 트래픽의 상당 부분이 ‘A 다음 B’라면 강하게 결합된 쌍입니다. ② 서브에이전트를 tool로 호출: 메인 에이전트가 대화를 계속 쥐고, full handoff는 서브에이전트가 사용자와 직접 말해야 할 때만 씁니다. 다시 쓰지 않아도 되고 baseline도 얻습니다. ③ 하나씩 접기: 프롬프트는 skill로, API 호출은 MCP tool로 바꾸고 있을 때와 없을 때를 비교합니다.

무엇을 조심하나. 최종 점수만 보지 말고 결과가 뒤집힌 task를 봐야 합니다. 바꾸기 전마다 운영에서 함께 도는 에이전트 사슬마다 task 하나, 에이전트가 절대 어겨서는 안 되는 규칙마다 task 하나를 eval에 두고, 각 task를 두 번 이상 돌립니다.

단계마다 같은 E2E eval로 측정한 뒤 다음으로 넘어갑니다.

②단계는 좋은 첫걸음이지만 종착점은 아닙니다.

통념과 다른 주장

흔히 이렇게 봅니다복잡한 기업 업무는 전문 서브에이전트로 나누고 orchestrator로 묶어야 품질이 오른다.

저자는 이렇게 봅니다skills를 갖춘 단일 에이전트가 서브에이전트 설계보다 품질이 자주 높고, 비용과 지연도 대개 낮습니다.

근거Applied AI 팀이 여러 enterprise 배포를 비교한 결과이며, 한 고객사는 단일 루프에서 약 2배 빠른 실행 속도를 확인했습니다.

흔히 이렇게 봅니다팀마다 자기 에이전트를 맡기면 책임이 분명해져 관리하기 쉽다.

저자는 이렇게 봅니다그렇게 하면 설계가 조직도를 복제합니다. 팀은 에이전트 대신 skill과 tool을 소유하고, 작은 중앙 팀이 시스템 프롬프트와 전체 품질을 맡아야 합니다.

근거저자는 수백 개로 늘어난 서브에이전트, 팀마다 한 문장씩 보탠 Frankenprompt, 하위 작업에만 맞춘 eval이 반복해서 나타났다고 말합니다.

흔히 이렇게 봅니다의도 분류기, 고정 추론 파이프라인, 세그먼트 분기 같은 구조를 많이 넣을수록 에이전트가 안정적이다.

저자는 이렇게 봅니다그 구조 대부분은 모델이 더는 도움받지 않아도 되는 일을 하고 있습니다. 경직된 구조는 오히려 새 모델이 더 많은 일을 맡지 못하게 막습니다.

근거저자는 Opus 4.5부터 모델이 한 루프에서 예상보다 많은 일을 관리하게 되었고, 고객의 모델 이행을 도울 때 경직된 멀티에이전트 구조가 걸림돌이 되는 일이 많았다고 밝힙니다.

세 가지 대비. 근거는 각 상자의 설명에 있습니다.

저자가 든 사례

수십 개 전문 서브에이전트를 둔 고객 대면 에이전트

상황: 한 기업이 고객 대면 에이전트 안에 전문 서브에이전트를 수십 개 두었습니다.
한 일: 이 구조 때문에 브랜드에 맞는 일관된 응대를 유지하기 어렵고, 늘어난 지연이 사용자 경험을 해친다고 판단했습니다.
결과: 이후 조치와 수치는 원문에서 밝히지 않음.
연결: Conway’s law와 Frankenprompt가 고객 경험으로 드러난 사례입니다.

Conway's law와 Frankenprompt가 고객 경험으로 드러난 사례입니다.

흔히 제안되는 다층 설계

상황: 저자는 ‘의도 분류기 → 고정된 다단계 추론 파이프라인 → 사용자 세그먼트 버킷 → 별도 추천 분기 → 맨 위 멀티에이전트 orchestrator’ 순으로 쌓아 올린 설계안을 자주 본다고 말합니다.
한 일: 이런 설계안을 검토했습니다.
결과: 구조 대부분이 모델이 더는 필요로 하지 않는 일을 하고 있었고, 명확한 시스템 프롬프트 하나와 얇은 데이터 tool 4~5개, 단단한 출력 guardrail이면 사용 사례 대부분을 감당한다는 피드백이 많았습니다.
연결: Single Agent Loop와 세 번째 통념에 대한 근거입니다.

제안서에 흔히 보이는 진행과, 그 대부분이 이미 모델이 하는 일이었다는 피드백.

멀티에이전트 harness와 단일 루프의 직접 비교

상황: 한 고객사가 자사 멀티에이전트 harness를 단일 에이전트 루프와 견주어 평가했습니다.
한 일: 같은 일을 두 구조로 실행해 비교했습니다.
결과: 단일 루프 쪽 실행 속도가 약 2배 빨랐습니다. 품질 비교 수치는 원문에서 밝히지 않음.
연결: Conway’s law에서 다룬 다섯 번째 문제, 지연의 근거입니다.

한 고객사가 직접 비교한 결과. 저자가 밝힌 수치는 '약 2배'입니다.

Claude Code의 시스템 프롬프트

상황: Claude Code의 시스템 프롬프트가 길었습니다.
한 일: 고급 모델용으로 정리하면서 skills와 tools를 지연 로드로 바꾸는 작업을 함께 했습니다.
결과: 고급 모델용 시스템 프롬프트를 80% 넘게 줄였습니다.
연결: Progressive Disclosure가 실제 제품에서 쓰인 예입니다.

progressive disclosure가 실제 제품에서 쓰인 예입니다.

샘플 고객 지원 에이전트의 접기 실험

상황: Anthropic이 샘플 고객 지원 에이전트에서 서브에이전트 하나를 다른 서브에이전트에 접어 보았습니다.
한 일: 접기 전과 후를 eval로 비교했습니다.
결과: 지연은 줄었지만 원래 통과하던 프로세스가 깨졌습니다. 주문 조회 tool을 쥔 에이전트가 배송 전문가에게 배송일을 묻지 않고 스스로 답했기 때문입니다. 이 문제는 두 번 실행 중 한 번에서만 드러났습니다.
연결: Staged Migration에서 뒤집힌 task를 보고, 사슬·규칙마다 task를 두고, 반복 실행하라는 권고의 근거입니다.

최종 점수만 보면 놓칩니다. 뒤집힌 task와 반복 실행이 필요한 이유입니다.

기술 디테일: 단일 루프를 실제로 돌리려면

Single Agent Loop harness를 처음 세울 때는 한도부터 숫자로 정합니다. 모델이 계획을 정하더라도 끝나는 조건은 harness가 쥐어야 합니다. 아래 값은 첫 측정 전 출발점으로 둔 가상 예시입니다. Opus 5.5와 Fable 5.1은 thinking을 끌 수 없으므로, 예전 모델에서 ‘step by step으로 생각하라’고 붙여 둔 지시는 지워도 됩니다. 이런 지시를 찾는 데는 원문이 소개한 /claude-api prompt-audit을 쓸 수 있습니다.

# 가상 예시: 단일 루프 골격
while turns < MAX_TURNS and spent < COST_BUDGET:
    resp = model(messages, tools=visible_tools)       # 짧은 설명 + 검색으로 찾은 정의
    if resp.stop_reason == "end_turn":                # 답 또는 사용자 질문
        break
    calls = [write_gate(c, user) for c in resp.tool_calls]   # 쓰기 tool은 확인·승인 거침
    results = run_parallel(calls, max_concurrency=8)  # raw 결과 그대로
    messages += [resp, results]
    turns += 1; spent += resp.cost
if VERIFY: verdict = verifier(messages[-1], goal, must_not_break)

값은 가상 예시입니다. 첫 측정 뒤 p95 비용과 turn 수를 보고 조정합니다.

MCP tool을 의도 단위로 묶고 전제조건을 안에 두려면(Skills, MCP Tools 연결) get_order, patch_order, cancel_order를 따로 두지 말고 manage_order(action, order_id, …)처럼 묶습니다. 늘 보이는 tool은 20개 안팎으로 두고 나머지는 tool search 뒤에 둡니다(가상 기준, 원문의 저하 구간 30~50개보다 여유를 둔 값). tool이 막힐 때는 예외를 던지지 말고 모델이 다음 행동을 정할 수 있는 응답을 돌려줍니다.

{"status": "blocked", "reason": "prerequisite_missing",
 "next_action": "먼저 manage_order(action='lookup')로 결제 상태를 확인하세요"}
{"status": "denied", "reason": "permission",
 "message": "이 사용자는 환불 승인 권한이 없습니다. 상담원 연결을 안내하세요"}

전제조건과 권한을 tool 안에 두면 권한 수준별 에이전트가 필요 없습니다.

서브에이전트 프롬프트를 skill로 바꾸려면(Staged Migration ③ 연결) 프롬프트를 통째로 옮기지 말고 부분별로 나눕니다. routing 규칙은 skill의 description이 됩니다. description이 트리거를 결정하므로 ‘언제 이 skill을 쓰는가’를 한두 문장으로 분명히 씁니다. 역할 선언과 말투 지시는 skill에 두지 않고 중앙 시스템 프롬프트 한 곳에 모읍니다. 접은 뒤 skill이 제때 불리지 않으면 원문이 소개한 /claude-api hillclimb으로 description을 eval에 맞춰 반복 개선합니다.

Frankenprompt를 막으려면 말투와 정체성은 중앙에만 둡니다.

서브에이전트를 tool로 부르는 동안에는(Staged Migration ② 연결) 모든 서브에이전트가 같은 응답 스키마를 쓰게 합니다. 근거마다 원천 시스템과 레코드 ID를 남겨야 메인 에이전트가 실제 데이터로 결론을 다시 확인할 수 있고, 최종 합성 단계에 넘길 입력도 줄일 수 있습니다.

{"agent": "shipping_specialist",
 "conclusion": "부분 배송, 잔여 1건 10/28 도착 예정",
 "evidence": [{"source": "wms", "record_id": "SHP-20931", "field": "eta", "value": "2026-10-28"}],
 "confidence": "high",
 "open_questions": []}

공유 응답 스키마가 있어야 메인 에이전트가 결론을 확인할 수 있습니다.

eval task는 사슬과 규칙 단위로 설계합니다(Task-Completion Evals, 샘플 지원 에이전트 사례 연결). task 하나를 JSONL 한 줄로 두고, 운영에서 함께 도는 에이전트 사슬과 절대 규칙을 필드로 명시합니다. 각 task를 3회 이상 돌려 통과율로 기록하고, 설계를 바꾸면 ‘task별 전/후’ 표에서 뒤집힌 행만 먼저 읽습니다. 지표는 task completion, skill·tool 선택 정확도, p50·p95 지연, 작업당 비용 네 가지면 충분합니다. 사용자 시뮬레이션이 어려우면 운영 로그에서 timestamp가 찍힌 주요 이벤트(주문 조회, 배송일 확인, 환불 실행)를 뽑아 재생합니다.

{"id": "ship-eta-07", "input": "어제 주문한 거 언제 와요?",
 "production_chain": ["order_lookup", "shipping_eta"],
 "must_not_break": ["배송일은 shipping 근거로만 답한다"],
 "expected": {"skills": ["shipping"], "tools": ["manage_order", "get_shipment"]},
 "rubric": "배송일·근거 일치 3점, 부분 배송 안내 1점, 말투 1점", "runs": 3}

원문의 사례에서 깨진 프로세스는 두 번 중 한 번만 드러났습니다. 3회는 이 노트의 가상 기준입니다.

자주 생기는 실패와 대응(전 메커니즘 연결)

증상	원인 추정	대응
skill이 제때 로드되지 않음	description이 트리거를 못 잡음	description 재작성 → hillclimb으로 반복
엉뚱한 tool을 고름	보이는 tool이 너무 많거나 겹침	의도 단위로 묶고 나머지는 tool search 뒤로
필요한 확인 단계를 건너뜀	순서가 skill 문장에만 있음	전제조건을 tool 안으로, 사슬 task 추가
접은 뒤 성능이 점점 떨어짐	context bloat	측정으로 확인되면 그 부분만 서브에이전트로 유지
비용이 늘어남	긴 tool 결과, 불필요한 출력	/claude-api cost-optimize로 prompt caching·토큰·effort를 하나씩 조정

현업 실행 디테일: 누가, 언제, 무엇을

역할. 이행 프로젝트에는 다섯 역할이 필요합니다. 중앙 팀을 작게 두는 것은 원문의 권고이고, 인원은 가상 예시입니다.

인원은 가상 예시입니다. 중앙 팀을 작게 유지하는 것은 원문의 권고입니다.

시작 전 준비물. 서브에이전트 목록(소유 팀, 프롬프트 원문, 연결된 tool, 기존 eval), 최근 30일 호출 로그(어떤 서브에이전트가 연달아 불리는지), 현재 시스템 프롬프트 전문, 에이전트가 절대 어겨서는 안 되는 규칙 목록, 골든 예시 10~30개가 필요합니다. 호출 로그는 첫 접기 대상을 고르는 데, 규칙 목록은 must-not-break task를 만드는 데 씁니다.

일정(가상 예시, 6주). 1주차에 서브에이전트 현황을 조사하고 골든 예시 10개로 E2E eval을 만듭니다. 2주차에는 남은 서브에이전트를 tool로 부르게 바꿔 baseline을 잽니다. 3~4주차에 가장 많이 쓰이는 결합 쌍 하나를 접고 뒤집힌 task를 분석합니다. 5주차에는 두 번째 대상을 접고 prompt-audit으로 예전 모델용 지시를 정리합니다. 6주차에 판정하고 경영진에 보고합니다.

가상 예시 일정입니다. 서브에이전트가 많으면 3~5주 구간을 접기 대상 수만큼 반복합니다.

현업 확인 질문(도메인 팀 DRI용). 이 서브에이전트가 없어지면 어떤 답이 달라집니까? 보통 어떤 서브에이전트와 함께 불립니까? 사용자와 직접 말해야 하는 순간이 있습니까? 이 영역에서 절대 깨지면 안 되는 규칙 세 가지는 무엇입니까? 지금 eval은 그 규칙을 확인합니까?

진행 판정 기준(예시). 접은 버전의 task completion이 서브에이전트 버전 이상이고, must-not-break task를 3회씩 돌려 위반이 0건이며, p95 지연과 작업당 비용이 늘지 않으면 접은 버전을 채택합니다. description을 다듬어 두 번 재측정해도 미달이거나, 서브에이전트를 남길 세 조건 중 하나가 측정으로 확인되면 서브에이전트로 남깁니다.

판정 수치는 가상 예시입니다. 원칙은 '접은 쪽이 더 나쁠 때만 남긴다'입니다.

AX 적용 제언. 국내 기업의 에이전트 과제는 대개 부서별 PoC로 시작해 나중에 ‘통합 상담 에이전트’로 묶입니다. 이때 부서별 에이전트를 그대로 서브에이전트로 올리면 Conway’s law가 재현됩니다. 통합 단계의 첫 산출물은 orchestrator가 아니라 공유 E2E eval과 절대 규칙 목록입니다. 부서의 역할은 ‘에이전트 운영’에서 ‘skill·tool·eval 제공’으로 바꾸고, 시스템 프롬프트와 전체 품질은 작은 중앙 팀이 맡도록 거버넌스를 먼저 정합니다. 경영진 보고 지표는 task completion, 지연, 작업당 비용 세 가지로 통일합니다.

기술 이행과 조직 재편을 같은 순서로 묶어 진행합니다.

원문 사례

항목	내용
저자·발표처	Diane Sarkis(Anthropic Applied AI), Claude 리소스 Best practices·Perspectives, 2026.10.22
핵심 주장	서브에이전트를 줄이고 skills·tool search로 점진적으로 드러내면 품질이 오르고 비용·지연이 줄어드는 경우가 많음
비교 관찰	여러 enterprise 배포에서 skills를 갖춘 단일 에이전트가 one-prompt 설계·서브에이전트 설계보다 자주 우위
서브에이전트 유지 조건	context bloat로 측정된 저하, 버릴 context에서의 병렬 작업, tool 선택 실패·지시 충돌
실패 패턴	context 관리, subagent sprawl, Frankenprompt, 국소 eval, 지연
수치	단일 루프 약 2배 빠름(한 고객사), Claude Code 고급 모델용 시스템 프롬프트 80% 이상 축소, tool 정의 30~50개 초과 시 선택 저하, 골든 예시 10개로 시작 가능, 샘플 실험의 결함은 2회 중 1회에서만 드러남
사례	수십 개 서브에이전트 고객 대면 에이전트, 다층 설계안 피드백(시스템 프롬프트 1 + tool 4~5 + 출력 guardrail), 샘플 지원 에이전트 접기 실험
이행 단계	도메인 에이전트 합치기 → 서브에이전트를 tool로 호출 → skills·MCP tools로 접기
도구	migration kit(single-agent-loop-kit), /claude-api build-eval·prompt-audit·hillclimb·cost-optimize, /skill-creator, /skill-doctor

핵심 개념

Harness: 모델 호출을 감싸 tool 실행, 한도, 로그를 관리하는 코드.
Write gate: 쓰기·변경 tool이 실행되기 전에 확인이나 승인을 거치게 하는 관문.
Task budget: 한 작업에 쓸 수 있는 turn이나 비용의 상한. 루프의 종료 조건이 됩니다.
Deferred loading: tool 정의를 처음부터 싣지 않고, tool search로 찾았을 때 불러오는 방식.
Full handoff: 서브에이전트가 대화 자체를 넘겨받아 사용자와 직접 말하는 방식.
Generator-verifier: 한 에이전트가 만들고 다른 에이전트가 검증하는, 가장 단순한 멀티에이전트 패턴 중 하나.
DRI: Directly Responsible Individual. 특정 skill이나 영역을 끝까지 책임지는 한 사람.
Golden example: 정답이 확정된 대표 입력. eval의 출발점이 됩니다.
Migration kit: 멀티에이전트 시스템을 진단해 단일 루프로 옮기는 과정을 안내하는 Anthropic의 공개 워크플로. 가상 시스템 데모가 들어 있습니다.

내 메모

TODO: 내 생각 추가

원문: Diane Sarkis, “Building agents: When to fold subagents into your main agent loop”(Claude by Anthropic, 2026.10.22). 요약·메커니즘·통념과 다른 주장·사례는 저자가 언급한 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, 코드·JSON 예시, 설정값·일정·판정 기준, 인포그래픽, 표는 새로 작성했으며 harness 설정값·인원·일정·판정 수치는 가상 예시입니다. 원문 전체와 migration kit 링크는 Claude 리소스 페이지에서 볼 수 있습니다.