Hermes Agent Masterclass: 8. Subagents & Delegation

🖼️ 인포그래픽

Hermes Agent Masterclass: 8. Subagents & Delegation 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Agent의 Subagents & Delegation은 긴 작업을 격리된 서브에이전트에 병렬 위임해 부모 컨텍스트를 깨끗하게 유지하고, 속도와 비용을 함께 최적화하는 실행 전략이다.

📌 핵심 요점

단일 에이전트 루프는 도구 호출, 재시도, 실패 경로가 부모 컨텍스트에 누적되면서 품질 저하와 환각 위험을 키우고, 여러 작업을 순차 처리할 때 벽시계 시간도 크게 늘린다.
서브에이전트 위임은 부모가 goal, context, tool set을 담은 brief를 넘기고, 자식 에이전트가 별도 컨텍스트와 터미널 세션에서 독립 실행한 뒤 최종 요약만 반환하는 구조다.
좋은 위임의 핵심은 “오류를 고쳐라” 같은 모호한 지시가 아니라 파일명, 라인, 스택, 프로젝트 루트, 실행 환경, 실제 오류처럼 자식이 독립적으로 작업할 수 있는 정보를 한 번에 제공하는 것이다.
delegate task는 batch 병렬 실행, concurrency 제한, depth 제어, synchronous/background 실행을 지원하지만, parent가 중단되면 child도 취소되는 등 durable 작업에는 적합하지 않은 경계가 있다.
영상의 비교 실험에서는 강한 부모 모델이 전체 연구를 직접 수행한 경우보다, 저가 서브에이전트가 조사 작업을 나눠 처리하고 부모가 합성만 맡은 경우 비용이 크게 줄어드는 사례가 제시됐다.

🧩 배경과 문제 정의

단일 에이전트 루프에서는 긴 하위 작업의 도구 출력, 재시도, 실패 경로가 모두 부모 컨텍스트에 누적되어 품질 저하와 환각 위험이 커진다.
여러 조사·디버깅·리팩터링 작업을 한 루프에서 순차적으로 처리하면 작업 수에 비례해 전체 시간이 늘어나고, 병렬 실행의 이점을 활용하기 어렵다.
서브에이전트 위임은 격리된 새 컨텍스트와 병렬 실행을 활용해 부모 에이전트의 컨텍스트를 작고 빠르게 유지하는 방식이다.
효과적인 위임은 목표, 실제 오류, 파일 위치, 프로젝트 루트, 도구 권한처럼 자식 에이전트가 독립적으로 실행하는 데 필요한 정보를 처음부터 충분히 제공하는 데 달려 있다.
핵심은 “에이전트를 더 많이 쓰는 것”이 아니라, fresh child agent가 유리한 작업과 cron·script·board가 더 적합한 작업을 구분하는 것이다.

🕒 시간순 섹션별 상세정리

단일 루프의 한계와 위임의 목적

Cron은 한 에이전트가 시간축을 따라 반복 실행되는 구조이고, 서브에이전트 위임은 여러 에이전트를 동시에 실행해 작업을 여러 워커로 분산하는 구조다 [00:18]
목표는 부모 에이전트가 3단계 연구 트리를 구성하고 9개 연구 작업을 병렬 실행한 뒤, 각 결과를 합쳐 하나의 답변으로 정리하는 흐름이다 [00:31]

로드맵과 컨텍스트 오염 문제

핵심 주제는 delegate task 도구, 병렬 실행, 배치 동시성, 에이전트 모니터, depth와 sync·async 제어, 그리고 서브에이전트를 쓰지 말아야 할 경우까지 포함한다 [01:18]
실습은 3단계 연구 트리를 중심으로 진행되며, 위임 구조가 단순 개념이 아니라 실제 연구 작업을 나누어 실행하는 방식임을 보여준다 [01:49]

서브에이전트의 구조와 부모 컨텍스트 보호

