Claude Managed Agents ya puede escribir un programa de flujo de trabajo que asigna partes de una tarea grande a varios agentes, recopila sus hallazgos y los combina. La función está en beta. Este es un procedimiento documentado para un desarrollador de software que quiera revisar una carpeta de documentos y generar un archivo de hallazgos comprobados.

Esto utiliza la API y la CLI de Claude Platform de Anthropic. BIG CHANGE revisó la documentación vigente; no ejecutamos la configuración ni probamos un flujo de trabajo.

Qué hace el flujo de trabajo

Un flujo dinámico es un programa para una sola ejecución. Puede dividir el trabajo en fases, iniciar hilos de agentes en paralelo, pasar sus resultados entre fases, reintentar o gestionar una rama fallida y combinar los resultados. Por ejemplo, una primera fase podría revisar archivos por separado y una posterior conciliar los hallazgos. El agente principal inicia la ejecución; el servidor la ejecuta en segundo plano.

Esto es distinto de pedir al agente principal que cree ejecuciones separadas. Una ejecución de flujo coordina hilos secundarios dentro de una sola ejecución y devuelve el resultado al agente que la inició. Un mensaje normal de sesión no inicia una ejecución por sí mismo; el agente decide cuándo hacerlo según la tarea y su instrucción de sistema. Anthropic afirma que una sesión puede tener varias ejecuciones abiertas, pero cada una tiene sus propias fases y resultado.

Antes de empezar

Necesitas una cuenta de Claude Console, una clave API y acceso a Claude Managed Agents, que Anthropic dice que está habilitado de forma predeterminada para las cuentas API. Los endpoints del agente y del flujo requieren el encabezado managed-agents-2026-04-01 beta. El SDK de Anthropic añade ese encabezado automáticamente; si llamas a la API sin SDK, debes incluirlo tú.

Managed Agents todavía figura como beta en la documentación actual. Las notas de la versión fechan su beta pública el 9 de abril de 2026, la orquestación multiagente el 11 de mayo y los flujos dinámicos el 9 de octubre. Los flujos dinámicos también están en beta. La fecha importa: la cifra de «1.000 agentes» es un límite vigente por ejecución de flujo, no una nueva capacidad para iniciar 1.000 a la vez.

La plataforma almacena en el servidor el historial de conversación de la sesión, el estado del entorno aislado y los resultados. Anthropic dice que Managed Agents no reúne actualmente los requisitos para la cobertura de Zero Data Retention ni del acuerdo de asociado comercial de HIPAA. No incluyas material regulado o confidencial en una sesión salvo que tu organización haya confirmado las normas de datos y la configuración aplicables.

1. Instala la CLI y el SDK

Instala la ant CLI siguiendo el método de tu sistema operativo indicado en la guía de inicio de Managed Agents. Por ejemplo, el comando documentado para macOS es:

Terminal
brew install anthropics/tap/ant

Para Python, instala el SDK y proporciona la clave API mediante el entorno, en vez de incluirla en un archivo de código:

Terminal
pip install anthropic
export ANTHROPIC_API_KEY="your-api-key"

La clave anterior es un marcador de posición. Guarda el valor real en tu gestor habitual de secretos o en la configuración protegida del entorno.

2. Define un agente que pueda usar flujos

Crea document-reviewer.md. El bloque multiagent habilita el tipo de flujo de octubre. Desactivar los subagentes deja explícita la vía de delegación configurada: este agente usa flujos dinámicos, no delegación puntual a subagentes.

YAML
---
name: document-reviewer
model: claude-sonnet-5-5
tools:
  - type: agent_toolset_20260401
multiagent:
  type: multiagent_20261001
  subagents:
    type: disabled
  workflows:
    type: enabled
---

You review documents for a user-defined checklist.

When a request contains more than 20 independent files, use a dynamic workflow.
Make one phase that checks the files independently and a later phase that
reconciles duplicate findings. Do not infer missing facts. Save the final
machine-readable results to report.json and a concise explanation to summary.md.
Include the source filename and a short evidence excerpt for every finding.
If a file cannot be read or a worker fails, record that file as unresolved;
do not silently omit it. The final response must report the number of files
reviewed, unresolved files, and whether every output file was written.

El umbral y las instrucciones de revisión son decisiones de tu política, no valores predeterminados de Anthropic. Adáptalos al trabajo y al coste de los errores. claude-sonnet-5-5 es un ID de modelo de ejemplo; elige uno que esté disponible actualmente para tu cuenta y presupuesto.

Crea el agente y guarda el ID que devuelve:

Terminal
ant apply document-reviewer.md

La CLI imprime el ID del agente y lo registra en claude-lock.json. Managed Agents separa la definición reutilizable del agente (modelo, instrucciones y herramientas) del entorno en que se ejecuta una sesión.

3. Configura el entorno aislado

Un entorno controla dónde se ejecutan las sesiones: en un entorno aislado en la nube gestionado por Anthropic o en uno autoalojado en tu infraestructura. El ejemplo en la nube de la guía de inicio usa una red restringida y permite gestores de paquetes:

YAML
# environment.yaml
name: document-review
config:
  type: cloud
  networking:
    type: limited
    allow_package_managers: true

Aplícalo con ant apply environment.yaml; su ID también se guarda en claude-lock.json. Si el agente necesita acceso a la red, enumera solo los hosts necesarios en allowed_hosts. Con una red limitada, esa lista también restringe las herramientas de búsqueda y recuperación web de Managed Agents. Permitir gestores de paquetes no añade sitios web a la lista de permitidos.

Para la primera ejecución, usa una carpeta pequeña y no sensible, y solo las herramientas necesarias. El conjunto de herramientas integrado incluye operaciones de shell y archivos; añadir herramientas puede ampliar las acciones del agente. Revisa la política de permisos y los controles del entorno antes de conceder acceso a sistemas externos o credenciales.

4. Inicia una sesión y envía una tarea acotada

Usa los ID del agente y del entorno para crear una sesión con el SDK de Python:

Python
import anthropic

client = anthropic.Anthropic()
session = client.beta.sessions.create(
    agent="AGENT_ID_FROM_CLAUDE_LOCK",
    environment_id="ENVIRONMENT_ID_FROM_CLAUDE_LOCK",
    title="Small document review",
)
print(session.id)

Sustituye los dos marcadores de ID por los valores de claude-lock.json. Después envía una tarea concreta mediante el flujo de eventos de la sesión. Inicia el flujo antes de enviar el evento para ver la ejecución y su avance a medida que ocurren:

Python
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": (
                    "Review each Markdown file in /review-set for a missing "
                    "owner, deadline, or acceptance criterion. Quote evidence; "
                    "do not infer missing details. Reconcile duplicate findings "
                    "and write /mnt/session/outputs/report.json plus "
                    "/mnt/session/outputs/summary.md. In report.json, use "
                    "a files array with one record per input: path, status "
                    "(reviewed or unresolved), and findings; each finding has "
                    "a check, evidence excerpt, and source location. Include "
                    "input, reviewed, and unresolved counts."
                ),
            }],
        }],
    )
    open_runs = {}
    run_results = {}
    for event in stream:
        if event.type == "workflow_run.created":
            open_runs[event.workflow_run_id] = event.name
            print(f"Run started: {event.name}")
        elif event.type == "workflow_run.status_ended":
            run_results[event.workflow_run_id] = event.result.type
            open_runs.pop(event.workflow_run_id, None)
            print(f"Run ended: {event.result.type}")
        elif event.type == "workflow_run.error":
            print(f"Run error: {event.error}")
        elif event.type == "agent.message":
            for block in event.content:
                if block.type == "text":
                    print(block.text)
        elif event.type == "session.status_idle":
            if event.stop_reason.type == "end_turn" and not open_runs:
                break

    # Inspect the child threads associated with completed workflow runs.
    for thread in client.beta.sessions.threads.list(session.id):
        if thread.workflow_run_id in run_results:
            print(f"Thread {thread.id}: {thread.status}")
            for thread_event in client.beta.sessions.threads.events.list(
                thread.id, session_id=session.id
            ):
                if thread_event.type == "session.error":
                    print(f"Thread error: {thread_event}")

Este ejemplo presupone que el método de entrada configurado para la sesión expone los archivos en /review-set. Antes de pedir al agente que los revise, coloca los archivos en el entorno aislado de la sesión mediante el método documentado de entrada. Para los resultados, pide al agente que escriba en /mnt/session/outputs/; la documentación de archivos de Managed Agents explica cómo enumerar los archivos de una sesión y descargarlos. En el SDK de Python, la forma documentada de lectura es:

Python
files = client.beta.files.list(
    scope_id=session.id,
    betas=["managed-agents-2026-04-01"],
)
for report in files:
    if report.filename == "report.json":
        content = client.files.download(report.id)
        content.write_to_file("report.json")
        break

Un archivo puede tardar unos segundos en aparecer después de que la sesión quede inactiva; si falta, vuelve a enumerar los archivos tras una breve espera. Para una primera prueba segura, crea una carpeta de prueba con unos pocos documentos cuyos hallazgos esperados puedas revisar manualmente. El prompt de ejemplo define la tarea, pero no garantiza que el agente encuentre todos los problemas.

El contrato de salida debe ser lo bastante estricto para poder auditarlo. Por ejemplo:

JSON
{
  "files": [
    {
      "path": "requirements.md",
      "status": "reviewed",
      "findings": [
        {
          "check": "deadline",
          "evidence_excerpt": "...",
          "source_location": "requirements.md, section 2"
        }
      ]
    }
  ],
  "input_count": 1,
  "reviewed_count": 1,
  "unresolved_count": 0
}

Este esquema es una propuesta para tu flujo, no un esquema proporcionado por Anthropic. Conserva como registros los archivos sin resolver o ilegibles, para que la falta de un resultado no parezca una revisión sin problemas.

5. Comprueba la ejecución y sus resultados

