Managed agents

Managed agents는 LLM agent를 한 컴퓨터 안에 붙잡아두는 대신, 모델·실행 환경·작업 기록을 분리된 인터페이스로 다루는 장기 실행 agent 구조입니다. Anthropic은 Claude Managed Agents를 설명하면서 이를 “brain”과 “hands”를 분리하는 방식으로 표현했습니다. 여기서 brain은 모델과 harness, hands는 sandbox와 외부 도구, session은 작업 기록입니다.

핵심은 agent를 더 오래 돌리는 것이 아닙니다. 오래 돌릴수록 더 자주 생기는 실패—컨테이너 장애, 긴 문맥 손실, 권한 노출, 도구 실행 실패, 여러 실행 환경 연결—를 견디도록 agent runtime을 설계하는 것입니다.

한 줄로 말하면

Managed agents는 agent의 두뇌, 손, 기억을 분리해 장기 작업을 더 안정적이고 안전하게 실행하려는 agent runtime 설계 방식입니다.

비유로 이해하기

초기 agent 시스템을 한 명의 작업자가 모든 것을 들고 다니는 노트북으로 생각해볼 수 있습니다. 그 노트북 안에는 작업 지시서, 실행 도구, 비밀번호, 작업 파일, 기록이 모두 들어 있습니다. 빠르게 시작하기는 쉽지만, 노트북이 멈추면 작업도 멈추고 기록도 사라지며, 위험한 파일을 열었을 때 비밀번호까지 노출될 수 있습니다.

Managed agents는 이를 회사의 업무 시스템처럼 나눕니다.

• 작업자는 필요할 때마다 도구실에 요청합니다.
• 작업 기록은 별도 문서함에 남습니다.
• 권한 정보는 금고에 있고, 작업자는 직접 보지 못합니다.
• 한 도구실이 망가지면 다른 도구실로 다시 시작할 수 있습니다.

비유의 한계도 있습니다. 실제 agent runtime에서는 “작업자”도 하나의 고정된 사람이 아닙니다. harness가 실패하면 다른 harness가 session log를 읽고 이어받을 수 있고, sandbox도 필요할 때만 새로 만들어질 수 있습니다.

정확한 정의

Managed agents는 장기 작업을 수행하는 LLM agent에서 다음 세 요소를 안정된 인터페이스로 분리하는 구조입니다.

요소	역할	왜 분리하나
Brain	모델과 harness가 다음 행동을 결정하는 층	모델과 orchestration을 sandbox 장애에서 분리하기 위해
Hands	코드 실행, 파일 편집, 외부 도구 호출 같은 실제 행동 층	untrusted code와 credential을 같은 공간에 두지 않기 위해
Session	작업 중 발생한 event log와 장기 작업 기록	harness나 sandbox가 죽어도 이어서 복구하기 위해

Anthropic의 글에서 중요한 설계는 session log가 harness 밖에 있다는 점입니다. harness가 실패해도 새 harness가 wake(sessionId)처럼 session을 다시 읽고 이어받을 수 있습니다. sandbox도 brain 안에 붙어 있지 않고 execute(name, input)처럼 도구 호출 인터페이스로 다뤄집니다.

이 구조는 Loop engineering과 맞닿아 있습니다. loop engineering이 “agent를 반복 실행 시스템으로 보자”는 관점이라면, managed agents는 그 반복 실행 시스템을 오래 돌릴 때 필요한 분리·복구·권한 경계를 더 명시적으로 다룹니다.

왜 중요한가

1. 긴 작업은 한 컨테이너에 모두 넣기 어렵다

agent가 단순히 짧은 답변을 만드는 단계라면 하나의 실행 환경에 모델 호출, 파일, 도구를 모두 묶어도 큰 문제가 없어 보입니다. 하지만 코드 수정, 리서치, 배포 준비, 여러 시스템 연결처럼 긴 작업으로 가면 상황이 달라집니다.

컨테이너가 멈추면 session이 사라질 수 있고, 디버깅을 위해 컨테이너 안에 들어가야 할 수도 있습니다. 그 컨테이너가 사용자 데이터와 credential을 함께 들고 있다면 운영자도 안전하게 들여다보기 어렵습니다. Managed agents는 이 문제를 “pet server”가 아니라 교체 가능한 구성요소로 바꾸려 합니다.

2. 권한과 보안 경계를 runtime 구조로 만든다

가장 중요한 보안 포인트는 모델이 실행하는 코드와 credential을 같은 공간에 두지 않는 것입니다. Anthropic은 Git credential이나 OAuth token을 sandbox 안에서 모델이 직접 읽을 수 있게 두는 대신, repository clone이나 MCP proxy, vault 같은 구조로 감싼다고 설명합니다.

이 차이는 작아 보이지만 큽니다. prompt injection이 agent를 속여 환경변수를 읽게 만들 수 있다면 좁은 권한 토큰도 위험해집니다. 반대로 token이 sandbox 밖에 있고 tool proxy가 필요한 호출만 대신 수행한다면, agent가 생성한 untrusted code가 credential을 직접 훔치기 어려워집니다.