10개 대상을 순차 조사하면 단일 루프가 한 번에 하나씩만 처리하므로 벽시계 시간이 거의 10배로 늘고, 병렬성이 필요한 작업에서 병목이 생긴다 [03:13]
서브에이전트는 부모가 목표와 맥락이 담긴 brief를 넘기면, 새 에이전트 인스턴스가 독립적으로 작업한 뒤 보고서를 반환하는 구조다 [03:39]

delegate task 도구와 실제 병렬 실행 예시

delegate task의 기본 입력은 goal, context, tool sets이며, 실패한 테스트 원인 분석에는 실제 명령, 오류, 파일 위치, 프로젝트 루트, 스택 정보가 함께 필요하다 [04:55]
도구 세트는 자식의 목적에 맞게 제한되며, 자식은 격리된 환경에서 실행한 뒤 수행 내용, 발견 사항, 변경 여부를 구조화해 요약한다 [05:29]

결과 합성과 자식 컨텍스트의 격리 효과

에이전트 모니터와 데스크톱 앱에서는 3개 서브에이전트가 파일 읽기와 검색을 수행하는 상태를 볼 수 있지만, 해당 작업 로그가 부모 컨텍스트를 채우지는 않는다 [06:51]
병렬 작업 결과는 quant family별 모델과 주로 Q4 계열 quants를 빠르게 확인하는 형태로 합쳐지며, 순차 처리보다 짧은 시간에 전체 결과가 나온다 [07:43]

좋은 brief, 도구 제한, 저렴한 자식 모델 전략

서브에이전트는 부모의 이전 대화나 오류 맥락을 모르기 때문에, “오류를 고쳐라”처럼 목표만 던지면 원인을 제대로 파악하기 어렵다 [09:07]
자식이 독립적으로 재현하고 판단할 수 있도록 파일명, 라인, 스택, 원인, 프로젝트 루트, Python 버전 같은 정보가 goal이나 context에 포함되어야 한다 [09:22]

저가 subagent 모델 설정과 부모-자식 비용 분리

Nemotron 3는 입력 비용이 더 낮은 모델로 설정되며, delegation 설정을 통해 child subagent 전체가 이 저가 모델을 사용하도록 전환된다 [12:09]
부모 agent는 GLM 5.2 같은 강한 모델을 유지하고, 자식 agent는 token-heavy grunt work를 저가 모델에서 처리해 전체 비용 부담을 낮춘다 [12:51]

병렬 batch 실행 구조와 concurrency 제한

delegate task는 여러 task를 array로 넘기는 구조이며, 각 research task는 goal과 tool set을 가진 채 thread pool에서 병렬로 실행된다 [13:50]
결과는 input index 기준으로 정렬되어 순서가 안정적으로 유지되며, parent가 중단되거나 새 메시지를 받으면 children도 함께 취소된다 [14:10]

단일 parent agent baseline 실험

baseline 실험에서는 GLM 5.2 parent agent가 soccer data, advanced statistics, machine learning use case research를 처음부터 끝까지 직접 수행한다 [15:28]
prompt에는 subagent를 쓰지 않고 모든 research를 직접 수행하라는 조건이 들어가며, 비교를 위해 시간과 비용도 함께 추적된다 [15:52]

저가 subagent 병렬 실행과 비용 비교

새 session에서는 같은 유형의 research task에 subagent 사용 조건이 추가되고, subagent는 GLM보다 약 10배 저렴한 Nemotron 모델을 사용한다 [17:08]
세 subagent는 서로 다른 topic으로 나뉘어 병렬 실행되며, /agents command에서 각 agent의 진행 상태와 완료 여부를 확인할 수 있다 [17:44]

delegation depth와 재귀 fanout 리스크

기본 subagent 구조는 flat tree이며, depth 0의 parent가 depth 1 children을 만들고 children은 더 이상 delegation하지 못한다 [20:54]
기본 max spawn depth는 1로 제한되어 있고, 이 제한은 runaway recursive delegation으로 인한 시간·token 낭비를 막기 위한 장치다 [21:08]

