출처 https://youtu.be/19HDQ9HppOA · 채널 Claude (Anthropic) · 길이 00:37:09 포맷 “Code with Claude” 컨퍼런스의 핸즈온 워크숍. Anthropic Applied AI팀 Isabella He가 슬라이드로 Claude Managed Agents 아키텍처를 설명한 뒤, 청중과 함께 노트북으로 실습하며 Streamlit 기반 SRE(사이트 신뢰성) 인시던트 대응 에이전트를 라이브 코딩으로 완성한다. 원본 자막: raw/transcripts/2026-07-11-ship-your-first-managed-agent.en.srt

한눈에 보는 요약

  • Managed Agents는 “에이전트 인프라를 통째로 대신 맡아주는” 세 번째 진화 단계다. 2023년 Messages API(토큰 인·아웃만 제공) → Agent SDK(Claude Code 하네스를 라이브러리로 제공, 호스팅/스케일링은 직접) → Managed Agents(호스팅·스케일링·세션 영속성·인증까지 Anthropic이 처리, 개발자는 태스크+에이전트 설정과 커스텀 툴 로직만 신경 씀) 순으로 발전했다.
  • 핵심 설계는 “브레인과 손을 분리”한 것. 에이전트 루프(브레인)는 Anthropic 인프라에서 서버사이드로 돌고, 툴 실행(손)은 필요할 때만 샌드박스를 띄운다. 이 덕분에 크리덴셜이 에이전트에 직접 노출되지 않고, TTFT(첫 토큰까지 시간) p95 기준 90% 이상 줄었다.
  • 세 가지 핵심 리소스로 구성된다: /v1/agents(페르소나·모델·툴, 버전 고정), /v1/environments(컨테이너·네트워킹 허용 목록), /v1/sessions(에이전트+환경을 묶어 대화를 시작·재개·스트리밍).
  • 토큰 인·아웃이 아니라 “이벤트” 단위로 동작한다. 유저 메시지, 툴 콜, 에이전트 응답이 모두 이벤트로 세션 로그에 append되어, 클라이언트 연결이 끊겨도 세션이 서버에서 안전하게 지속되고 재개된다.
  • 실습으로 7개 함수만 채워 SRE 에이전트를 완성했다: 에이전트 정의 → 환경 생성 → 로그 파일 업로드(Files API) → 세션 시작 → 이벤트 스트리밍 → 로컬 툴 핸들러(get_metrics/get_recent_deploys/get_diff) → 세션 삭제. 이걸로 실제 인시던트(“checkout p99 레이턴시 10배 급등”)를 에이전트가 스스로 조사해 근본 원인(DB 커넥션 풀 고갈, 특정 커밋)까지 찾아냈다.
  • “베이스라인 그 다음”으로 9가지 베타 기능이 있다: Subagents, Memory, Outcomes(결과 루브릭), Vaults(자격증명 암호화 저장), MCP 서버, Webhooks, Permission policies, Interrupt, Console agent builder.

장면별 상세 설명

[00:10] 1. 세션 시작 — Applied AI팀 소개

장면 1 — 인트로 로고 애니메이션

발표자 Isabella He는 Anthropic Applied AI팀 소속으로, 이 팀은 제품·리서치·고객의 교차점에 있어 Claude Code나 사내 하네스에 기여하는 동시에 Claude와 하네스 위에 무언가를 만드는 외부 고객과도 함께 일한다고 소개한다. 오늘 세션의 목표는 참가자들이 실제로 Managed Agents 위에서 손을 놀려가며 만들어보고, 하네스가 내부적으로 어떻게 동작하는지 이해한 뒤, 첫 인시던트 대응 매니지드 에이전트를 배포할 준비를 갖추는 것이다.

[01:20] 2. 오늘의 아젠다 — 3부 구성

장면 2 — "What we'll cover" 아젠다 슬라이드

오늘 다룰 내용은 세 파트다.

1부 핵심 개념은 Managed Agents가 무엇인지, 서버사이드 루프와 세 가지 리소스를 빠르게 훑는다.