3. session은 context window와 다르다

LLM의 context window는 지금 모델이 보고 있는 작업대입니다. session log는 작업이 지나간 기록 보관소입니다. 긴 작업에서는 이 둘을 구분해야 합니다.

Context compaction이나 memory 요약은 유용하지만, 무엇을 버리고 무엇을 남길지 결정하는 순간 정보 손실이 생길 수 있습니다. Managed agents의 session log는 이벤트 원본을 더 오래 보존하고, harness가 필요한 조각을 다시 골라 context window에 넣는 구조에 가깝습니다. 이 지점은 Agent memory consolidation의 위험과도 연결됩니다. 기억을 요약해 쓰더라도 원래 사건 기록으로 돌아갈 수 있어야 불확실성과 출처를 잃지 않습니다.

4. 지연 시간과 확장성도 바뀐다

Brain과 hands를 분리하면 sandbox가 필요 없는 작업은 sandbox를 기다리지 않고 시작할 수 있습니다. Anthropic은 이 구조로 time-to-first-token이 크게 줄었다고 설명합니다. 핵심은 모든 session이 시작할 때 컨테이너를 먼저 준비하는 것이 아니라, brain이 필요할 때 hands를 도구처럼 호출한다는 점입니다.

이는 제품 관점에서도 중요합니다. agent service가 느린 이유가 모델 자체가 아니라 sandbox provisioning, repository clone, event fetch, credential wiring이라면, runtime 구조가 사용자 경험을 결정합니다.

실제 예시

예를 들어 코딩 agent가 repository를 수정한다고 해봅니다.

단순 구조에서는 agent harness, git credential, repository checkout, shell, session log가 한 컨테이너 안에 있을 수 있습니다. 이 경우 컨테이너가 멈추면 agent는 어디까지 했는지 잃고, prompt injection이 credential을 읽을 가능성도 커집니다.

Managed agents식 구조에서는 다음처럼 나뉩니다.

1. Session log가 “사용자가 요청했다 → repo를 열었다 → 테스트가 실패했다 → 수정했다” 같은 event를 저장합니다.
2. Brain은 이 log를 읽고 다음 행동을 고릅니다.
3. Sandbox는 필요한 순간에만 tool call처럼 실행됩니다.
4. Git credential은 sandbox가 직접 들고 있지 않고, 필요한 작업을 수행하는 별도 권한 경로로 연결됩니다.
5. Harness가 죽으면 새 harness가 session log를 읽고 이어갑니다.

이렇게 하면 agent는 더 복잡해지지만, 실패했을 때 재시작하고 설명하고 격리하기 쉬워집니다.

투자·산업 관점에서 보는 법

AI agent 제품을 볼 때 “어떤 모델을 쓰는가”만으로는 충분하지 않습니다. 실제 장기 업무에 들어가려면 모델 주변의 runtime이 중요합니다.

볼 질문은 다음과 같습니다.

• session log가 durable하게 남는가
• sandbox와 credential이 분리되어 있는가
• agent가 여러 실행 환경을 다룰 수 있는가
• 실패한 harness나 sandbox를 교체할 수 있는가
• context 관리와 원본 event 보존이 분리되어 있는가
• 감사 가능성을 위해 어떤 입력·권한·tool call 기록이 남는가

이런 요소는 데모 화면에서는 잘 보이지 않지만, enterprise agent adoption에서는 실제 병목이 될 수 있습니다. 모델 성능이 충분히 올라갈수록 경쟁은 “agent가 할 수 있는가”에서 “안전하게 오래 맡길 수 있는가”로 이동합니다.

헷갈리지 말아야 할 점

Managed agents는 “agent를 완전히 자율적으로 풀어놓자”는 뜻이 아닙니다. 오히려 장기 실행 agent를 더 잘 통제하기 위해 session, sandbox, credential, harness의 경계를 분리하는 설계에 가깝습니다.

또한 session log가 있다고 해서 memory 문제가 자동으로 해결되는 것도 아닙니다. session은 원본 기록을 보존하는 데 도움이 되지만, 모델에게 어떤 조각을 보여줄지 고르는 context management는 여전히 어렵습니다. 잘못 요약하거나 오래된 기록을 확정 사실처럼 쓰면 Agent memory consolidation의 문제가 다시 생깁니다.

마지막으로 managed agents는 특정 회사 제품명으로만 보면 좁게 보입니다. 더 넓게는 장기 실행 AI agent를 제품화하기 위한 runtime architecture의 한 방향으로 읽는 편이 좋습니다.

관련 문서

• Loop engineering
• Agent containment
• Agent memory consolidation
• AI 시스템의 감사 가능성
• Agent observability
• Agent memory의 epistemic status
• 모델 아키텍처와 Agent Memory의 차이
• AI agent runtime과 AI capex cycle의 차이