[arXiv 2605.10913] Shepherd: 메타 에이전트를 실행 추적으로 다루는 런타임 기판

Shepherd: A Runtime Substrate Empowering Meta-Agents with a Formalized Execution Trace

https://arxiv.org/abs/2605.10913

Simon Yu, Derek Chong, Ananjan Nandi, Dilara Soylu, Jiuding Sun, Christopher D. Manning, Weiyan Shi | Northeastern University, Stanford University | arXiv:2605.10913 | 2026년 5월

---

1. 서론: 메타 에이전트에는 실행을 붙잡는 런타임이 필요하다

LLM 에이전트가 단순한 질의응답을 넘어 코드를 고치고, 터미널을 조작하고, 여러 도구를 순서대로 호출하는 시스템으로 커지면 자연스럽게 그 위에 또 다른 제어자가 올라간다. 논문은 이 제어자를 meta-agent라고 부른다. 메타 에이전트는 작업자 에이전트의 답을 평가하는 judge에 머물지 않고, 실행 중인 에이전트를 관찰하고, 중간 상태에서 되감고, 여러 후보 경로를 갈라 실행하고, 필요한 경우 한 경로를 유지하거나 버리는 상위 행위자다. Shepherd는 이 상위 행위자가 안정적으로 동작하려면 프롬프트나 로그만으로는 부족하며, 에이전트 실행 자체가 다룰 수 있는 값이 되어야 한다는 문제의식에서 출발한다.

기존 에이전트 런타임은 대개 작업자 에이전트가 자신의 상태를 이어 가도록 돕는 데 집중한다. 대화 transcript, tool log, sandbox snapshot, 파일시스템 상태 같은 조각은 남지만, 이들은 상위 제어자가 임의의 과거 시점으로 돌아가 다른 continuation을 시험하기 위한 일관된 객체로 설계되지 않았다. 그래서 supervisor, workflow optimizer, RL trainer가 각각 별도 checkpoint 로직과 replay 로직을 만들게 된다. Shepherd의 핵심 주장은 작업자 에이전트와 환경의 실행 이력을 typed event와 Git-like commit graph로 묶으면, live supervision, counterfactual optimization, tree-style RL이 같은 substrate 위에서 구현될 수 있다는 것이다.

이 논문이 다루는 범위는 꽤 야심적이다. 저자들은 functional programming의 효과 처리 개념을 빌려와 agentic execution을 task, effect, scope, execution trace라는 네 가지 일급 객체로 재구성한다. 여기에 Python framework 구현, container/sandbox level copy-on-write fork, provider prompt-cache reuse, Lean으로 기계화한 작은 의미론까지 붙인다. 결과적으로 Shepherd는 단순한 에이전트 orchestrator 라이브러리보다 낮은 층의 runtime substrate에 가깝고, 메타 에이전트가 다른 에이전트의 실행을 함수처럼 전달·관찰·분기·재실행할 수 있게 만든다.

수치상으로도 논문은 세 가지 축을 강조한다. 첫째, Shepherd는 Terminal-Bench 2.0 이미지에서 파일시스템과 에이전트 상태를 함께 fork할 때 134~143ms 수준의 지연시간을 보이며, 이는 Docker 기반 full copy나 commit 방식보다 훨씬 작다. 둘째, replay는 부모 실행의 LLM message prefix를 byte-identical하게 보존해 Anthropic API의 prompt cache에서 약 95% 수준의 hit rate를 얻는다. 셋째, 같은 primitive로 CooperBench live supervision, CRO meta-optimization, Tree-GRPO training을 구성해 각각 pair pass rate, workflow score, held-out Terminal-Bench 성능을 끌어올린다.

Figure 1: Shepherd가 지원하는 메타 에이전트 응용의 전체 그림

그림은 Shepherd가 단일 기능을 넘어 실행을 다루는 공통 substrate라는 점을 보여 준다. 위쪽에는 코딩 작업자를 감독하는 supervisor가 있고, 아래쪽에는 live supervision, meta-optimization, Tree-GRPO가 같은 trace/fork/replay primitive를 공유한다. 논문에서 중요한 대목은 응용별로 별도의 런타임을 새로 만든 방식과 달리, 실행 이력이라는 동일한 추상화가 서로 다른 세 실험에 재사용된다는 점이다.

기존 위키 맥락으로 보면 Shepherd는 이미 다룬 failure-aware agent orchestration, computer use agent reliability, commit-linked agent evaluation 흐름과 직접 이어진다. FAMA가 실패 유형을 분석해 어떤 보조 에이전트를 켤지 고르는 상위 정책을 제시했다면, Shepherd는 그런 상위 정책이 실제 실행 중 어디서 관찰하고 어디서 되돌아갈지를 제공하는 기반층이다. Workspace-Bench가 산출물, 파일 의존성, 루브릭 근거를 평가 대상으로 끌어올렸다면, Shepherd는 그 평가 근거가 실행 그래프와 효과 스트림으로 보존될 수 있는 쪽을 보여 준다.

구성 요소	논문이 제안하는 역할	리뷰에서 볼 포인트
Programming model	task, effect, scope, execution trace를 일급 객체로 정의	에이전트 실행을 함수형 효과 처리 문제로 재정의하는 부분
Runtime substrate	파일시스템, 프로세스, LLM message prefix를 함께 fork/replay	메타 에이전트가 현실적인 비용으로 branch를 늘릴 수 있는지
Applications	live supervision, CRO, Tree-GRPO, trajectory compression	같은 primitive가 서로 다른 agent lifecycle 단계에 재사용되는지

2. 배경 및 관련 연구: supervisor와 optimizer가 공통으로 요구하는 것

메타 에이전트라는 이름은 새롭지만, 그 역할은 이미 여러 흐름에서 등장했다. multi-agent framework는 작업을 여러 worker에게 나누고 message passing으로 협업을 시도한다. advisor model과 supervisor agent는 작업자가 실행 중인 과정을 읽고 조언한다. workflow optimizer는 실패한 파이프라인의 prompt나 subroutine을 고쳐 다음 후보를 만든다. tree-search RL은 긴 rollout 중간에서 가지를 뻗어 sibling trajectory 간 성패 차이로 step-level credit을 추정한다. 논문은 이들을 모두 다른 에이전트의 실행을 대상으로 삼는 higher-order agent로 묶는다.

이 묶음에서 공통 병목은 실행 state가 너무 평면적이라는 데 있다. transcript는 사람이 읽기에는 좋지만, 어느 tool call이 어떤 filesystem mutation을 일으켰고 어느 message prefix가 provider cache와 정확히 대응되는지를 안정적으로 추적하지 못한다. sandbox snapshot은 환경 상태를 되돌릴 수 있지만, 에이전트의 내부 실행 프레임과 tool event stream을 함께 다루지는 않는다. Git commit은 파일 변경 이력에는 강하지만, 모델 호출, tool intent, 관찰, reversible side effect를 하나의 typed trace로 묶는 데는 설계 목표가 다르다.

Shepherd는 이 지점을 agentic runtime and infrastructure 문제로 둔다. 논문은 OpenHands, AgentGit, BranchFS 같은 선행 시스템을 언급하며 각각이 transcript, Git-like tool, filesystem branch라는 일부 기능을 제공한다고 정리한다. 그러나 메타 에이전트가 원하는 것은 파일만 fork하거나 transcript만 읽는 것이 아니다. 작업자 에이전트가 어떤 의도를 emit했고, 그 의도가 언제 물리적 side effect로 materialize되며, 어느 지점에서 branch를 만들면 부모 실행을 오염시키지 않는지가 함께 필요하다.

이전 리뷰들과의 연결도 여기서 선명하다. computer use agent reliability는 같은 작업을 다시 시켜도 안정적으로 성공하는지 묻는다. commit-linked agent evaluation은 세션 로그와 최종 patch 결과를 연결해 실제 채택 신호를 본다. Workspace-Bench 1.0은 파일 의존성 그래프와 루브릭 근거를 통해 agent output의 provenance를 남긴다. Shepherd는 이 평가·운영 계열의 다음 층으로, 결과를 평가하기 전에 실행 자체를 rollback 가능한 그래프 구조로 남겨야 한다고 주장한다.