2부 핸즈온 워크숍은 agent.py 안의 여섯 개 함수를 채워 인시던트 조사 에이전트를 엔드투엔드로 만드는 실습이다.

3부 베이식을 넘어서는 vaults·subagents·memory·webhooks 등 상자 안에 더 들어있는 기능들과 다음에 갈 곳을 다룬다.

참고로 이 세션 바로 다음에는 “드리밍(dreaming)” — 자가개선 에이전트와 메모리를 다루는 세션이 이어진다고 예고한다.

[02:25] 3. 에이전트를 만드는 인터페이스의 진화 — Messages API → Agent SDK → Managed Agents

장면 3 — 세 인터페이스 비교 슬라이드

2023년 첫 Claude와 함께 나온 Messages API는 순수 모델 접근(토큰 인·아웃)만 제공했고, 에이전트 루프·컨텍스트 관리·툴 실행 런타임·세션 상태·호스팅/인증/관측성까지 전부 개발자가 직접 구현해야 했다. 당시엔 모델이 덜 똑똑해 에이전트가 할 수 있는 일도 적었기 때문에 이 primitive들이 비교적 단순했다.

모델이 더 복잡한 작업과 툴 콜을 처리하게 되면서 Agent SDK로 넘어갔다 — Claude Code(컴퓨터에 접근해 파일시스템에서 행동하는 에이전트)의 하네스를 라이브러리로 제공해, 에이전트 루프·컨텍스트 관리(캐싱·컴팩션)·툴 실행·재시도는 SDK가 맡지만, 호스팅과 스케일링, 컨테이너 안전성은 여전히 개발자 몫이었다.

그다음이 Claude Managed Agents — 호스팅·스케일링까지 Anthropic이 프로덕션 수준으로 처리하는 첫 하네스다. 목적에 맞게 설계된 하네스, 샌드박싱, 관측성, 툴 런타임, 세션 영속성·체크포인팅, OAuth+크리덴셜 볼트까지 전부 매니지드 인프라 안에 들어있어, 개발자는 “태스크 + 에이전트 설정”과 “커스텀 툴 로직(MCP/스킬)“만 제공하면 된다.

[04:55] 4. Managed Agents란 — “10~15배 빠르게 프로덕션으로”

장면 4 — "What are Managed Agents?" 슬라이드

Managed Agents는 “Claude를 Anthropic 매니지드 인프라 위에서 자율 에이전트로 돌리는 조합 가능한 API 세트”로 정의된다 — 개발자는 태스크·툴·가드레일을 정의하고, Anthropic이 루프·샌드박스·상태·스케일링을 처리한다. 실제로 이 방식으로 프로덕션까지 10~15배 빠르게 도달한 사례들이 관측됐다고 한다.

하네스를 이렇게 매니지드로 만든 이유 중 하나는 하네스가 모델과 함께 계속 진화해야 하기 때문이다. 예를 들어 Sonnet 4.5는 컨텍스트 윈도우에 여유가 있어도 태스크를 일찍 마무리해버리는 “컨텍스트 불안(context anxiety)” 행동을 보였고, 팀은 이를 완화하는 로직을 하네스에 추가했다. 그런데 Opus 4.5가 나오면서 이 행동 자체가 사라져, 애써 만든 완화 로직이 통째로 무의미해졌다. 하네스를 유지보수하는 데 이렇게 많은 공수가 드는데, Claude Managed Agents는 컴팩션·캐싱·컨텍스트 불안 같은 온갖 복잡함을 Anthropic이 대신 다뤄주기 때문에, 개발자는 정말 중요한 태스크·툴에만 집중할 수 있다는 게 요지다.

[06:05] 5. 세 가지 핵심 리소스 — agents / environments / sessions

장면 5 — "Three primary resources" 슬라이드