synchronous/background 실행과 delegation 선택 기준

기본 delegate task는 synchronous 방식으로 parent turn 안에서 실행되며, child 작업이 끝날 때까지 parent를 block한다 [22:12]
parent를 interrupt하면 children도 함께 취소되고 결과도 버려지므로, 기본 synchronous 실행은 durable한 작업에 적합하지 않다 [22:24]

delegation보다 cron·script·board가 나은 경계

cron job은 turn을 넘어 지속되거나 정해진 schedule에 따라 실행되어야 하는 durable 작업에 적합하다 [24:03]
execute code는 reasoning이 거의 필요 없는 deterministic multi-step pipeline에 더 알맞다 [24:18]

3단계 machine learning sports research tree 설계

deep research on machine learning in sports는 3개 sport로 fan-out한 뒤 9개 research worker로 확장되고, 다시 상위 단계에서 synthesis되는 3-level tree 구조를 사용한다 [25:44]
parent model은 baseball·basketball·football research를 각각 sport child subagent에 위임한다 [26:03]

dashboard 설정과 research prompt 구성

dashboard의 delegation config에서 핵심 변경값은 max spawn depth이며, 기본값 1을 2로 바꿔 grandchild subagent까지 생성 가능한 구조로 설정한다 [27:21]
orchestrator enabled는 이미 켜져 있고, max iterations는 focused research에 맞게 낮춰 runaway exploration 가능성을 줄인다 [27:34]

live tree 실행과 desktop app 모니터링

실행 직후 baseball·basketball·American football용 subagent 3개가 먼저 spawn되며, 각각 sport-level orchestrator 역할을 맡는다 [28:51]
desktop app에서는 baseball orchestrator가 data·advanced stats·machine learning uses를 맡은 grandchild subagent 3개로 다시 delegation하는 구조가 시각적으로 드러난다 [29:53]

synthesis 결과, timeout 조정, module 8 마무리

모든 subagent가 돌아온 뒤 baseball·basketball·American football을 포함한 machine learning in sports 최종 summary가 생성된다 [30:14]
최종 report는 category별 data와 cross-sports synthesis를 함께 묶어, 병렬 조사 결과를 하나의 extensive report로 통합하는 delegation의 마무리 효과를 보여준다 [30:29]

timeout guardrail 조정과 module 8 핵심 정리

첫 실행에서는 child timeout seconds guardrail 때문에 두 단계 child·grandchild 실행이 60초를 넘기며 문제가 생겼다 [31:23]
두 번째 실행에서는 timeout 값을 높여 다시 돌렸고, 그 결과 전체 subagent tree가 정상적으로 완료됐다 [31:31]
module 8의 결론으로 delegation을 쓰는 이유는 isolated contexts, parallelism, 그리고 summary만 반환되는 구조를 이해하는 데 있다고 정리한다 [31:44]
delegate task의 single·batch 사용, sub agents don’t know rule, 비싼 orchestrator와 저렴한 child model 조합의 cost impact까지 함께 복습한다 [32:04]

subagent tree 설계 확장과 module 9 예고

desktop app에서 live로 3-level machine learning in sports research tree가 생성되고 완전히 synthesis되는 과정을 시각적으로 확인했다 [32:19]
task에 따라 subagent tree를 여러 방식으로 customize할 수 있고, 때로는 main agent가 이런 delegation을 자동으로 수행하기도 한다 [32:38]
이런 구조를 이해하면 money와 tokens를 아끼면서 더 advanced workflow를 설계할 수 있다고 마무리한다 [32:49]
다음 module 9는 profiles를 다루며, 별도 persona·memory·skills·gateways를 가진 isolated Hermes instances와 durable work 협업용 Kanban board를 예고한다 [33:25]

🧾 결론

