■ 에이전트 상태·실패·배포

상태와 실패 : 실패하면 처음부터 재시작하지 않는다. 멈춘 곳에서 재개한다. 재시작은 비싸고 사용자를 짜증나게 한다 [1.4③]

결정론적 안전장치(재시도 로직 · 정기 체크포인트)와 모델 지능(도구 실패를 모델에 알려 적응시키는 것)을 함께 쓴다

도구 오류는 불투명한 코드·traceback 이 아니라, 구체적으로 고칠 점을 알려 주는 메시지로 준다. 자세한 것은 ■ 도구 설계 에 있다

subagent 실패를 "성공 + 빈 결과" 로 삼키지 않는다. orchestrator 가 반응하도록 세 가지를 돌려준다

• 오류 종류
• 재시도 가능 여부
• 모은 부분 결과

필드 구성은 이 카드의 해석이다. 공식은 도구 실패를 모델에 알리고, 오류 메시지를 구체적으로 쓰라는 것이다

재시도 : 공식 SDK 는 일시 오류(연결·429·5xx)를 지수 백오프로 기본 2번 자동 재시도한다(max_retries 로 조정한다). 단 월 지출 한도 429 는 retry-after 없이 계속 실패한다. 자세한 것은 ■ rate limit 에 있다

재개 수단 (Agent SDK 세션)은 셋이다

• continue : 가장 최근 세션을 잇는다
• resume : 세션 ID 로 잇는다
• fork : 원본은 두고 갈래를 새로 만든다

max_turns·예산 한도로 끝난 실행도 한도를 올려 resume 한다

세션은 대화만 저장한다. 파일시스템은 저장하지 않는다. 그래서 파일은 file checkpointing 으로 다룬다

다른 호스트면 SessionStore 로 transcript 를 복제한다. 또는 결과(분석·결정·diff)를 앱 상태로 저장해 새 세션 프롬프트에 넣는다. 뒤쪽이 흔히 더 튼튼하다

Managed Agents : 세션이 대화 기록·샌드박스 상태·산출물을 서버에 저장한다. 그래서 멈춘 뒤 깨끗이 재개한다

긴 작업 : 끝난 단계는 요약해 외부 메모리에 둔다. 컨텍스트 창이 차면 새 서브에이전트로 넘기고, 계획은 메모리에서 되찾는다

새 컨텍스트 창에서는 progress 파일과 git 로그로 상태를 되찾는다. git 은 되돌릴 체크포인트다

디버깅 : 같은 프롬프트도 실행마다 결정이 다르다. 그래서 프로덕션 전체를 트레이싱한다. 대화 내용이 아니라 결정 패턴과 상호작용 구조를 관측한다. 자세한 것은 ■ observability 세 신호 · ■ 텔레메트리 기록 범위 에 있다

동기 vs 비동기 : 동기는 subagent 묶음이 다 끝날 때까지 기다린다. 조율은 쉽다. 대신 세 가지 문제가 있다 [1.4③]

• orchestrator 가 도중에 subagent 의 방향을 못 튼다
• subagent 끼리 조율하지 못한다
• subagent 하나 때문에 전체가 막힌다

비동기는 동시에 작업하고, 필요할 때 새 subagent 를 만든다. 그래서 병렬성이 오른다. 대신 결과 조율·상태 일관성·subagent 간 오류 전파가 어렵다

연구 글(2025)은 동기로 운영한다. 모델이 더 긴 일을 하게 되면, 비동기의 이득이 그 복잡도를 넘을 것으로 본다

병렬이면 독립 작업은 합이 아니라 가장 느린 것의 시간에 끝난다

Agent SDK 서브에이전트는 기본이 백그라운드다. 결과가 먼저 필요하면 Claude 가 run_in_background: false 로 둔다 (2026-09-28 조회)

Managed Agents 세션 상태는 모든 스레드를 모은 값이다. 하나라도 running 이면 running 이다

배포 : 에이전트는 거의 쉬지 않고 도는 상태 있는 연결망이다(프롬프트·도구·실행 로직이 얽혀 있다). 배포 순간에 에이전트가 과정 어디에든 있을 수 있다. 그래서 모두를 한꺼번에 새 버전으로 바꾸지 못한다 [1.4③]

rainbow deployment 는 구버전·신버전을 함께 돌리며 트래픽을 조금씩 옮긴다

Managed Agents : 코디네이터 명단은 만들거나 업데이트할 때 스냅샷으로 저장된다. 참조 에이전트는 스냅샷 버전에 고정된다. 그래서 새 버전에 위임(delegation)하려면 코디네이터를 업데이트한다