Claude Managed Agents 동적 워크플로, 에이전트 최대 1,000개를 어떻게 돌리나?

동적 워크플로(dynamic workflows)는 2026년 10월 9일 Claude Managed Agents에 베타로 추가된 기능이다. 세션이 돌리는 에이전트가 워크플로, 곧 여러 에이전트를 단계별로 돌리고 결과를 합치는 프로그램을 짜면, 서버가 이 프로그램을 워크플로 실행으로 백그라운드에서 돌린다 ^[1].

켜는 곳은 에이전트의 multiagent 블록이고 타입은 multiagent_20261001이다. 각 실행의 진행 상황은 세션 스트림에 오는 workflow_run.* 이벤트로 지켜본다 ^[1].

10월 9일에 무엇이 바뀌었나?

Claude Managed Agents에는 원래 일을 위임하는 방법이 있었다. 이번에는 에이전트가 프로그램을 짜서 일을 넘기는 방법이 더해졌다. 릴리스 노트는 문서 수백 건을 검토하는 작업을 쓰임새로 든다. 켜려면 에이전트의 multiagent 필드를 {"type": "multiagent_20261001", "workflows": {"type": "enabled"}}로 정하고 managed-agents-2026-04-01 베타 헤더를 보낸다 ^[1].

기능 자체는 Claude Code에서 먼저 나왔다. Anthropic은 2026년 5월 28일 Claude Code에 동적 워크플로를 소개했고, 그 글에는 지금 Claude Code에서 정식 출시 상태라고 적혀 있다 ^[5]. 새로 생긴 것은 API로 다루는 호스팅 버전이다. Managed Agents에서는 애플리케이션이 제어하는 세션 안에서 서버가 워크플로를 돌린다.

multiagent_20261001 타입은 세 가지 옵션을 한 블록에 모았다. 서브에이전트와 동적 워크플로는 기본으로 켜져 있고, 어드바이저는 꺼져 있다 ^[2].

예전 coordinator 타입도 목록에 올린 서브에이전트에게 일을 맡기고 어드바이저에게 조언을 구할 수 있다. 하지만 워크플로 실행을 시작하거나 서브에이전트를 스스로 정의하지는 못한다. API는 두 타입을 모두 받는다 ^[2].

워크플로 실행은 어떻게 동작하나?

워크플로 실행은 에이전트가 짠 프로그램을 한 번 돌린 것이다. 실행은 백그라운드에서 돌고, 그동안 에이전트는 하던 일을 계속하거나 턴을 끝낸다 ^[3]. 프로그램은 작업을 이름 붙은 단계로 나누고, 여러 에이전트를 동시에 돌리고, 한 에이전트의 결과를 다른 에이전트에게 넘길 수 있다. 검토를 통과할 때까지 한 단계를 되풀이하거나, 에이전트가 실패했을 때 어떻게 할지 정할 수도 있다. 에이전트는 저마다 자기 세션 스레드에서 일하고, 모두 세션의 샌드박스와 파일을 함께 쓴다.

서브에이전트와 다른 점은 누가 조율하느냐다. 서브에이전트 방식에서는 에이전트가 다음 단계를 하나하나 정하고, 서브에이전트의 스레드는 후속 메시지를 받을 수 있게 열려 있다. 동적 워크플로에서는 Claude가 직접 끼지 않고 프로그램이 에이전트 사이에 맥락과 결과를 넘긴다. 덕분에 메인 스레드는 사용자와 계속 대화할 수 있다. 대신 에이전트는 실행의 스레드에 후속 메시지를 보낼 수 없고, 서버는 실행이 끝날 때까지 각 스레드를 보관 처리(archive)한다 ^[2].

실행에 참여하는 에이전트는 두 종류다. 인라인 에이전트는 워크플로가 정의한다. 워크플로가 에이전트마다 시스템 프롬프트를 쓰고, 모델은 세션 에이전트의 모델을 그대로 쓴다. 사전 정의 에이전트는 사용자가 직접 만들어 workflows.predefined_agents에 올린 에이전트로, 최대 20개까지 올릴 수 있고 에이전트마다 모델과 툴, MCP 서버를 따로 둔다 ^[2]. 작업을 여러 갈래로 나누는 부분에 더 싼 모델을 쓰고 싶다면, 그 모델로 에이전트를 만들어 목록에 올리면 된다.