논문에서 흥미로운 선택은 functional programming을 단순 은유를 넘어 설계 언어로 가져온 점이다. 함수형 프로그래밍은 effectful computation을 값처럼 다루기 위해 intent와 handler를 분리한다. Shepherd는 모델 호출, tool invocation, filesystem write, custom action을 typed effect로 기록하고, handler가 이를 실행·보류·재해석하게 만든다. 이렇게 하면 meta-agent는 worker의 행동을 가로채는 감시자보다, effect stream을 읽고 handler 정책을 바꾸는 상위 함수처럼 동작한다.

메타 최적화 연구와 비교하면 Shepherd의 차이는 더 분명하다. GEPA나 MetaHarness류 optimizer는 후보 workflow를 만들고 전체 evaluation을 다시 돌리는 방식으로 score를 비교한다. 이 접근은 구현하기 쉽지만, 긴 tool trajectory에서는 같은 prefix를 계속 다시 수행하고, stochastic variation 때문에 작은 edit의 인과 효과가 흐려진다. Shepherd의 Counterfactual Replay Optimization은 edit이 처음 영향을 미치는 commit에서만 fork해 suffix를 replay하므로, 후보 검증이 full rerun보다 지역적이고 재사용 가능해진다.

3. 방법론: task, effect, scope, execution trace의 네 층 구조

Shepherd의 프로그래밍 모델은 네 개의 추상화로 정리된다. 첫째, task는 agent behavior declaration이다. 논문은 Python class와 typed input/output을 가진 `@agent` decorator를 통해 task를 선언하고, 이 task를 다른 task의 인자로 넘길 수 있게 만든다. 어떤 task가 `Issue`를 받아 `Patch`를 반환한다면 같은 type을 가진 다른 task로 대체 가능하고, supervisor task는 이런 worker task를 인자로 받는다. 이 구조 덕분에 메타 에이전트는 자연스럽게 higher-order task가 된다.

둘째, effect는 agent action을 구조화한 기록이다. 도구 호출은 단순히 텍스트 로그 한 줄로 남지 않고, 호출 의도와 결과가 분리된 typed event로 기록된다. 예를 들어 worker가 테스트 실행 도구를 호출하면 Shepherd는 먼저 tool name과 argument를 담은 intent effect를 남기고, 실행 결과가 돌아오면 outcome effect를 추가한다. 이 구분은 meta-agent가 결과를 본 뒤 평가하는 수준을 넘어, 호출이 materialize되기 전 개입할 수 있는 가능성을 연다.

셋째, scope는 agent가 실행되는 환경이다. scope는 sandbox handle, model provider binding, tool surface, filesystem state, effect stream을 함께 소유한다. meta-agent는 `scope.fork()`로 copy-on-write child scope를 만들고, `merge`로 child의 효과를 부모에 반영하거나, `discard`로 child 전체를 버릴 수 있다. 중요한 점은 fork가 작업자 message history에 그치지 않고 filesystem과 process binding까지 함께 잡는다는 점이다. 그래서 되돌림은 텍스트 상태를 넘어 실행 환경 전체의 byte-level equivalence에 가깝다.

넷째, execution trace는 과거 실행 이력이다. Shepherd는 각 scope의 effect stream을 Git-like commit graph로 materialize한다. 과거 commit은 hash로 접근 가능하고, 여러 branch는 같은 prefix를 content hash로 공유한다. persistent data structure가 과거 version을 보존하면서 suffix만 새로 갖는 것처럼, Shepherd trace도 sibling branch 간 prefix를 공유한다. 이 구조 덕분에 meta-agent는 특정 commit에서 replay를 시작해 다른 handler, 다른 prompt, 다른 subtask 정의를 시험할 수 있다.

논문은 reversible, compensable, irreversible effect의 구분도 둔다. filesystem mutation처럼 substrate가 native rollback할 수 있는 것은 reversible effect다. database write나 service mutation처럼 별도 보상 동작이 필요한 것은 compensable effect이며, handler가 compensation을 제공해야 한다. 외부 결제, 이메일, 이미 전송된 model API call처럼 되돌릴 수 없는 것은 irreversible effect로 기록은 되지만 materialization 자체는 취소할 수 없다. 이 계층은 agent safety와 감사 가능성 측면에서 Shepherd가 갖는 의미를 키운다.

형식화 측면에서 저자들은 production runtime 전체를 검증했다고 주장하지 않는다. 대신 typed effect trace의 작은 deterministic core를 Lean으로 기계화하고, 실행별 proof envelope가 어느 profile과 strength를 갖는지 명시한다. ordinary Python run은 runtime_only이고, 정적 lowering과 validator, Lean theorem boundary를 만족하는 일부 fragment만 semantic adequacy를 주장한다. 이 점은 과장된 formal verification claim을 피하면서도, 어떤 범위가 수학적으로 다뤄졌는지 분리해 보여 주는 안전한 서술 방식이다.

Shepherd primitive	기능적 대응물	에이전트 실행에서의 의미
Task	typed function	worker나 supervisor를 같은 타입 계약을 가진 값처럼 전달
Effect	algebraic effect	tool call, model call, mutation의 의도와 결과를 typed event로 기록
Scope	region-scoped handler	sandbox와 binding을 함께 fork하고 merge/discard로 반영 여부를 결정
Execution trace	persistent data structure	과거 commit을 hash로 다시 열고 sibling branch의 prefix를 공유

4. 실험 설정: 런타임 비용과 세 가지 에이전트 응용을 함께 측정한다

4.1 데이터셋 및 벤치마크

논문은 runtime substrate 자체의 성능과 그 위에서 구현한 meta-agent 응용을 나누어 평가한다. runtime 비용은 Terminal-Bench 2.0 Docker image 세 개에서 측정된다. 이미지 크기는 openssl-selfsigned-cert의 42MB부터 pytorch-model-recovery의 5.8GB까지 두 자릿수 이상 차이가 난다. 이 설정은 fork/revert가 이미지 전체 크기에 비례하는지, 아니면 copy-on-write suffix에만 반응하는지를 확인하기 위한 구성이다.

응용 실험은 세 갈래다. 첫째, live supervision은 CooperBench의 구조적 충돌 split을 사용한다. 두 worker가 서로 다른 feature를 병렬로 구현하고, 병합 후 양쪽 테스트를 모두 통과해야 pair success로 인정된다. 둘째, CRO는 HoVer, MATH Level 5, IFBench, LiveCodeBench, TerminalBench 2.0 subset에서 workflow optimization을 수행한다. 셋째, Tree-GRPO는 Endless Terminals corpus에서 학습하고 held-out Terminal-Bench 2.0의 89개 task로 out-of-distribution transfer를 본다.

4.2 구현 세부사항

runtime 측정에서 Shepherd는 containerized sandbox의 native checkpoint facility와 overlay filesystem을 통합한 device-layer interface를 사용한다. 저자들은 full rootfs copy, docker commit, Modal snapshot, BranchFS와 비교한다. 중요한 평가 항목은 fork latency, revert latency, storage delta, $K=4$ branch를 동시에 둘 때 host disk/RAM 비용이다. 또 mutation-size sweep을 통해 agent가 쓰는 변경량이 1KB에서 100MB로 늘어도 fork/revert 지연시간이 거의 평평하게 유지되는지 확인한다.

live supervision에서는 두 Claude Haiku 4.5 worker가 병렬 E2B sandbox에서 실행되고, Claude Sonnet 4.6 또는 Opus 4.7 meta-agent가 두 effect stream을 구독한다. supervisor는 `inject`, `handoff`, `discard` 세 도구를 받는다. `inject`는 worker session에 guidance를 넣고, `handoff`는 앞선 worker의 scope를 follower의 새 root로 fork해 재시작하게 하며, `discard`는 stuck worker를 중단한다. baseline은 한 worker가 순차 처리하는 solo와, 두 worker가 peer-to-peer message bus를 쓰는 coop이다.

