Claude Managed Agents: configuración, flujo de trabajo y compensaciones del SDK

Claude Managed Agents es el servicio de agentes alojado de Anthropic, en beta al momento de escribir. Ejecuta el bucle del agente, la sandbox y el registro de sesión del lado de Anthropic, y factura el tiempo de ejecución a $0.08 por hora de sesión además de tokens, con tiempo inactivo gratis. Envías eventos y transmites resultados en lugar de mantener esa capa tú mismo. Este artículo es un recorrido documentado de lo que el servicio aloja, cómo se comporta el flujo de trabajo basado en archivos ant apply, y dónde Agent SDK sigue siendo la opción mejor.

Nota: Managed Agents es un servicio beta al momento de escribir. Trata todo aquí en consecuencia.

Qué Claude Managed Agents aloja para ti

La versión corta: Anthropic ejecuta el arnés del agente, la zona de pruebas de cómputo y el registro de sesión. Tú envías eventos y transmites resultados de vuelta por HTTP. Eso es todo. No administras el ciclo de vida del contenedor, el entorno de ejecución de herramientas, ni la lógica de reintentos para fallos transitorios.

Más específicamente, aquí está lo que cae del lado de Anthropic:

• El bucle del agente. Claude decide cuándo llamar a una herramienta, procesa el resultado e itera sin que tengas que escribir la orquestación.
• Herramientas integradas. Bash, operaciones de archivos, búsqueda web, todas accesibles a través del tipo de herramienta agent_toolset_20260401. No los configures tú mismo.
• Zonas de pruebas por sesión. Cada sesión obtiene su propio entorno de ejecución aislado. Sin derrame entre sesiones.
• Registros de sesión duraderos. Si tu aplicación interrumpe el flujo, la sesión no ha desaparecido. Te reconectas y te pones al día.
• Integración MCP. Las herramientas personalizadas se adjuntan como servidores MCP. Claude activa la herramienta; tu servicio devuelve resultados sobre el protocolo. Nada que empaquetar en tu despliegue.
• Almacenamiento en caché de solicitudes. Integrado a nivel de plataforma, lo que importa una vez que tus solicitudes de sistema se vuelven largas.

Lo que mantienes de tu lado: la definición del agente, tus implementaciones de servidor MCP, y cualquier lógica de negocio que decida cuándo iniciar o detener una sesión. Esa es una superficie mucho más pequeña de la que ser responsable que un arnés completo.

Hatchworks cubre la división de infraestructura claramente: la inferencia puede comenzar antes de que se aprovisione un contenedor, lo que a menudo resulta más rápido para agentes de inicio en frío, aunque cada llamada de herramienta cruza un límite de servicio.

Cuándo elegir Managed Agents, el Agent SDK, o Claude Code

La confusión que veo más a menudo es que la gente trata estos tres como intercambiables. No lo son.

Claude Code es una herramienta de terminal. Excelente para un desarrollador que ejecuta tareas localmente. No es algo que insertes en un producto.

El [Agent SDK](/blog/claude-agent-sdk-guide-2026/) ejecuta el bucle del agente dentro de tu propio proceso, en tu propia infraestructura. Acceso directo al sistema de archivos, conectividad de red privada, control total sobre el entorno de ejecución. Elige el SDK cuando necesites cosas como escrituras de archivos locales sin un límite de servicio, infraestructura existente por la que ya pagaste, o flexibilidad multi-proveedor a nivel de modelo (aunque por ahora estés limitado a Claude de todas formas con el SDK).

Managed Agents es la solución alojada. Obtienes sesiones duraderas, cómputo en caja de arena e información integrada sin construir nada de esto. El modelo de costos es por hora de sesión, no solo por token, así que recompensa sesiones cortas enfocadas y penaliza las largas inactivas.

Aquí está la tabla de decisión:

Una cosa que vale la pena señalar: como se menciona en la guía del SDK en hidekazu-konishi.com, un camino común es hacer prototipos locales con el SDK y migrar a Managed Agents cuando quieras sandboxes alojadas que prefieras no operar.

Si tu desafío específico es construir el producto completo de agentes alrededor de esto, nuestro trabajo de ingeniería de agentes podría ahorrarte algunos giros equivocados.

Crea un agente e inspecciona una sesión

Este es un recorrido documentado, no una ejecución de producción verificada. Estoy describiendo el procedimiento de la documentación oficial; considera cualquier código aquí como ilustrativo hasta que lo ejecutes contra tu propia clave.

Llegar a un agente en funcionamiento requiere cuatro pasos.

1. Crea una definición de agente. Aquí es donde describes qué puede hacer el agente: a qué herramientas integradas tiene acceso, a qué servidores MCP puede llamar, y cuál es su indicación del sistema.
2. Crea un entorno de ejecución. La plataforma aprovisiona un caja de arena limitada a tu definición de agente.
3. Inicia una sesión. Envías un evento de inicio con la entrada de tu usuario. El ID de sesión regresa inmediatamente.
4. Fluye eventos. Las llamadas de herramientas, resultados intermedios y la respuesta final llegan en el flujo. Los manejas en tu aplicación.