실행은 세션의 기본 스레드에 있는 에이전트만 시작할 수 있다. 그래서 실행 안에서 또 실행을 만들 수는 없다. 사용자가 보내는 어떤 이벤트로도 실행을 끝낼 수 없지만, 세션을 보관 처리하면 실행이 끝날 수 있다 ^[3].

동적 워크플로는 어떻게 켜나?

에이전트 정의에서 워크플로를 켜고, 언제 실행을 쓸 만한지는 시스템 프롬프트에 적어 둔다. 실행을 시작하는 API 호출은 따로 없다. user.message로 할 일을 설명하면 실행을 시작할지, 언제 시작할지는 에이전트가 정한다 ^[2].

아래 Python 예제는 공식 문서에 나오는 계약서 검토 에이전트를 따랐다.

import anthropic

client = anthropic.Anthropic()

agent = client.beta.agents.create(
    name="Contract Reviewer",
    model="claude-opus-5-5",
    system=(
        "You review contracts. When you're asked to review more than a few "
        "contracts, start a workflow run that reads them in parallel and "
        "combines the findings. Review one or two contracts yourself, without a run."
    ),
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={"type": "multiagent_20261001", "workflows": {"type": "enabled"}},
)

위임 없이 동적 워크플로만 쓰려면 같은 블록에 "subagents": {"type": "disabled"}를 더한다. 직접 만든 에이전트만 허용하려면 workflows 아래의 inline_agents를 {"type": "disabled"}로 두고 에이전트를 하나 이상 목록에 올려야 한다. 목록이 비어 있으면 요청이 400 오류로 실패한다 ^[2].

문서는 실행 규칙도 프롬프트에 넣으라고 권한다. 문서 하나에는 에이전트 하나를 붙이고, 모든 결과를 검토하는 두 번째 에이전트를 두고, 에이전트 하나가 실패해도 실행 전체를 실패로 돌리지 않고, 시간 제한을 두라는 식이다 ^[2].

기존 설정에서 걸리기 쉬운 점이 세 가지 있다.

1. 세션은 만들 때의 설정을 그대로 쓴다. 세션은 생성 시점에 설정을 복사하므로, 에이전트를 바꿔도 이미 있는 세션은 바뀌지 않는다 ^[2].
2. coordinator에서 옮기면 블록 전체가 바뀐다. 업데이트는 multiagent 블록을 통째로 교체한다. workflows를 빼면 기본값이 적용돼 켜지고, 서브에이전트 목록을 빼면 목록이 비워진다 ^[2].
3. ant__ 접두사는 예약돼 있다. 이름이 ant__로 시작하는 커스텀 툴이 있으면, 이름을 바꾸거나 지울 때까지 에이전트 업데이트가 모두 400 오류로 실패한다 ^[2].

실행은 어떻게 지켜보고, 끝난 것은 어떻게 아나?

실행은 세션 이벤트 스트림에서 7가지 이벤트 타입으로 지켜본다. 실행 이름과 선언된 단계 목록은 workflow_run.created에 담겨 온다. 진행 상황은 workflow_run.phase_started와 workflow_run.phase_ended가 알려 주고, 일시 정지와 재개는 workflow_run.status_running과 workflow_run.status_idle이 알린다. 오류는 workflow_run.error로 오고, 최종 결과인 result는 workflow_run.status_ended에 실려 온다 ^[3]. 실행 이벤트로는 웹훅이 호출되지 않는다.

문서 예제를 조금 고친 짧은 루프로 스트림을 돌며 열린 실행을 추적할 수 있다.

open_runs = {}

with client.beta.sessions.events.stream(session_id) as stream:
    for event in stream:
        if event.type == "workflow_run.created":
            open_runs[event.workflow_run_id] = event.name
        elif event.type == "workflow_run.status_ended":
            open_runs.pop(event.workflow_run_id, None)
            print(event.result.type)
        elif event.type == "session.status_idle":
            if not open_runs and event.stop_reason.type == "end_turn":
                break