CRO에서는 baseline workflow와 후보 workflow의 training/dev execution trace가 모두 Shepherd graph에 남는다. proposer는 이전 후보와 실패 사례를 읽고 parent candidate를 고른 뒤 candidate edit을 낸다. 각 edit에는 고쳐야 할 fix set과 regression을 막아야 할 guard set이 붙는다. Shepherd는 parent trace에서 edit이 영향을 미치는 첫 commit을 찾아 suffix만 replay하고, parent보다 나은 후보만 dev evaluation으로 보낸다. 이 구조가 전체 rerun 비용을 줄이는 핵심이다.

4.3 베이스라인

runtime 비교에서는 full copy와 Docker commit이 가장 직관적인 기준선이다. full copy는 container rootfs 전체를 복사하므로 이미지 크기에 직접 비례한다. Docker commit은 storage delta가 작지만 agent state와 typed effect stream을 함께 다루지는 않는다. BranchFS는 filesystem branch에 강하지만 worker representation과 replay primitive는 제공하지 않는다. Modal snapshot은 hosted runtime에서 가져온 비교치라 하드웨어와 network round-trip이 섞이지만, 실제 hosted sandbox 계열과의 운영 감각을 제공한다.

응용 baseline도 각 문제에 맞게 다르다. CooperBench에서는 solo와 coop이 비교점이다. CRO에서는 baseline workflow, GEPA, MetaHarness가 비교된다. Tree-GRPO에서는 동일 generation compute에 맞춘 Flat GRPO가 핵심 baseline이다. 이 배치는 Shepherd가 더 좋은 모델을 써서 성능을 올렸는지보다, 같은 또는 비슷한 agent loop에서 실행 구조를 분기·재사용할 때 무엇이 달라지는지를 보려는 설계다.

5. 주요 실험 결과: fork 비용보다 branch 활용 방식이 성능을 만든다

5.1 Runtime substrate 성능

Shepherd의 가장 기초적인 claim은 fork/revert가 충분히 싸다는 것이다. Table 2에서 Shepherd fork는 세 이미지 모두 134~143ms 범위에 있다. 42MB image와 5.8GB image 사이에 크기 차이가 큰데도 지연시간은 거의 평평하다. 반대로 full rootfs copy는 큰 이미지에서 53.5초까지 올라가고, Docker commit과 Modal snapshot도 replay와 worker state를 한 번에 다루는 기판으로 쓰기에는 느리거나 불완전하다. 이 수치가 중요한 이유는 meta-agent가 branch를 많이 만드는 순간 runtime overhead가 곧 탐색 폭의 상한이 되기 때문이다.

이미지 / 조건	비교 방식	Fork 지연시간	Revert 지연시간	해석
42MB openssl-selfsigned-cert	Shepherd	약 134ms대	수백 ms 이하	작은 이미지에서도 full copy보다 branch 생성이 가볍다
5.8GB pytorch-model-recovery	Shepherd	약 143ms	수백 ms 수준	이미지 크기가 커져도 fork 비용이 거의 증가하지 않는다
5.8GB image	Full rootfs copy	약 53.5초	수십 초 가능	branch 하나가 agent turn보다 훨씬 비싸져 meta-agent 탐색이 막힌다
Anthropic Haiku 4.5 replay	Prompt cache reuse	$K \ge 2$에서 약 95% hit plateau	해당 없음	byte-identical prefix가 실제 provider cache 이득으로 이어진다

prompt cache 결과도 단순한 최적화가 아니다. 에이전트 branch가 많아질수록 prefix가 길고 suffix가 짧은 구조가 자주 생긴다. Shepherd가 부모 실행의 message prefix를 byte-identical하게 재구성하면 provider는 이미 계산한 KV cache를 재사용할 수 있다. 논문은 Anthropic Claude Haiku 4.5와 Terminal-Bench 2.0 task에서 $K=2$ 이상부터 hit rate가 약 95%로 안정된다고 보고한다. 이는 trace fidelity가 실제 API 비용과 latency에 영향을 준다는 점을 보여 준다.

5.2 Live supervision: CooperBench coordination gap을 줄인다

CooperBench 실험은 병렬 coding agent가 서로 충돌하는 상황을 다룬다. 두 worker가 각자 feature patch를 만들면 개별로는 맞아도 병합 단계에서 충돌하거나 한쪽 수정이 다른쪽 테스트를 깨뜨릴 수 있다. coop baseline은 worker들이 message bus로 서로 소통하지만 pass rate가 28.8%에 머문다. solo baseline은 한 agent가 두 feature를 순차 처리해 57.2%에 도달하지만 시간이 길어진다. Shepherd supervisor는 이 둘 사이에서 effect stream을 읽고 필요한 순간에 guidance, handoff, discard를 사용한다.

Figure 2: CooperBench live intervention 실험 결과

Figure 2는 supervisor가 coordination gap을 얼마나 닫는지와 wall-clock overhead가 어느 정도인지 함께 보여 준다. Sonnet meta-agent는 pair pass rate를 45.3%까지 올리고, Opus meta-agent는 54.7%에 도달해 solo ceiling 57.2%에 거의 붙는다. 시간 측면에서는 parallel coop baseline이 19.8분, Sonnet supervision이 21.2분, Opus supervision이 24.2분으로 보고되어, 성능 상승에 비해 추가 시간이 비교적 제한적이다.

조건	작업자 / 제어 방식	Pair pass rate	평균 wall-clock	의미
Coop baseline	Haiku 4.5 worker 2개, peer message	28.8%	19.8분	병렬성은 있으나 충돌 조정 실패가 크다
Solo baseline	Haiku 4.5 worker 1개, 순차 처리	57.2%	28.4분	성능은 높지만 병렬 이점이 줄어든다
Sonnet supervisor	Sonnet 4.6 meta-agent	45.3%	21.2분	작은 overhead로 gap 절반 이상을 회수한다
Opus supervisor	Opus 4.7 meta-agent	54.7%	24.2분	solo ceiling에 가까워지지만 supervisor 비용은 더 커진다

이 실험은 Shepherd가 단순 snapshot tool을 넘어 live intervention interface라는 점을 가장 잘 보여 준다. supervisor는 worker의 도구 호출과 상태 변화를 관찰하고, 병합 충돌이 커지기 전에 한쪽 worker에게 방향을 주거나 앞선 worker의 scope를 handoff할 수 있다. pass rate 상승 자체도 중요하지만, 더 중요한 것은 supervisor가 worker context를 오염시키지 않고 읽을 수 있으며, 필요한 순간에만 materialization 경로를 바꾸는 구조가 가능하다는 점이다.

5.3 CRO: counterfactual replay로 workflow 최적화 비용을 줄인다

CRO는 Shepherd의 replay 기능을 workflow optimizer에 적용한 사례다. 일반적인 optimizer는 후보 prompt나 workflow edit을 만들고 evaluation set 전체를 다시 돌린다. CRO는 후보 edit이 영향을 미치는 첫 commit을 찾고, 그 지점에서 suffix만 replay한다. fix set과 guard set을 먼저 통과한 후보만 dev set으로 올라가므로, 전체 후보 탐색에서 낭비되는 full evaluation이 줄어든다. 논문은 이 구조가 LiveCodeBench에서 후반 proposer session으로 갈수록 subtask cache reuse를 60% 이상으로 끌어올린다고 보고한다.

Figure 3: LiveCodeBench에서 CRO와 기존 meta-optimization 방법 비교

Figure 3은 held-out test pass rate와 optimization wall-clock을 함께 그린다. CRO가 단지 빠른 후보 평가를 한 것이 아니라, wall-clock 축에서 더 짧은 시간 안에 경쟁력 있는 후보로 올라가는지가 핵심이다. 논문은 HoVer, MATH, LiveCodeBench, TerminalBench 2.0 등 네 데이터셋에서 CRO가 최고 test mean을 기록하고, IFBench에서는 MetaHarness가 1.0pt 앞서지만 CRO가 더 적은 시간으로 비슷한 수준에 도달한다고 설명한다.

Figure 4: LiveCodeBench에서 CRO의 subtask cache reuse 증가