Cuando empieza un flujo, el flujo de eventos informa de workflow_run.created, incluido un ID de ejecución y las fases declaradas por el flujo. El ejemplo mantiene abierto cada ID hasta su correspondiente workflow_run.status_ended; que la sesión principal esté inactiva no demuestra por sí solo que el flujo en segundo plano haya terminado. El flujo principal resume el estado de los hilos secundarios, mientras que la lista de eventos de cada hilo contiene sus mensajes y errores. El ejemplo enumera los hilos por workflow_run_id y muestra los eventos session.error . Inspecciona esos eventos para detectar reintentos agotados (incluido retry_status.type == "exhausted") u otros errores secundarios, y marca como no resueltos los archivos afectados.

Considera el archivo de salida como el entregable, no la palabra «completado». Anthropic advierte expresamente que una ejecución puede terminar con completed aunque haya fallado el trabajo de un hilo o no se haya podido crear un hilo. Abre report.json y comprueba que cada archivo de entrada tenga hallazgos o un estado explícito de no resuelto, que los extractos de evidencia apunten al archivo fuente correcto y que las cantidades coincidan con los archivos suministrados. Compara la carpeta de prueba con tus propios resultados esperados antes de usar el flujo con un corpus mayor.

Si se desconecta tu cliente, un nuevo flujo de eventos solo envía los eventos emitidos después de abrirse. Reconstruye el estado de la ejecución enumerando los eventos anteriores de la sesión con los filtros de tipo documentados y siguiendo la paginación. No deduzcas que una ejecución terminó porque el agente principal esté inactivo mientras los hilos secundarios quizá sigan trabajando. Cuando terminen todas las ejecuciones observadas, enumera los archivos de la sesión y descarga /mnt/session/outputs/report.json y summary.md mediante la API de archivos documentada. Comprueba que cada archivo suministrado tenga un registro revisado o no resuelto y que las cantidades cuadren. El bucle de eventos de ejemplo no descarga ni valida el informe.

Límites que afectan al diseño

Los límites de las ejecuciones de flujo actuales de Anthropic documentan hasta 64 hilos de flujo trabajando a la vez en una ejecución, pero advierten que la API no garantiza esa concurrencia y que el valor puede cambiar. El límite de 1.000 agentes cuenta los agentes iniciados durante toda la vida de la ejecución; no es un número de hilos simultáneos. Si el flujo intenta iniciar otro agente tras alcanzar ese total, la ejecución termina con thread_limit_error; los reintentos de agentes fallidos pueden crear hilos adicionales.

Una ejecución dura 24 horas de forma predeterminada, o menos si su agente fija una duración menor. El tiempo de espera de tu cliente cuenta, y una ejecución pausada también puede agotar el plazo. Una sesión tiene 10 ejecuciones abiertas de forma predeterminada, incluidas las inactivas. El presupuesto de uso de una sesión se aplica a todos los agentes del flujo; al alcanzarse, las ejecuciones abiertas se pausan hasta que se aumente o elimine el presupuesto. Planifica unidades de trabajo más pequeñas, guarda puntos de control en archivos y haz que la fase de conciliación informe de los elementos pendientes en vez de fingir que se revisaron.

Si hay fallos, inspecciona el workflow_run.error y el hilo afectado. program_error puede indicar que falló el código del flujo o un agente secundario; thread_limit_error identifica el límite de 1.000 agentes; timeout_error identifica la duración máxima de la ejecución. Si se alcanza el presupuesto de la sesión, auméntalo o elimínalo para reanudarla. Si necesitas detener un flujo, pide al agente principal que detenga sus ejecuciones; interrumpir un turno de sesión no equivale a cancelar una ejecución.

Coste

La documentación de precios de Anthropic cobra los tokens de modelo de Managed Agents según las tarifas del modelo elegido y el tiempo de sesión a 0,08 $ por hora de sesión en ejecución. El tiempo se acumula mientras el estado de la sesión sea running; no cuentan el tiempo inactivo, la reprogramación ni la terminación. Un flujo no tiene una tarifa aparte, pero el uso de tokens de sus hilos se factura como parte de la sesión. Las búsquedas web iniciadas en una sesión figuran a 10 $ por cada 1.000 búsquedas. El total exacto depende del modelo, los tokens de entrada y salida, las herramientas y la duración de la sesión; consulta el uso en Console en lugar de estimarlo a partir del límite de 1.000 agentes.

La configuración práctica consiste en empezar con unos pocos archivos, comprobar que los resultados del flujo dan cuenta de cada uno, inspeccionar los hilos fallidos y ampliar la entrada solo cuando la política de revisión y el coste sean aceptables. Los flujos gestionados coordinan trabajo paralelo asíncrono; no certifican los hallazgos.

El gran cambio

Desde el 9 de octubre, un agente de Managed Agents puede escribir un programa de flujo que el servidor ejecuta en varios hilos de agentes y fases. Los desarrolladores pueden usar esta vía para distribuir trabajo de forma acotada y auditable mientras la sesión principal sigue el avance. La función sigue en beta, y los límites publicados no garantizan que cada ejecución alcance su concurrencia máxima ni produzca hallazgos correctos.

Fuentes y lecturas adicionales