이 강의의 핵심 메시지는 서브에이전트가 “더 많은 에이전트를 쓰는 기능”이 아니라, 컨텍스트 오염을 줄이고 병렬성을 얻기 위한 구조적 도구라는 점이다.
부모 에이전트는 판단, orchestration, synthesis에 집중하고, 자식 에이전트는 token-heavy 조사·검색·리뷰 같은 하위 작업을 맡을 때 가장 큰 효율이 난다.
위임은 독립적인 하위 작업, 긴 reasoning trace, 병렬 fanout, 저가 모델 활용이 필요한 상황에 적합하며, memory 기록, 사용자 확인, 메시지 전송처럼 순차 의존성이 강한 작업은 단일 루프가 더 낫다.
깊은 delegation tree는 강력하지만 depth와 concurrency가 곱셈으로 비용을 키울 수 있으므로, max spawn depth, max iterations, child timeout 같은 안전장치를 함께 설계해야 한다.
turn을 넘어 살아야 하거나 재시작 이후에도 유지되어야 하는 durable workflow는 background subagent보다 cron, script, Kanban board 같은 별도 구조가 더 적합하다고 정리된다.

📈 투자·시사 포인트

AI 에이전트 운영에서 비용 최적화의 핵심은 모든 작업을 가장 강한 모델에 맡기는 것이 아니라, 강한 모델은 합성과 판단에 두고 반복 조사·파일 탐색·기초 분석은 저가 서브에이전트로 분산하는 구조다.
병렬 fanout이 큰 리서치, 테스트 디버깅, 대량 파일 리뷰 같은 업무에서는 서브에이전트가 시간 단축과 컨텍스트 품질 유지에 동시에 기여할 가능성이 크다.
영상의 parent-only 대비 subagent 실험처럼 비용 절감 효과가 나타날 수 있지만, 실제 절감 폭은 task 수, 모델 단가, timeout, 실패율, synthesis 품질에 따라 달라지므로 조직별 검증이 필요하다.
운영 관점에서는 “언제 subagent를 쓰고, 언제 cron·script·board를 쓸지”를 구분하는 설계 역량이 에이전트 도입 성과를 좌우한다.
복잡한 multi-agent workflow를 쓰려면 desktop app이나 monitor를 통해 tree 구조, child 상태, token 사용량, cost를 관찰할 수 있어야 하며, 이는 비용 폭주와 실패 지점 파악에 중요하다.

⚠️ 불확실하거나 확인이 필요한 부분

영상에서 제시된 비용 비교, 즉 parent-only 방식 약 66센트와 저가 subagent 병렬 방식 약 13센트는 특정 모델, provider, 프롬프트, 실행 환경에서의 시연 결과이므로 일반적인 절감률로 단정하기 어렵다.
기본 concurrency가 subagent 3개이고, limit을 넘기면 queue나 drop 없이 error가 난다는 설명은 영상 속 Hermes Agent 설정 기준으로 보이며, 사용 중인 버전이나 profile 설정에 따라 달라질 수 있어 실제 환경에서 확인이 필요하다.
Nemotron 3가 GLM보다 약 10배 저렴하다는 비교는 영상 시점의 가격표와 provider 설정에 기반한 것으로 보이며, 현재 가격·과금 단위·토큰 처리 방식은 별도 확인이 필요하다.
자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

서브에이전트에 작업을 위임할 때는 goal만 쓰지 말고 프로젝트 루트, 파일 경로, 오류 메시지, 관련 명령, 스택 정보, 기대 결과를 brief에 포함한다.
독립적인 조사·리뷰·디버깅 작업은 단일 루프에서 순차 처리하기 전에 subagent batch로 나눌 수 있는지 먼저 판단한다.
자식 에이전트의 tool set은 목적에 맞게 최소화한다: 코드 수정은 file·terminal 중심, 조사 작업은 web 중심, 읽기 전용 리뷰는 file 중심으로 제한한다.
비용이 큰 research workflow에서는 강한 parent model과 저렴한 child model 조합을 테스트해 속도·품질·비용을 비교한다.