Figure 4는 CRO의 비용 절감이 어디에서 나오는지 분리해 보여 준다. 첫 proposer session은 cold start라 reuse가 약 1% 수준이지만, 실행 그래프가 쌓인 뒤에는 같은 prefix와 subtask 결과가 재사용되어 60% 이상으로 올라간다. 이 패턴은 Shepherd가 단발성 checkpoint보다 누적되는 execution graph에 가깝다는 점을 보여 주며, optimizer가 오래 돌수록 이전 실패와 성공의 trace가 자산으로 바뀐다는 해석을 가능하게 한다.

방법	HoVer Test / Wall	MATH Test / Wall	IFBench Test / Wall	LiveCodeBench Test
Baseline	43.7 / -	60.7 / -	42.4 / -	30.7
GEPA	43.7 / 67분	74.0 / 20분	50.1 / 50분	48.7
MetaHarness	77.8 / 235분	79.3 / 101분	52.3 / 126분	40.0
CRO	79.4 / 120분	80.0 / 42분	51.3 / 82분	51.0

5.4 Tree-GRPO: 중간 상태 fork가 장기 RL credit을 만든다

Tree-GRPO는 Shepherd의 fork/replay를 post-training 문제에 연결한다. 장기 terminal agent task는 reward가 episode 끝에 한 번만 들어오므로, 어떤 중간 행동이 성공에 기여했는지 알기 어렵다. Tree-search RL은 중간 상태에서 sibling rollout을 만들어 성패 차이를 비교하면 credit을 더 세밀하게 줄 수 있다. 하지만 filesystem과 process 상태가 얽힌 terminal task에서는 중간 상태를 정확하고 싸게 fork해야 한다. Shepherd가 제공하는 coupled fork가 바로 이 전제다.

Figure 16: Flat GRPO와 Tree-GRPO의 group composition 비교

Figure 16은 Tree-GRPO가 학습 중 더 많은 informative group을 유지한다는 논지를 시각화한다. Flat GRPO는 쉬운 task가 포화되면서 all-one group 비중이 커지고, gradient signal을 주는 variance band가 줄어든다. Tree-GRPO는 meta-agent가 고른 중간 turn에서 sibling branch를 만들기 때문에 같은 compute에서도 성공과 실패가 섞인 그룹을 더 자주 얻는다. 논문은 이 차이가 process reward model 없이도 step-level advantage를 얻는 통로라고 본다.

Figure 17: Endless Terminals held-out 평가에서 Tree-GRPO의 reward 추세

Figure 17은 Tree-GRPO가 훈련 풀 안에서만 과적합된 결과인지 확인하기 위한 보조 근거다. held-out Endless Terminals evaluation에서 Tree-GRPO는 두 base model 모두에서 Flat GRPO보다 높은 reward로 올라가고 안정화된다. 논문은 Terminal-Bench 2.0 transfer 결과와 이 held-out curve를 함께 제시해, 중간 fork를 통한 richer rollout distribution이 train-only artifact로 끝나지 않았다고 주장한다.

학습 방식	Qwen3.5-35B-A3B avg@5	Nemotron-3-Super-120B-A12B avg@5	해석
Base	26.1% ± 4.21	30.3% ± 3.62	RL 전 terminal agent 기준 성능
Flat GRPO	34.2% ± 4.05	33.8% ± 3.41	episode-level reward를 root rollout 전체에 배분
Tree-GRPO	39.4% ± 3.87	37.2% ± 3.19	meta-agent가 고른 fork turn에서 sibling rollout을 만들어 suffix credit을 분리

Figure 18: Qwen과 Nemotron base model에서 Tree-GRPO의 train raw reward

Figure 18은 train raw reward에서도 Tree-GRPO가 Flat GRPO보다 높은 reward trajectory를 보이는 장면이다. 논문은 $G=8$ root rollout과 $K=4$ sibling branch를 사용하며, matched generation compute에서 Tree-GRPO가 더 많은 variance signal을 얻는다고 설명한다. 이 그림은 Table 4의 최종 transfer score만 보았을 때 놓칠 수 있는 학습 동역학을 보완한다.

6. 추가 분석 및 Ablation Study: 캐시, 압축, proof envelope가 주장 범위를 좁힌다

6.1 Trajectory compression은 실행 그래프의 후처리 활용을 보여 준다

부록 D의 trajectory compression은 본문 세 응용만큼 크게 강조되지는 않지만 Shepherd가 어떤 운영 가능성을 여는지 잘 보여 준다. 이미 성공한 agent trajectory는 보통 탐색, 실패한 가설, 중복 명령, 불필요한 파일 읽기를 포함한다. meta-agent가 완료된 effect stream을 읽고 적절한 fork point와 hint를 고른 뒤, worker를 그 지점에서 다시 실행해 같은 verifier를 통과하면서 더 짧은 trajectory를 만들 수 있는지 보는 실험이다. 이는 실패 복구만큼이나 성공 경로의 압축·증류에도 execution trace가 쓰일 수 있음을 보여 준다.

Figure 5: 두 worker model family와 두 benchmark에서의 trajectory compression

Figure 5는 같은 worker를 forked Shepherd scope에서 다시 실행할 때, meta-agent hint가 trajectory 길이를 줄일 수 있는지 측정한다. 왼쪽은 압축 성공 trajectory의 평균 길이를 baseline rerun과 비교하고, 오른쪽은 passing baseline 중 압축 가능한 비율을 보여 준다. 이 결과는 Shepherd trace가 단순 감사 로그로 끝나지 않고, 반복 task class에서 더 짧은 실행 정책을 찾는 후처리 자료가 될 수 있음을 시사한다.

6.2 Mutation-size sweep과 effect-stream overhead

부록 C의 mutation-size sweep은 큰 파일을 쓰는 작업에서 copy-on-write가 실제로 어떻게 반응하는지 확인한다. 5.8GB pytorch-model-recovery image에서 per-step write를 1KB, 10KB, 1MB, 100MB로 늘려도 fork는 대략 331~386ms, revert는 346~385ms 사이에 머문다. disk delta는 agent가 실제로 쓴 총량과 거의 1:1로 늘어난다. 이 결과는 Shepherd가 이미지 전체를 다시 복사하는 방식이 아니며, 비용이 base image 크기보다 divergent suffix에 붙는다는 설명을 뒷받침한다.

Per-step write	Total written	Disk delta	Fork	Revert
1KB	8KB	8.4KB	339ms	348ms
10KB	80KB	80.4KB	386ms	346ms
1MB	8MB	8.0MB	331ms	385ms
100MB	800MB	800MB	343ms	366ms

effect-stream overhead도 운영 관점에서 중요하다. 논문은 local 환경에서 raw throughput 17 events/s, logged throughput 16 events/s, event당 3.1ms 정도의 overhead를 보고한다. E2B에서는 remote overhead 때문에 event당 113ms까지 늘어나지만, 이는 substrate 개념보다 backend latency의 영향을 크게 받는다. 또 supervisor subscription이 worker context에 0 token을 추가한다는 결과는 관찰자가 worker prompt를 부풀리지 않는다는 Shepherd의 설계 의도를 잘 보여 준다.

6.3 Proof envelope는 검증 범위를 명시한다

Lean 기계화 부분은 Shepherd의 핵심 primitive가 최소한의 형식적 바닥을 갖도록 만든다. 논문은 production runtime의 Python, provider SDK, shell command, sandbox operation, retry scheduling 전체가 검증 범위에 들어간다고 말하지 않고 분명히 선을 긋는다. 검증된 것은 algebraic-effects trace machine과 그 위에서 정의된 일부 static fragment의 simulation 성질이다. Core-0, Core-A, Core-0H 같은 profile은 각 trace가 어떤 theorem surface에 기대는지 구분한다.

이 태도는 꽤 중요하다. 에이전트 시스템 논문은 종종 “formal”이라는 표현을 넓게 쓰지만, 실제 구현 전체가 수학적으로 안전하다는 뜻은 아니다. Shepherd는 proof envelope를 trace에 붙일 수 있게 하고, ordinary Python run은 runtime_only로 두며, reference validator를 통과한 trace와 Lean theorem coverage를 받는 trace를 구분한다. 따라서 사용자는 어느 실행이 감사를 위한 구조화 로그인지, 어느 실행이 작은 의미론 범위 안에서 simulation claim을 갖는지 분리해 볼 수 있다.