Managed Agents를 구성하는 세 리소스는 다음과 같다.

  • /v1/agents — 페르소나 + 역량. “에이전트가 무엇인지”를 정의하는 모델·시스템 프롬프트·툴·MCP 서버·스킬. 한 번 만들면 버전이 고정(immutable)되어 재사용된다. 발표자 표현으로는 에이전트의 브레인에 해당한다.
  • /v1/environments — 인프라 + 가드레일. 에이전트의 에 해당하며, 컨테이너 설정·네트워킹 허용 목록을 정의한다. 한 번 설정해두고 어디서든 재사용한다.
  • /v1/sessions — 대화를 실제로 시작하는 지점. 만들어둔 에이전트와 환경을 페어링해 상호작용 하나를 시작하고, 이벤트를 스트리밍으로 되돌려 받고, 언제든 재개할 수 있다.

[07:05] 6. 아키텍처 — 에이전트 루프는 서버사이드에서 돈다

장면 6 — "The agent loop runs server-side" 슬라이드

툴 콜·재시도·컨텍스트 관리 같은 오케스트레이션은 개발자의 클라이언트가 아니라 Anthropic 인프라 안에서 산다. 개발자는 이벤트를 보내고 이벤트를 스트리밍으로 받을 뿐이며, 클라이언트가 연결되어 있든 아니든 루프는 안정적으로 계속 돈다. 그래서 노트북을 덮거나 페이지를 하드 리프레시해도 durability·reliability를 신경 쓸 필요 없이 모든 게 유지된다 — 프로토타입을 프로덕션으로 옮길 때 발목을 잡는 요소들이 사라지는 것이다. (참고로 슬라이드에는 이 기능이 베타 헤더 managed-agents-2026-04-01로 활성화된다고 표기돼 있다.)

[07:50] 7. 핵심 설계 결정 — “브레인이 상자를 빠져나갔다”

장면 7 — "The brain left the box" 비포/애프터 다이어그램

이전의 많은 에이전트 하네스는 에이전트 루프와 툴 실행을 같은 박스 안에 강하게 결합시켰다 — Claude Code처럼 파일시스템에 직접 접근해야 하는 에이전트에는 여전히 합리적인 패턴이지만, 몇 가지 제약이 있었다. 첫째는 크리덴셜·보안 — 브레인과 손을 분리하면 에이전트가 암호화 없이 크리덴셜에 직접 접근하지 못하도록 확실한 샌드박싱이 가능해진다. 둘째는 레이턴시 — 예전엔 세션마다 컨테이너를 새로 띄워야 해서 TTFT(첫 토큰까지 시간)에 지연이 붙었지만, 분리 이후 P95 TTFT가 90% 이상 줄었다.

슬라이드는 이를 “Before: 한 컨테이너에 에이전트 루프+툴 실행이 같이 갇혀 있음” → “Now: 브레인(에이전트 루프, Anthropic 매니지드, 하나의 서비스가 수천 세션을 처리하며 크래시에도 살아남음)과 손(샌드박스, 툴이 실제로 필요할 때만 온디맨드로 뜸)이 분리됨”으로 도식화한다.

[09:15] 8. 실습 시작 — “Part two: Hands-on workshop”

장면 8 — 실습 링크 안내 슬라이드

여기서부터 청중은 노트북을 열고 https://cwc26.short.gy/workshops 링크로 이동해 저장소를 클론한다. 발표자는 이후 30분 가까이 슬라이드가 아니라 실제 코드와 화면 공유로 라이브 코딩을 진행한다.

[10:20] 9. 셋업 커맨드 — 저장소 클론부터 앱 실행까지

장면 9 — 셋업 커맨드가 적힌 Google Docs

화면에 공유된 실제 커맨드는 다음과 같다.

git clone https://github.com/anthropics/cwc-workshops
cd cwc-workshops/ship-your-first-managed-agent
 
python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
 
pip install -r requirements.txt
cp .env.example .env           # then put your ANTHROPIC_API_KEY in .env
streamlit run app.py