Entre los siete SDKs oficiales (Python, TypeScript, Go, Java, C#, Ruby, PHP), la forma de ese flujo es consistente aunque la sintaxis difiera. El tipo de herramienta agent_toolset_20260401 es lo que desbloquea el conjunto completo de herramientas integradas en una única declaración. No enumeras bash, operaciones de archivos y búsqueda web individualmente.

Una vez que una sesión se está ejecutando, puedes inspeccionarla a través del punto final del registro de sesión. Aquí es donde el beneficio de durabilidad se muestra concretamente. Suelta el flujo, vuelve a conectar y el registro se reproduce desde donde lo dejaste. Para tareas de larga duración donde el cliente podría desconectarse, eso importa mucho.

Administra recursos con ant apply y claude-lock.json

El CLI ant es una herramienta separada del SDK mismo. Instálalo a través de Homebrew. Proporciona un flujo basado en archivos para declarar tus recursos de agente (agentes, entornos, registros de servidor MCP) en archivos de configuración, luego aplicarlos a la plataforma.

La documentación de ant apply describe el comando principal:

ant apply

Antes de tocar producción, ejecuta la bandera de ejecución simulada:

El CLI ant es una herramienta separada del SDK mismo. Instálalo a través de Homebrew. Proporciona un flujo basado en archivos para declarar tus recursos de agente (agentes, entornos, registros de servidor MCP) en archivos de configuración, luego aplicarlos a la plataforma.

Esto muestra una vista previa de lo que haría apply. Advertencia importante de la documentación oficial: --dry-run puede salir con código 0 incluso en un plan que sería bloqueado al momento de apply. No trates un dry-run limpio como garantía de que el apply completo tendrá éxito. Verifica el apply real en un ambiente de staging primero.

El archivo claude-lock.json es el lockfile que registra el estado actual de tus recursos desplegados. Piénsalo como un package-lock.json: fija versiones de recursos y previene divergencia entre lo que declaraste y lo que la plataforma está ejecutando. Después de cualquier ant apply, el lockfile se actualiza para reflejar el nuevo estado. Confirmalo. Trata los cambios en él como significativos en la revisión de código.

Un punto de serialización que confunde a la gente: applies parciales. Si ant apply falla a mitad del camino, algunos recursos estarán en el nuevo estado y otros no. El lockfile reflejará la actualización parcial. Antes de ejecutar ant apply nuevamente, compara el lockfile contra lo que realmente se desplegó, reconcilia manualmente si es necesario, y luego ejecuta de nuevo. Ejecutar un segundo apply sobre un estado parcial roto sin verificar primero puede dejar recursos en una condición intermedia confusa.

Esto es diferente de herramientas como Terraform que tienen un paso plan separado en el CLI. No hay ant plan. El dry-run es lo que tienes para vista previa. Diseña tu CI en consecuencia.

Revisa Cambios en CI y Maneja Fallos Parciales

Para equipos con múltiples desarrolladores trabajando contra el mismo ambiente de Managed Agents, se recomienda fuertemente aplicar cambios desde CI en lugar de máquinas locales. De lo contrario obtienes race conditions en el lockfile.

Aquí está el flujo que sugiero:

1. PR se abre. CI ejecuta ant apply --dry-run y publica el output como comentario en el PR.
2. El revisor comprueba el diff, incluyendo cualquier cambio en el lockfile.
3. Al hacer merge a main, CI ejecuta ant apply contra el ambiente de staging.
4. Promueve a producción solo después de que el apply en staging tenga éxito y las sesiones se comporten correctamente.

El requisito de serialización es la restricción operacional principal. No puedes ejecutar dos llamadas ant apply en paralelo contra el mismo ambiente. Si tu sistema CI puede encolar múltiples merges rápidamente, refuerza un lock a nivel de pipeline (la mayoría de plataformas CI tienen una configuración de concurrency group exactamente para esto).

Para el manejo de fallos parciales, la lista de verificación se ve así:

• Comprueba el lockfile inmediatamente después de un apply fallido. Anota cuáles recursos se actualizaron y cuáles no.
• No ejecutes ant apply a ciegas. Lee el error primero.
• Si el estado parcial es seguro dejar mientras investigas, déjalo. Si los recursos están en un estado intermedio roto, es posible que necesites hacer rollback manual antes de aplicar de nuevo.
• Una vez resuelto, ejecuta ant apply --dry-run nuevamente antes del apply completo para confirmar que el plan se ve correcto.

Porque --dry-run puede salir con código 0 en un plan bloqueado, no saltes el paso de revisión incluso si el dry-run se ve limpio.

Limitaciones Beta, Costos y una Lista de Verificación de Despliegue

Managed Agents es un servicio en beta. Esa designación importa para cualquier cosa crítica en producción. Las características pueden cambiar. Los precios pueden cambiar. Las garantías de disponibilidad en beta no son lo mismo que en GA.

Costos. La tarifa publicada es $0.08 por hora de sesión, medida solo mientras se está ejecutando una sesión (el tiempo inactivo no se factura), con tokens cobrados además a las tasas estándar del modelo. Eso lo hace relativamente predecible para sesiones cortas y enfocadas en tareas. Para sesiones de larga duración con uso sustancial de herramientas, querrás monitorear activamente la duración de la sesión. La guía de vibecodingacademy pone esto en contexto: la competitividad de costos depende del tiempo de ingeniería que gastarías construyendo una infraestructura autoadministrada equivalente, que es real y a menudo subestimada.

Restricciones actuales en beta:

• Las herramientas personalizadas se enrutan a través de servidores MCP, no funciones en el proceso. Si tu herramientas personalizadas están fuertemente acopladas al runtime de tu aplicación, necesitarás extraerlas hacia un servidor MCP primero.
• La observabilidad de sesiones es a través del endpoint de registro de sesión. No hay un dashboard equivalente incorporado a lo que construirías tú mismo usando el SDK.
• ant apply aplica semántica de fallo parcial que requiere reconciliación manual. No hay reversión automática.
• Las aplicaciones serializadas significan que el rendimiento del pipeline está limitado por la duración de la aplicación.

Lista de verificación previa al despliegue:

1. Definición del agente revisada y aviso del sistema finalizado
2. Servidores MCP registrados y probados independientemente antes de conectarlos al agente
3. claude-lock.json confirmado y tratado como un artefacto revisado
4. Salida de ant apply --dry-run revisada por una segunda persona antes de cualquier aplicación en producción
5. Monitoreo de duración de sesión implementado (vigila sesiones inesperadamente largas)
6. Procedimiento de recuperación de fallo parcial documentado para tu equipo
7. Entorno de staging validado antes de promover a producción
8. Alertas de presupuesto configuradas a nivel de cuenta dado que el precio beta podría cambiar

Una última cosa sobre la pregunta de construir versus comprar. El Agent SDK te da más control, sí. Pero control significa responsabilidad. Como ksred señala sobre el SDK, las sesiones con agentes que realizan trabajo sustancial pueden volverse costosas rápidamente, y la recuperación de fallo es completamente tu responsabilidad en el SDK. Managed Agents intercambia parte de ese control por sesiones duraderas e infraestructura que no operas. Ninguno es incorrecto. La elección depende de lo que tu equipo realmente pueda mantener.

Salida de ant apply --dry-run revisada por una segunda persona antes de cualquier aplicación en producción

¿Funciona Managed Agents con cualquier modelo Claude, o está restringido a versiones específicas?

La documentación oficial no lista restricciones de modelo específicas dentro de Managed Agents en el momento de la escritura. Dado el estado beta, la disponibilidad de modelos puede cambiar. Consulta la página de descripción general directamente antes de comprometerte con una versión de modelo específica en una definición de agente en producción.

¿Puedo ejecutar la misma definición de agente localmente con el SDK para probar antes de desplegar a Managed Agents?

No directamente. El SDK ejecuta el bucle en tu propio proceso contra tu entorno local; Managed Agents lo ejecuta en la sandbox de Anthropic. Puedes prototipado el comportamiento del agente con el SDK, pero el contexto de ejecución es lo suficientemente diferente como para que debas probar el despliegue real de Managed Agents en un entorno de staging antes de promover a producción.

¿Cómo maneja Managed Agents la autenticación para servidores MCP que necesitan credenciales?

La documentación oficial describe las herramientas personalizadas como conectadas a través de servidores MCP, con Claude activando la herramienta y tu servicio devolviendo resultados. El manejo de credenciales para esos servidores MCP es tu responsabilidad a nivel de servidor. Managed Agents no inyecta credenciales en llamadas MCP en tu nombre según la documentación actual.

¿Hay una forma de limitar el gasto por sesión en Managed Agents como lo hace el parámetro max_budget_usd del SDK?

El parámetro max_budget_usd del SDK en query() es un control a nivel de SDK que no se traduce directamente a la API REST de Managed Agents. Los controles de presupuesto dentro de Managed Agents no están documentados con la misma granularidad en el beta actual. Las alertas de gasto a nivel de cuenta son el respaldo más seguro ahora.

¿Qué sucede con una sesión en ejecución si la región o la sandbox experimenta una interrupción?

Los registros de sesión duraderos son una característica de diseño central de Managed Agents, pero los detalles específicos de la recuperación de sesión en una interrupción de infraestructura no se detallan en la documentación beta actual. Dado el estado beta, trata la garantía de durabilidad como de mejor esfuerzo hasta que Anthropic publique un SLA para el servicio.

El resumen honesto: Managed Agents es un servicio genuinamente útil que elimina una gran clase de trabajo de infraestructura. El flujo de trabajo ant apply es directo una vez que entiendes las advertencias de dry-run y el requisito de serialización. Pero está en beta, la semántica de fallo parcial requiere cuidado, y no es la respuesta correcta si necesitas acceso al sistema de archivos local o ya tienes infraestructura de agentes con la que estás satisfecho. Comienza con la tabla de decisión, elige basándote en lo que tu equipo realmente quiere poseer, y trata el archivo de bloqueo tan seriamente como lo harías con cualquier otro archivo de estado.