6.4 CRO 알고리즘을 실행 단위로 다시 읽기

CRO의 알고리즘적 핵심은 후보 edit을 낼 때마다 전체 workflow를 처음부터 다시 실행하지 않는 데 있다. proposer는 이전 후보들의 성공·실패 trace, 고쳐야 할 training example, 지켜야 할 guard example을 함께 읽는다. 그런 다음 parent workflow $p$와 edit $\Delta_i$를 묶어 candidate $c_i=p\oplus\Delta_i$를 만든다. Shepherd는 이 edit이 영향을 주는 가장 이른 effect commit을 찾고, parent trace의 그 지점에서 child scope를 fork한 뒤 suffix만 재실행한다. 이렇게 하면 후보 하나의 검증 단위가 전체 trajectory에서 affected suffix로 줄어든다.

fix set과 guard set의 조합도 중요하다. fix set은 edit이 해결하겠다고 주장한 실패 사례이고, guard set은 기존에 맞던 행동이 깨지지 않는지 보는 작은 방어 집합이다. CRO는 이 두 집합에서 parent보다 나은 후보만 dev evaluation으로 올린다. 이 절차는 전통적인 prompt optimizer의 “많이 생성하고 전체 평가” 방식보다 더 원인 지향적이다. 후보가 어떤 실패를 고치려는지 먼저 명시하고, 그 실패에 직접 연결된 실행 suffix만 재생한다는 점에서 counterfactual debugging에 가깝다.

이 구조가 유효하려면 trace 안에서 edit dependency를 찾을 수 있어야 한다. flat transcript만 있으면 어느 prompt fragment가 어느 tool call과 어느 downstream answer에 영향을 주었는지 거칠게 추정할 수밖에 없다. Shepherd는 typed effect와 commit graph를 통해 dependency boundary를 더 세밀하게 잡는다. 물론 논문이 말하듯 system prompt 전체처럼 넓게 영향을 주는 edit은 suffix가 거의 전체 실행으로 커진다. 하지만 local subroutine, tool wrapper, intermediate prompt, verifier instruction처럼 영향 범위가 좁은 edit에서는 replay savings가 커진다.

이 대목은 agent 개발 워크플로에도 실용적이다. 실패한 coding agent session을 보고 사람이 “이 지점에서 다른 테스트를 먼저 돌렸다면 어땠을까”, “이 tool output을 더 짧게 요약했다면 다음 edit이 달라졌을까” 같은 질문을 자주 던진다. Shepherd식 trace가 있으면 이런 질문이 감상적 사후 분석에 그치지 않고, 특정 commit에서 branch를 열어 다시 실행하는 실험이 된다. 따라서 CRO는 benchmark optimizer인 동시에, 장기 agent debugging을 counterfactual experiment로 바꾸는 예시다.

논문의 Table 3에서 CRO가 MetaHarness보다 항상 압도적으로 높은 점수를 내는 것은 아니다. IFBench에서는 MetaHarness가 52.3, CRO가 51.3으로 1.0pt 앞선다. 그러나 CRO는 그 상황에서도 wall-clock 82분으로 MetaHarness의 126분보다 짧다. 이 결과는 성능 승리만 보지 말고 동일하거나 비슷한 품질을 더 낮은 재실행 비용으로 얻는 방식의 장점으로 읽어야 한다. 특히 TerminalBench 2.0처럼 각 실행이 무거운 benchmark에서는 full rerun을 줄이는 substrate가 더 큰 의미를 갖는다.

6.5 Tree-GRPO의 credit assignment를 수식 관점으로 풀어 보기

Tree-GRPO는 기존 GRPO의 group baseline을 중간 상태 branch로 확장한다. Flat GRPO에서는 prompt 하나에 대해 $G$개의 root rollout을 샘플링하고, 각 trajectory의 outcome reward를 trajectory 전체 action에 넓게 나눠 준다. 이 방식은 episode가 짧고 행동 수가 적을 때는 충분할 수 있다. 하지만 terminal agent처럼 수십 번의 command와 file edit이 이어지는 환경에서는 마지막 성공/실패 하나가 어느 command 때문인지 흐려진다. Shepherd는 중간 상태를 정확히 fork할 수 있으므로, 한 root rollout 안의 선택된 turn $t$에서 $K$개의 sibling branch를 추가로 만든다.

그 결과 학습 신호는 두 층으로 나뉜다. $t$ 이전의 prefix action은 기존 root rollout 간 비교에서 advantage를 얻고, $t$ 이후의 suffix action은 같은 fork group 내부의 sibling outcome 차이에서 advantage를 얻는다. 논문은 이를 $G(K+1)$ trajectory 구조로 설명한다. 실제 generation cost는 모든 prefix를 새로 생성하는 방식보다 낮다. parent prefix를 공유하고 suffix branch만 추가로 생성하기 때문이다. 여기서 Shepherd의 fork가 정확해야 sibling 비교가 의미를 갖는다.

이 접근은 process reward model을 따로 학습하지 않는다는 점에서도 흥미롭다. 많은 long-horizon RL 연구는 step-level reward를 얻기 위해 judge model이나 verifier를 촘촘히 붙인다. Tree-GRPO는 outcome reward만 유지하면서도 sibling branch의 상대 성패를 이용해 어느 중간 선택 이후가 좋았는지 추정한다. 따라서 reward modeling 비용을 늘리는 대신 state branching 비용을 낮추는 쪽으로 문제를 옮긴다. Shepherd가 그 비용 이동을 가능하게 한 substrate다.

다만 fork turn을 고르는 meta-agent의 역할은 여전히 크다. 너무 이른 지점에서 fork하면 sibling들이 모두 긴 suffix를 실행해야 하고, 너무 늦은 지점에서 fork하면 이미 중요한 결정이 끝난 뒤라 informative variance가 줄어든다. 논문은 meta-agent가 선택한 turn에서 Tree-GRPO가 variance band를 더 오래 유지한다고 보여 주지만, 어떤 기준으로 fork turn을 고르는 것이 최적인지는 별도 연구 주제다. 향후에는 실패 유형, command class, file mutation density, verifier failure message를 함께 넣어 fork turn policy를 학습하는 방향이 자연스럽다.

또한 Terminal-Bench 2.0 transfer 결과는 운영적으로도 의미가 있다. Qwen3.5-35B-A3B에서는 Base 26.1%, Flat GRPO 34.2%, Tree-GRPO 39.4%로 올라간다. Nemotron-3-Super-120B-A12B에서도 Base 30.3%, Flat GRPO 33.8%, Tree-GRPO 37.2%다. 두 모델 모두에서 gain이 보인다는 점은 특정 작은 모델의 우연한 artifact라기보다, branch-based credit이 terminal task 학습에 실제 정보를 추가했을 가능성을 높인다.

6.6 Shepherd를 agent 관측 계층으로 볼 때의 운영 의미

Shepherd의 effect stream은 단순한 로그 저장소보다 더 강한 의미를 가진다. 일반 로그는 보통 사후 설명을 위해 쌓인다. Shepherd의 effect는 실행과 handler 사이에 위치하기 때문에 materialization 이전의 intent와 materialization 이후의 outcome을 구분한다. 이 구분은 agent observability에서 매우 중요하다. worker가 어떤 도구를 호출하려 했는지와 실제 도구가 무엇을 반환했는지, 그리고 그 사이에서 supervisor가 개입했는지를 분리해 남길 수 있기 때문이다.

이 관점은 provenance-aware agent evaluation과도 잘 맞는다. Workspace-Bench는 산출물과 파일 dependency graph를 함께 평가했지만, 그 산출물이 어떤 tool sequence와 어떤 fork history에서 나왔는지는 benchmark harness 밖의 문제로 남았다. Shepherd trace를 붙이면 산출물 파일, 수정 diff, tool call outcome, meta-agent intervention, discarded branch까지 같은 lineage 안에서 볼 수 있다. 그러면 Agent-as-a-Judge가 최종 답만 보는 대신, 어떤 근거가 어떤 branch에서 채택되었는지까지 평가할 수 있다.