streamlit run app.py를 실행하면 로컬에 Streamlit 앱이 뜬다. 이 앱은 “인시던트 대응”을 시뮬레이션한다 — 온콜 개발자가 새벽 2~3시에 서버 장애로 깨어나 메트릭·로그·배포 이력을 뒤지는 그 고통스러운 경험을, 이제 Claude Managed Agents 위의 에이전트가 대신 조사하게 만드는 것이 오늘 실습의 목표다. 왼쪽에는 미완성 agent.py, 오른쪽에는 정답이 담긴 agent_complete.py를 열어두고, 완성본에서 조금씩 복사해오며 각 primitive가 에이전트를 어떻게 조립하는지 하나씩 확인하는 방식으로 진행한다.

[14:15] 10. Step 1~2 — 에이전트 정의와 환경 생성

장면 10 — agent.py / agent_complete.py 코드 비교

첫 번째로 채우는 setup_agent()는 에이전트의 페르소나+역량을 정의한다 — 모델(claude-opus-4-7), 시스템 프롬프트, 툴(get_metrics/get_recent_deploys/get_diff 등)을 지정해 client.beta.agents.create(...)로 만들고 agent.id를 반환한다. 시스템 프롬프트 자체는 “너는 인시던트를 디버깅하는 SRE 에이전트이고, 메트릭·최근 배포·diff 같은 툴에 접근할 수 있다”는 정도로 의외로 단순하다.

@st.cache_resource
def setup_agent() -> str:
    agent = client.beta.agents.create(
        name="SRE Agent", model="claude-opus-4-7", system=SYSTEM, tools=TOOLS,
    )
    return agent.id

두 번째 setup_environment()는 에이전트가 실제로 일할 손(환경) 을 정의한다 — Anthropic 클라우드에서 도는 컨테이너 타입과 네트워킹 허용 범위를 지정한다. 이 워크숍에서는 데모 편의상 네트워킹을 unrestricted로 열어뒀지만, 실제로는 이 목록이 화이트리스트라서 특정 사이트·URL로만 제한할 수 있다고 강조한다. 발표 하루 전 “Code with Claude London”에서 막 발표된 직접 컨테이너·컴퓨트를 가져와 매니지드 에이전트를 자기 인프라 안에서 돌리는 기능과, 퍼블릭 네트워크 대신 프라이빗 환경에서 MCP 서버를 돌리는 Cloud MCP 터널 기능도 함께 언급된다.

@st.cache_resource
def setup_environment() -> str:
    env = client.beta.environments.create(
        name=f"sre-agent-{uuid.uuid4().hex[:6]}",
        config={"type": "cloud", "networking": {"type": "unrestricted"}},
    )
    return env.id

[15:25] 11. Step 3~5 — 로그 업로드, 세션 생성, 이벤트 스트리밍

장면 11 — 나머지 함수 코드(upload_log/start_session/stream_reply)

세 번째 upload_log()Files APIapp.log를 에이전트에 업로드한다 — Claude Code가 파일시스템 접근으로 힘을 얻었듯, 여기서는 메트릭·로그 파일을 에이전트에 붙여줘서 코드를 실행하고 그 파일들을 처리하게 만드는 것이다. 발표자는 “에이전트에게 최대한 많은 데이터를 줄수록 강력해진다”며, 어떤 파일을 올리고 에이전트가 그걸 어떻게 처리하게 할지 같은 컨텍스트 엔지니어링이 Managed Agents 위에서 개발자가 시간을 가장 많이 쓰는 지점이라고 짚는다.

@st.cache_resource
def upload_log() -> str:
    with open(DATA / "app.log", "rb") as f:
        return client.beta.files.upload(file=f).id

네 번째 start_session()은 에이전트+환경을 묶고 로그 파일을 리소스로 마운트해 세션을 연다 — 에이전트 ID, 환경 ID, 리소스(로그 파일)를 넘겨 실제로 유저와 상호작용을 시작할 수 있게 만드는 지점이다.

def start_session(agent_id: str, env_id: str, log_file_id: str) -> str:
    session = client.beta.sessions.create(
        agent=agent_id,
        environment_id=env_id,
        resources=[{"type": "file", "file_id": log_file_id, "mount_path": "app.log"}],
    )
    return session.id