작업이 끝났다고 보려면 두 조건이 모두 맞아야 한다. 생성을 확인한 모든 실행에 workflow_run.status_ended가 와야 하고, 그 뒤에 end_turn을 담은 session.status_idle이 와야 한다. 일시 정지된 실행은 세션을 running 상태로 붙잡아 두지 않으므로, 세션이 유휴 상태라는 사실만으로는 작업이 끝났다고 볼 수 없다 ^[3]. 실제 서비스용 클라이언트라면 실행의 스레드에서 들어오는 툴 호출에도 그때그때 답해야 한다. 문서의 전체 예제에 이 처리가 나와 있다.

result는 꼼꼼히 읽어야 한다. completed는 프로그램이 끝났다는 뜻일 뿐이고, 작업이 통과했다는 보장은 없다. 일부 스레드의 작업이 실패해도 실행은 completed로 끝날 수 있다. 나머지 결과로는 stopped가 있고, 오류 타입으로는 timeout_error, program_error, thread_limit_error, unknown_error가 있다 ^[3].

비용은 얼마이고, 한도는 어떻게 되나?

실행에는 따로 매기는 가격이 없다. 실행 안의 에이전트가 쓴 토큰은 모델별 요금으로 청구되고, 세션 예산과 Messages API 요청 한도에 함께 잡힌다 ^[3]. Managed Agents는 여기에 세션 런타임 요금을 더한다. 세션이 running 상태인 동안 세션 시간당 $0.08이다 ^[4]. Anthropic은 Claude Code의 동적 워크플로가 "일반적인 Claude Code 세션보다 토큰을 훨씬 많이 쓸 수 있다"고 경고한다 ^[5].

2026년 10월 13일 기준으로 문서에 나온 한도는 다음과 같다 ^[3].

AI 에이전트를 쓰는 팀에는 무엇이 달라지나?

팀 입장에서 보면 동적 워크플로는 감사, 마이그레이션, 심층 리서치, 교차 검증처럼 크고 병렬로 돌아가는 작업을 직접 관리하던 스크립트에서 에이전트 요청 하나로 옮겨 온다. 문서도 이 네 가지를 실행에 잘 맞는 작업의 예로 든다 ^[2]. 요청하는 사람은 여전히 기본 스레드의 에이전트 하나와 대화하고, 실행은 그동안 백그라운드에서 일한다.

대신 잘 보이지 않는 부분이 생긴다. 워크플로 코드도, 실행을 시작하고 관리하는 툴 호출도, 스레드마다 워크플로에 돌려주는 결과도 볼 수 없다. 실행이 끝난 뒤 에이전트에게 워크플로를 출력해 달라고 요청할 수는 있다 ^[3]. 감사 기록이 필요한 팀이라면 이 요청을 정해진 절차로 만들어 두는 편이 좋다.

한계와 남은 질문은?

이 기능은 베타이고, 문서는 몇몇 동작을 보장하지 않는다고 분명히 밝힌다. 동시 스레드 64개라는 수치는 바뀔 수 있다. 스레드가 어느 단계에서 일하는지 알려 주는 이벤트가 없고, 실행 목록을 돌려주는 엔드포인트도 없다. 그래서 다시 연결한 클라이언트는 지난 이벤트로 실행 상태를 다시 만들어야 한다 ^[3].

운영할 때 조심할 점도 두 가지 있다. 실행이 같은 작업에 스레드를 둘 이상 만들 수 있어서, 문서는 에이전트가 호출하는 툴을 두 번 호출해도 안전하게 만들라고 권한다. 또 인라인 에이전트는 세션 에이전트의 툴과 MCP 서버를 받지만, API는 그 전부를 받는다고 보장하지 않는다 ^[3]. 문서는 워크플로에 걸린 서버 쪽 다른 한도를 모두 공개하지 않았고, 릴리스 노트에도 Managed Agents에서 정식 출시될 날짜는 나와 있지 않다.