실무 배치에서는 trace storage policy도 중요하다. 모든 effect를 무기한 보관하면 비용과 개인정보 문제가 커진다. 반대로 너무 빨리 줄이면 replay와 감사 능력이 사라진다. Shepherd 계열 시스템은 trace를 prefix hash, suffix delta, irreversible effect summary, redacted content pointer처럼 층화해서 저장할 필요가 있다. 특히 사용자 파일이나 API token이 포함된 tool output은 content-addressed graph에 그대로 남기기보다, cryptographic hash와 접근 통제된 blob store를 분리하는 설계가 요구된다.

또 다른 운영 포인트는 merge policy다. fork된 branch 중 하나를 선택해 parent에 merge할 때 무엇을 기준으로 삼을지 정해야 한다. verifier success만으로 충분한 작업도 있지만, coding agent에서는 테스트 통과, diff 크기, 보안 scanner 결과, 사용자 style guide 준수, dependency update 여부가 모두 기준이 될 수 있다. Shepherd는 merge primitive를 제공하지만, merge decision은 여전히 meta-agent 또는 사람 reviewer의 정책이다. 따라서 substrate와 governance layer를 분리해 설계하는 편이 안전하다.

이런 점에서 Shepherd는 agent safety에도 직접적인 언어를 준다. irreversible effect가 materialize되기 전 supervisor가 halt-and-inspect를 수행하고, compensable effect에는 compensation handler를 요구하며, reversible effect는 scope discard로 폐기할 수 있다. 이 구조를 제대로 쓰면 “에이전트가 위험한 일을 하지 않도록 조심한다”는 추상적 원칙을, effect tier와 materialization gate라는 실행 규칙으로 바꿀 수 있다. 물론 외부 세계의 모든 효과가 깔끔히 되돌려지는 것은 아니므로, gate 설계가 실제 안전성을 좌우한다.

6.7 기존 리뷰 흐름과의 연결: 실패 분석에서 실행 기판으로

FAMA와 Shepherd를 나란히 놓으면 역할 분담이 명확해진다. FAMA는 baseline agent가 어디서 반복적으로 실패하는지 분석하고, 그 실패 유형에 맞는 전문 agent subset을 선택하는 framework다. Shepherd는 그런 전문 agent가 실제로 worker 실행에 개입할 때 필요한 fork, observe, replay, discard를 제공한다. FAMA가 “어떤 보조자가 필요한가”를 묻는다면 Shepherd는 “그 보조자가 어느 상태를 안전하게 건드릴 수 있는가”를 묻는다. 두 접근은 경쟁 관계보다 상하위 계층 관계에 가깝다.

SWE-chat과의 연결도 있다. SWE-chat은 coding agent의 line-level authorship, user pushback, code survival을 통해 최종 commit에 남는 신호를 분석했다. Shepherd trace가 붙으면 세션 중간의 discarded branch와 accepted branch를 비교할 수 있고, 인간이 어떤 시점에서 pushback했는지도 trace commit에 매달 수 있다. 이렇게 되면 code survival은 단순히 최종 diff에 남은 비율을 넘어, 어떤 execution branch가 살아남았는지를 함께 보는 지표가 된다.

Workspace-Bench는 파일 의존성 그래프와 루브릭 근거를 붙여 업무공간 agent를 평가했다. Shepherd는 그 file dependency가 실제 실행 중 어떻게 발견되었는지, 어떤 파일을 잘못 읽어 discarded branch가 생겼는지, 어느 branch에서 올바른 lineage를 찾았는지 기록할 수 있다. 이 조합은 업무공간 agent 평가를 “정답 파일을 맞혔는가”에서 “정답 파일로 가는 실행 경로가 재현 가능한가”로 확장한다. 장기적으로는 benchmark manifest와 runtime trace가 같은 식별자를 공유해야 한다.

LongSeeker 같은 장기 검색 에이전트와도 간접적으로 이어진다. LongSeeker는 working context를 압축·발췌·삭제·되돌리는 Context-ReAct 계열의 context management를 다뤘다. Shepherd는 context 내부의 token selection보다 더 아래에서 실행 상태 자체를 branch한다. 두 층이 결합되면, 검색 에이전트는 단순히 context window 안의 문장을 정리하는 수준을 넘어, 특정 검색 branch를 폐기하고 다른 branch를 재개하는 방식으로 장기 탐색을 관리할 수 있다.

이런 연결들을 보면 Shepherd의 진짜 강점은 특정 benchmark 최고점을 조금 올린 데만 있지 않다. agent 평가, agent orchestration, agent training, agent observability가 서로 다른 도구군으로 흩어져 있던 상황에서, 실행 trace를 공통 객체로 삼자는 제안을 했다는 데 있다. 좋은 trace가 있으면 실패 분석은 더 구체적이 되고, 좋은 실패 분석이 있으면 supervisor policy가 좋아지며, 좋은 supervisor policy는 다시 더 유용한 trace를 만든다. 이 선순환의 출발점이 runtime substrate다.

7. 한계점 및 향후 연구 방향: 좋은 substrate와 좋은 meta-policy는 다른 문제다

논문은 세 case study를 proof-of-existence로 둔다. 이는 Shepherd primitive가 의미 있는 uplift를 만들 수 있음을 보여 주는 데는 충분하지만, 각 응용에서 최적의 meta-agent policy를 찾았다는 뜻은 아니다. CooperBench supervisor의 prompt, CRO proposer의 edit 전략, Tree-GRPO의 fork turn 선택은 모두 더 큰 sweep과 더 다양한 model family에서 다시 검증될 여지가 있다. Shepherd가 좋은 substrate라는 claim과, 그 위에서 쓴 특정 meta-agent가 범용적으로 최고라는 claim은 분리해야 한다.

두 번째 한계는 meta-agent 비용이다. live supervision에서는 Sonnet 4.6 또는 Opus 4.7 meta-agent가 Haiku 4.5 worker를 감독한다. CRO에서는 GPT-5.4 계열 meta-optimizer가 GPT-5.4-mini executor를 다룬다. 작업이 짧거나 worker 비용이 매우 낮은 경우, supervisor나 proposer token cost가 실행 이득을 잠식할 수 있다. 논문은 wall-clock을 중심으로 강한 결과를 보여 주지만, 실제 제품 배치에서는 latency, dollar cost, 실패 시 복구 비용, 사람 검수 비용을 함께 따져야 한다.

세 번째 한계는 counterfactual replay의 지역성 가정이다. CRO는 edit이 처음 영향을 미치는 commit부터 suffix만 replay할 때 이득이 크다. 하지만 edit이 system prompt 전체나 매 step 호출되는 core tool에 영향을 주면 affected suffix가 거의 전체 trajectory가 된다. 논문도 cold first proposer session에서는 reuse가 낮고, 두세 session 뒤에야 amortization이 커진다고 설명한다. 즉 Shepherd는 모든 workflow edit을 싸게 만드는 만능 장치가 아니라, locality가 있는 edit에서 특히 강하다.

네 번째 한계는 외부 side effect다. Shepherd는 reversible, compensable, irreversible effect를 나누지만, 현실 서비스에서는 compensable effect의 정의가 어렵다. database write는 rollback할 수 있어도 외부 API가 보낸 알림, 결제 요청, 사용자에게 보이는 메시지는 이미 사회적 효과를 만든다. 따라서 safety-critical 배치에서는 irreversible materialization 이전에 별도 승인 gate를 두고, Shepherd trace는 그 gate의 근거를 제공하는 방식으로 쓰는 편이 더 안전하다.

향후 연구 방향은 넓다. 첫째, meta-agent가 worker의 effect stream을 읽고 어떤 fork point를 골라야 하는지 학습하는 정책 연구가 필요하다. 둘째, worker 자체가 `fork`, `discard`, `replay`를 native action으로 쓰도록 post-training할 수 있다. 셋째, interpretation 목적의 counterfactual replay가 가능하다. 특정 prompt span, tool output, memory entry를 제거하거나 바꾸고 같은 suffix를 실행해 결과가 어떻게 바뀌는지 보면, agent decision의 인과적 기여를 더 직접적으로 분석할 수 있다.

7.1 실제 배포에서 확인해야 할 체크리스트