다섯 번째 stream_reply()가 이벤트 스트리밍을 구현한다. 매니지드 에이전트 세션은 토큰 인·아웃이 아니라 이벤트 단위로 동작한다 — 유저 메시지, 툴 콜, 에이전트 응답 같은 이벤트가 세션에 스트리밍으로 오가며, 각 이벤트가 관측성 관점에서 로깅되는 동시에 유저에게도 실시간으로 보인다. 이는 유저 경험(토큰이 뭉텅이로 끝날 때가 아니라 오는 대로 보임) 뿐 아니라 관측성 측면에서도 중요하며, Managed Agents는 에이전트가 하는 모든 일을 들여다보는 콘솔을 기본 제공한다.

def stream_reply(session_id: str, user_text: str):
    with client.beta.sessions.events.stream(session_id) as stream:
        client.beta.sessions.events.send(
            session_id,
            events=[{"type": "user.message", "content": [{"type": "text", "text": user_text}]}],
        )
        for ev in stream:
            if ev.type == "agent.custom_tool_use":
                result = handle_tool(ev.name, ev.input)
                client.beta.sessions.events.send(session_id, events=[...])

이후 남은 두 함수(6. 로컬 툴 핸들러 — get_metrics/get_recent_deploys/get_diff를 실제 로컬 JSON 데이터에 연결, 7. 세션 삭제 — 보안상 원치 않는 세션 데이터를 능동적으로 지우는 기능)까지 마저 채우면, 에이전트가 “hi”에는 답하지만 아직 툴을 부를 수 없는 상태에서 → 실제로 get_metrics/get_recent_deploys/get_diff를 호출하며 조사하는 상태로 완성된다.

[19:25] 12. 첫 테스트 — “hi”에는 답하지만 아직 툴이 없다

장면 12 — Streamlit 앱의 INCIDENT-2277 화면과 "hi" 테스트

완성된 앱 화면은 왼쪽에 인시던트 대시보드(INCIDENT-2277, checkout 서비스 P99 레이턴시가 베이스라인 대비 10배, 에러율 21.9%, DB 풀 100%, 28분째 진행 중), 오른쪽에 SRE 에이전트 채팅 패널로 구성된다. 로컬 툴 연결 전 “hi”라고 보내면 에이전트는 인사에 답하며 “서비스 메트릭 조사, 최근 배포 확인, 로그에서 에러 검색, 스파이크와 코드 변경 상관관계 분석” 같은 걸 도울 수 있다고 스스로 소개하지만, 아직 실제 로컬 툴이 연결되지 않아 진짜 조사는 하지 못하는 상태다.

[24:05] 13. 라이브 데모 — 에이전트가 툴을 연쇄 호출하며 조사한다

장면 13 — sandbox·bash, local·get_diff, local·get_metrics 툴 콜 체인

로컬 툴까지 연결한 뒤 “debug my incident for me”라고 프롬프트를 보내자, 에이전트가 sandbox·bash로 로그를 들여다보고, local·get_recent_deploys로 최근 배포를 확인하고, local·get_metrics를 여러 차례, local·get_diff로 코드 변경사항까지 순서대로 호출하는 모습이 실시간 스트리밍으로 화면에 쌓인다. (라이브 데모 중 첫 시도는 실패했다가 재시도에서 성공하는 해프닝이 있었다.) 결국 에이전트는 원인을 DB 커넥션 풀 고갈로 지목하고, Alice가 주문 요약(order summary) 빌더를 리팩터링하며 추가한 쿼리가 풀 자원을 고갈시켰다고 콕 집어낸 뒤, 다른 가능성들은 배제하고 권장 조치까지 제시한다. 발표자는 여기에 Claude Code 같은 툴 접근 권한을 더 주면 에이전트가 코드베이스에 들어가 수정안을 제안하고 PR까지 올리는 것도 가능하다고 짚으며, 사람은 그 위에서 “감독”만 하는 그림으로 확장될 수 있다고 말한다.