Shepherd 계열 runtime을 실제 제품에 붙인다면 가장 먼저 확인할 것은 effect taxonomy다. 파일 쓰기, 테스트 실행, 패키지 설치, 서버 시작, 외부 API 호출, 결제, 이메일, 사용자 알림은 모두 다른 rollback 성질을 갖는다. 논문은 reversible, compensable, irreversible tier를 제공하지만, 각 조직의 도구 표면이 어느 tier에 속하는지는 운영자가 직접 정의해야 한다. 특히 outbound network call이나 user-visible notification은 기술적으로 재시도 가능한 경우에도 사회적 의미에서는 되돌림이 어려울 수 있다.

두 번째는 state fidelity test다. fork 후 discard했을 때 working directory hash가 같다는 검증만으로 충분하지 않을 수 있다. 장기 agent는 background process, open socket, temporary credentials, package cache, hidden state file, model provider message prefix를 함께 들고 다닌다. Shepherd의 장점은 이들을 하나의 scope로 묶겠다는 데 있지만, 실제 backend별로 어떤 state가 checkpoint boundary 안에 들어오는지 정기적으로 테스트해야 한다. 논문이 E2B, Modal, Daytona 같은 cross-backend portability를 따로 확인한 이유도 여기에 있다.

세 번째는 human override latency다. live supervisor가 효과적이려면 worker가 위험한 effect를 emit한 뒤 materialize되기 전까지 사람이든 meta-agent든 판단할 시간이 있어야 한다. 너무 많은 effect를 synchronous gate로 묶으면 agent throughput이 떨어지고, 너무 적게 gate하면 irreversible event가 먼저 나간다. 그래서 배포 시스템은 effect tier마다 default policy를 달리 가져가야 한다. 예를 들어 filesystem write는 자동 materialize, package install은 sandbox 안에서만 허용, 외부 API POST는 supervisor 승인, 결제는 사람 승인처럼 층을 나눌 수 있다.

네 번째는 trace retention과 privacy다. agent trace는 매우 가치 있는 디버깅 자산이지만, 사용자의 private file, secret, prompt, 실패한 코드, 조직 내부 자료를 포함할 수 있다. 따라서 content-addressed graph를 그대로 장기 보관하는 전략은 위험하다. trace에는 구조와 hash, effect type, timing, branch relation을 남기고 민감 payload는 별도 암호화 저장소에 두는 식의 분리가 필요하다. 이 설계가 빠지면 replay 가능성은 높아져도 보안·감사 정책과 충돌할 수 있다.

다섯 번째는 evaluation protocol이다. Shepherd를 붙인 agent가 좋아졌다고 주장하려면, pass rate와 latency 외에도 discarded branch 수, branch당 평균 suffix 길이, cache-hit rate, intervention precision, rollback failure rate를 함께 보고해야 한다. 그래야 성능 향상이 더 강한 supervisor model 덕분인지, 더 많은 branch를 쓴 덕분인지, substrate 재사용 덕분인지 분해할 수 있다. 이 지표들은 향후 meta-agent 논문에서 표준 observability metric으로 자리 잡을 가능성이 있다.

7.2 논문 주장에 추가되면 좋을 ablation

첫 번째로 필요한 ablation은 coarse snapshot baseline이다. 같은 supervisor와 같은 worker를 두고, 한쪽은 Shepherd effect stream을 읽게 하고 다른 한쪽은 일정 간격 sandbox snapshot과 transcript만 읽게 만드는 비교다. 이 실험은 typed effect가 실제 개입 타이밍과 pass rate에 얼마나 기여하는지 분리한다. 만약 coarse snapshot도 비슷한 결과를 낸다면 Shepherd의 형식화 가치는 주로 개발 편의와 추적성에서 나오고, 성능 이득은 supervisor policy에서 나온다고 해석해야 한다.

두 번째 ablation은 fork point policy다. Tree-GRPO에서 meta-agent가 고른 fork turn과 random turn, heuristic turn, failure-message-triggered turn을 비교하면 중간 branch의 가치가 더 분명해진다. 지금 결과는 meta-agent-guided branch가 좋다는 방향을 보여 주지만, 어떤 정보가 fork turn 선택에 결정적인지는 더 자세히 알기 어렵다. file mutation 직후, long command 직후, failed test 직후, tool observation entropy가 큰 지점처럼 후보 기준을 나누면 후속 연구가 설계하기 쉬워진다.

세 번째는 cost-normalized quality다. 논문은 wall-clock을 잘 보고하지만, 실제 운영에서는 token cost와 sandbox cost가 함께 중요하다. Sonnet/Opus supervisor가 Haiku worker를 감독할 때, 한 pair를 더 성공시키는 데 든 추가 dollar cost가 얼마인지, CRO가 MetaHarness보다 줄인 wall-clock이 token price까지 포함해도 이득인지 별도 표로 보고하면 제품 배치 판단이 쉬워진다. 특히 short task와 long task를 나누어 break-even point를 제시하면 Shepherd의 적용 범위가 더 선명해진다.

네 번째는 trace corruption과 replay drift 실험이다. 실제 agent 실행에서는 provider API 응답 형식, tool version, package registry 상태, environment variable이 바뀌어 replay가 drift할 수 있다. Shepherd가 byte-identical prefix와 filesystem state를 보존해도 외부 dependency가 달라지면 suffix 결과가 달라진다. 따라서 replay drift rate를 측정하고, 어떤 effect가 drift를 일으키는지 분류하면 runtime substrate의 신뢰 경계가 더 구체화된다.

마지막으로 필요한 것은 multi-human collaboration 조건이다. 많은 실제 코딩 환경에서는 meta-agent 하나가 아니라 여러 개발자, CI bot, reviewer, security scanner가 같은 agent output에 개입한다. Shepherd trace graph가 이런 다중 검수자의 intervention을 어떻게 표현하고, 충돌하는 merge decision을 어떻게 남기는지 보면, 이 substrate가 개인 agent runtime을 넘어 팀 단위 agent operating system으로 확장될 수 있는지 판단할 수 있다.

8. 내 해석: 약점 1 + 후속 제안 1

내가 이 논문에서 가장 설득력 있게 본 부분은 Shepherd가 메타 에이전트 정책보다 낮은 층의 문제를 잡았다는 점이다. 이전에 리뷰한 FAMA는 실패 유형을 분석해 어떤 전문 에이전트를 켤지 고르는 orchestration 관점이 강했고, Workspace-Bench는 산출물과 파일 의존성 평가를 구조화하는 benchmark 관점이 강했다. Shepherd는 그 둘 사이에 놓인 실행 기반층을 제시한다. 실패 유형을 알아도 중간 상태를 되돌릴 수 없으면 개입은 prompt 조언에 머물고, 파일 의존성을 평가해도 trace가 불완전하면 왜 그런 산출물이 나왔는지 재현하기 어렵다. 이 논문은 그 빈칸을 “실행을 branch 가능한 값으로 만들자”는 방식으로 메운다.

다만 내가 걸리는 약점은 case study들의 설득력이 substrate 효과와 meta-policy 효과를 완전히 분해하지는 못한다는 점이다. CooperBench에서 Opus supervisor가 54.7%까지 올라간 결과는 강하지만, 그 안에는 Shepherd의 effect stream, Opus 4.7의 강한 판단력, supervisor prompt, handoff/discard 도구 설계가 모두 섞여 있다. CRO도 suffix replay 자체와 proposer의 edit 품질이 함께 작동한다. 논문은 proof-of-existence framing을 명시하기 때문에 이 점을 과장하지 않지만, 실제 독자가 “Shepherd를 쓰면 어떤 meta-agent라도 좋아진다”로 읽지 않으려면 더 많은 ablation이 필요하다.

내가 후속으로 붙여 보고 싶은 실험은 substrate-only ablation이다. 같은 supervisor prompt와 같은 meta-agent model을 두고, 하나는 Shepherd의 typed effect/fork/replay를 쓰고 다른 하나는 transcript plus coarse snapshot만 쓰게 만든 뒤, intervention timing과 rollback accuracy, cache reuse, 최종 pass rate를 분리해서 비교하는 것이다. 특히 commit-linked agent evaluation 관점으로 보면, 단순 성공률보다 “몇 번째 tool call에서 개입했는지”, “개입 뒤 실제 diff가 얼마나 줄었는지”, “discard된 branch가 어떤 실패 패턴을 남겼는지”를 함께 저장해야 Shepherd 고유의 가치가 더 잘 드러난다.

또 하나의 후속 제안은 Shepherd trace를 사람 검수 인터페이스와 직접 연결하는 것이다. 지금 논문은 meta-agent가 trace를 읽는 쪽에 초점을 둔다. 하지만 실제 배포에서는 사람 reviewer가 언제 irreversible effect를 승인할지, 어느 branch를 merge할지, 어떤 replay 결과를 신뢰할지를 결정하는 장면이 많다. trace graph 위에 “중단해야 하는 effect”, “사람에게 보여 줄 최소 diff”, “다시 실행해도 같은 결과가 나오는 branch”를 표시하는 UI를 만들면, Shepherd는 자동 agent substrate를 넘어 human-in-the-loop audit substrate가 될 수 있다.

9. 결론: agent 실행을 값으로 만드는 방향

Shepherd는 메타 에이전트 연구에서 중요한 질문을 한 단계 낮은 층으로 내린다. “어떤 supervisor prompt가 좋은가”보다 먼저 “supervisor가 작업자의 어떤 실행 상태를 읽고 되돌릴 수 있는가”를 묻는다. “어떤 optimizer가 좋은 edit을 내는가”보다 먼저 “candidate edit을 전체 rerun 없이 counterfactual하게 검증할 수 있는가”를 묻는다. “어떤 RL reward가 좋은가”보다 먼저 “장기 terminal trajectory 중간 상태에서 sibling rollout을 정확히 만들 수 있는가”를 묻는다. 이 질문들이 모두 runtime substrate의 문제로 모인다는 점이 논문의 가장 큰 기여다.

논문의 세 응용은 서로 다른 위치에 있다. live supervision은 실행 중 개입이다. CRO는 실행 후 최적화다. Tree-GRPO는 훈련 중 credit assignment다. 세 경우가 같은 task/effect/scope/trace primitive를 공유한다면, 앞으로의 agent stack은 application framework와 runtime substrate가 더 분리될 가능성이 있다. 작업자는 도구를 호출하고 파일을 바꾸지만, substrate는 그 행동을 typed event로 남기고, meta-agent는 그 이력을 바탕으로 더 높은 수준의 control을 수행한다.

물론 Shepherd가 곧바로 production agent safety의 해답은 아니다. irreversible side effect, meta-agent 비용, policy optimality, backend별 checkpoint fidelity, 장기 trace 저장 비용 같은 문제는 남아 있다. 하지만 이 논문은 에이전트 시스템을 대화 로그 더미로 다루는 방식에서 벗어나, 실행 그래프와 rollback 가능한 scope를 중심으로 다시 설계할 수 있음을 보여 준다. 개인적으로는 이 방향이 장기 에이전트의 신뢰성, 평가, 안전, 학습을 한 곳에서 묶는 기반 언어가 될 가능성이 크다고 본다.

특히 Tistory 위키에서 이어 온 agent 평가 흐름과 연결하면 Shepherd는 좋은 “다음 조각”이다. SWE-chat은 실제 커밋에 무엇이 남는지 물었고, Workspace-Bench는 작업공간 파일 관계를 얼마나 이해하는지 물었다. Shepherd는 그보다 앞단에서 실행 자체가 추적과 분기의 대상으로 남아야 한다고 말한다. 평가가 강해질수록 trace의 품질이 중요해지고, trace가 좋아질수록 supervisor와 optimizer가 더 구체적인 개입을 할 수 있다. 이 순환이 이번 논문의 실전적 가치다.

실제 개발팀 관점에서는 Shepherd가 제안하는 구조가 agent platform의 관측 단위를 바꿀 수 있다. 지금 많은 코딩 에이전트 도구는 session transcript와 최종 diff를 따로 저장한다. 이 둘 사이를 잇는 것은 사람이 남긴 메모, CI 로그, 간헐적인 screenshot 정도다. Shepherd 방식에서는 worker가 시도한 tool call, supervisor의 guidance, discard된 sibling branch, merge된 branch, 최종 patch가 같은 trace graph 안에 놓인다. 그러면 실패 분석은 “모델이 왜 틀렸나”라는 느슨한 질문에서 “어느 commit 이후의 suffix가 verifier 실패를 만들었나”라는 재현 가능한 질문으로 바뀐다.

또한 이 논문은 long-horizon agent 학습에서 환경 engineering이 reward design만큼 중요하다는 메시지를 준다. reward가 좋아도 중간 상태를 싸게 복제할 수 없으면 tree-style credit assignment는 실행 비용에 막힌다. 반대로 substrate가 branch를 싸게 열어 주면 같은 outcome reward에서도 더 많은 비교 신호를 만들 수 있다. 이는 모델 크기와 prompt 기법에 집중된 agent 연구가 앞으로는 runtime, sandbox, trace, cache 같은 시스템 계층을 함께 다뤄야 한다는 신호로 읽힌다.

마지막으로 Shepherd의 장점은 깔끔한 성공 경로보다 실패와 우회 경로를 남기는 데 있다. agent가 실전에서 가치 있으려면 한 번에 맞히는 능력뿐 아니라, 잘못된 branch를 버리고, 이전 상태로 돌아가고, 다른 worker나 사람에게 상태를 넘길 수 있어야 한다. Shepherd는 이 모든 행동을 ad-hoc script가 아니라 substrate primitive로 끌어내린다. 그 점에서 이 논문은 “에이전트가 무엇을 할 수 있는가”보다 “에이전트의 실행을 어떤 단위로 통제할 것인가”를 묻는 시스템 논문으로 읽는 편이 가장 정확하다.

후속 독자가 이 논문을 읽을 때는 세 실험의 headline 숫자만 따라가기보다, 각 숫자가 어떤 primitive와 연결되는지 표시해 두면 좋다. CooperBench의 상승은 observe와 handoff, CRO의 시간 절감은 replay와 cache reuse, Tree-GRPO의 성능 향상은 forked sibling rollout과 연결된다. 이렇게 primitive별로 읽으면 Shepherd가 단일 benchmark trick이 아니라 agent runtime 설계 원칙을 제안한다는 점이 더 분명해진다.

10. 요약 정리

• Shepherd는 meta-agent가 worker agent의 실행을 관찰, fork, replay, merge, discard할 수 있도록 설계한 runtime substrate다.
• 핵심 추상화는 task, effect, scope, execution trace이며, 함수형 프로그래밍의 effect handling과 persistent data structure 관점을 agent runtime에 적용한다.
• Shepherd는 filesystem과 worker state를 함께 fork하며, Terminal-Bench 2.0 이미지에서 134~143ms 수준의 fork latency를 보고한다.
• byte-identical replay는 provider prompt cache와 연결되어 Anthropic Haiku 4.5 기준 약 95% cache-hit plateau를 만든다.
• CooperBench live supervision에서는 coop baseline 28.8% pair pass rate를 Opus supervisor 조건 54.7%까지 끌어올린다.
• CRO는 candidate edit이 영향을 미치는 첫 commit에서 suffix만 replay해 HoVer, MATH, LiveCodeBench, TerminalBench 2.0 등에서 strong meta-optimization 결과를 보인다.
• Tree-GRPO는 중간 상태 sibling rollout으로 long-horizon terminal agent의 credit assignment를 개선해 Qwen3.5 기준 Terminal-Bench 2.0 avg@5를 34.2%에서 39.4%로 올린다.
• 논문의 한계는 substrate 효과와 meta-policy 효과가 완전히 분해되지 않았고, 강한 supervisor/proposer 비용과 irreversible side effect 관리가 실제 배포에서 별도 문제가 된다는 점이다.
• 후속으로는 transcript-only baseline과 Shepherd substrate를 직접 비교하는 substrate-only ablation, 사람 검수용 trace graph UI, worker가 fork/discard/replay를 직접 쓰는 post-training 연구가 중요해 보인다.