[26:15] 14. 세션 영속성과 상태 — 새로고침해도 사라지지 않는다

장면 14 — 세션 드롭다운에 쌓인 여러 idle 세션들

페이지를 하드 리프레시해도 이전에 실행한 세션들이 전부 클라우드에 그대로 남아있다 — 데이터베이스를 직접 관리하거나 에이전트를 어디에 저장할지 배선할 필요 없이, 서버사이드에 이미 다 유지되는 것이다. 세션 삭제 버튼을 누르면 해당 세션은 로그 전체에서도 함께 지워져, 원치 않는 세션 데이터를 능동적으로 관리할 수 있다. 세션은 idle → running → rescheduling(재시도 필요 시) → terminated(실패 시) 상태를 오가며 관리되는데, 이 상태 기반 설계 덕분에 예컨대 웹훅으로 외부 이벤트가 들어오면 그걸 받아 세션을 재개하거나 특정 상태를 트리거하는 식의 강력한 활용도 가능해진다.

[33:25] 15. 베이식을 넘어서 — 9가지 확장 기능

장면 15 — "Beyond the basics" 3x3 기능 그리드

오늘 만든 건 Managed Agents의 아주 기본적인 형태였다는 걸 강조하며, 더 강력하게 만들 수 있는 베타 기능 9가지를 소개한다.

  • Subagentscallable_agents. 오케스트레이터 에이전트가 다른 에이전트를 스폰·조율해 각자의 컨텍스트 윈도우로 병렬 처리.
  • Memory — 컨테이너에 마운트되는 영속적 에이전트 메모리. 유저 교정이나 선호를 기억해 자가개선 에이전트를 만드는 데 쓰인다.
  • Outcomes — 이벤트와 별개로 존재하는, 에이전트가 만들어낸 결과물의 구조화된 아티팩트. “좋은 결과”의 루브릭을 주고 그걸 달성할 때까지 시도 횟수를 함께 정할 수 있다.
  • Vaultsvault_ids로 참조하는, 한 번 등록해두는 유저별 크리덴셜. 브레인·손 분리 아키텍처 덕분에 크리덴셜이 별도 엔드포인트에 암호화 저장된다.
  • MCP serversmcp_toolsetentries를 통해 원격 툴 서버를 붙임.
  • Webhooks — 콘솔 Settings → Webhooks에서 설정. session.status.idled 같은 이벤트에 반응해 발동.
  • Permission policies — 툴에 always_ask를 걸면 user.tool_confirmation을 기다리며 루프가 멈춘다.
  • Interrupt — 실행 중간에 인터럽트를 보내 에이전트를 강제로 idle 상태로 되돌림.
  • Console agent builder — API로 내려가기 전에 콘솔에서 대화형으로 에이전트 설정을 반복 개선.

마지막으로 발표자는 오늘 세션에서 실제로 SRE 에이전트를 완성한 참가자들을 축하하며, 이 정도의 인프라(컴팩션·캐싱·툴 콜링 등)를 처음부터 직접 구축하려면 훨씬 오래 걸렸을 거라는 점, 그리고 subagents·memory·outcomes 같은 추가 기능으로 에이전트를 훨씬 강력하게 만들 수 있다는 점을 강조하며 세션을 마무리한다.

핵심 개념·용어 메모

  • 세 가지 리소스/v1/agents(브레인: 페르소나+역량, immutable), /v1/environments(손: 컨테이너+네트워킹, 재사용 가능), /v1/sessions(둘을 묶어 대화 시작·재개).
  • 브레인/손 분리 아키텍처 — 에이전트 루프(Anthropic 매니지드, 세션 수천 개를 하나의 서비스가 처리, 크래시에도 생존)와 툴 실행(온디맨드 샌드박스)을 분리 — 보안(크리덴셜 비노출)과 레이턴시(TTFT P95 90%+ 감소) 두 마리 토끼.
  • 이벤트 기반 세션 — 토큰 인·아웃이 아니라 user.message / agent.custom_tool_use 같은 이벤트가 세션 로그에 append됨. 클라이언트 연결 여부와 무관하게 루프가 안정적으로 지속.
  • 세션 상태 머신 — idle → running → rescheduling → terminated.
  • 컨텍스트 불안(context anxiety) — Sonnet 4.5가 컨텍스트에 여유가 있어도 일찍 태스크를 마무리하던 현상. Opus 4.5에서 자연 해소되어, 하네스에 넣었던 완화 로직이 무의미해진 사례로 언급됨 — “하네스는 모델과 함께 계속 진화해야 한다”는 근거로 제시.
  • 7개 함수로 완성하는 SRE 에이전트 — setup_agent → setup_environment → upload_log(Files API) → start_session → stream_reply(이벤트 스트리밍) → 로컬 툴 핸들러(get_metrics/get_recent_deploys/get_diff) → 세션 삭제.
  • Beyond the basics 9종 — Subagents(callable_agents), Memory, Outcomes, Vaults(vault_ids), MCP servers(mcp_toolsetentries), Webhooks(session.status.idled), Permission policies(always_ask/user.tool_confirmation), Interrupt, Console agent builder.

등장한 사람·조직·키워드

Isabella He(Anthropic Applied AI팀), Anthropic, Claude Managed Agents, Claude Code, Agent SDK, Messages API, Streamlit, Code with Claude(컨퍼런스), github.com/anthropics/cwc-workshops(워크숍 저장소), Sonnet 4.5, Opus 4.5/4.7, Files API, MCP.

원문 인용 모음

  • [00:00] “My goal today is to get you all hands-on with actually building on top of manage agents… getting you ready to actually ship your first incident response management.”
  • [03:30] “That’s only then evolved into Claude managed agents, which is the first harness to be able to handle scaling and production ready components for you by Anthropic.”

관련 노트

  • 2026-07-10-agent-battle-mine-most-diamonds — 같은 컨퍼런스, 같은 Managed Agent 기반의 라이브 대회
  • 2026-07-10-agents-that-remember — 바로 다음 세션, Managed Agents 메모리(Memory Store·Dreaming) 심화
  • 2026-07-11-building-the-future-of-agentic-infrastructure — 같은 컨퍼런스, Managed Agents/하네스 철학 좌담
  • 2026-07-10-how-we-claude-code — 같은 컨퍼런스, Claude Code 자체의 하네스·검증 워크숍
  • [04:40] “We’ve seen people build 10 to 15 times faster to production with Claude managed agents by leveraging our purpose-built harness.”
  • [05:00] “Harnesses should evolve alongside your agents… Sonnet 4.5 emitted a particular behavior called context anxiety… when Opus 4.5 then came out, we actually saw this behavior go away, making all that work we had done inside of the harness essentially obsolete.”
  • [06:20] “A key thing here… Claude managed agent has the agent loop run server side… you don’t have to worry about durability, reliability.”
  • [08:10] “With this now decoupled, our teams actually saw reductions in time to first token along the lines of over 90% reduction in TTFT for our P95 metrics.”
  • [11:00] “If you are software engineer, you might be woken up at, let’s say, 3:00 a.m… we can hand it off to an agent, or maybe we don’t even get woken up at all if Claude is able to do everything for us.”
  • [17:20] “When our Cloud Managed Agents runs within a single session, instead of responding in tokens in and tokens out, it actually works in units of events.”
  • [24:15] “It says that this seems to be caused by a database pool exhaustion. Seems like a commit that someone added here from Alice to refactor the order summary builder introduced a query that then caused the pool resources to be exhausted.”
  • [31:05] “We went from idle to running, rescheduling if the agent needs to retry anything, or terminated if any of the sessions fail.”
  • [34:00] “Outcomes is another one of my favorites… you can define a rubric of exactly what you want the agent to produce, and it’ll figure out along the way which tool calls… it needs to do to execute towards that final result.”