Soy Lena. Mantuve abierto el blog de ingeniería antrópica en mi pantalla durante un tiempo después de leer la entrada de arquitectura de Managed Agents. No porque tuviera prisa por probarlo, sino más bien porque el encuadre me pilló desprevenida.
Compararon la infraestructura de agentes con los sistemas operativos. La forma en que un sistema operativo virtualiza el hardware en abstracciones — proceso, archivo, socket — que duran más que el propio hardware. Luego dijeron: hicimos lo mismo, pero para agentes.
Me quedé pensando en eso un momento.
Claude Managed Agents se lanzó en beta pública el 8 de abril de 2026. No es un modelo nuevo. Es una capa de infraestructura: un entorno de ejecución alojado donde Claude opera como un agente autónomo dentro de un entorno gestionado. La forma en que Anthropic lo diseñó dice algo por lo que merece la pena ralentizarse, especialmente si tu equipo está decidiendo si construir infraestructura de agentes o entregar esa capa a otra persona.
Esto es lo que he notado, y lo que sigo intentando entender.
Lo que son los agentes gestionados por Claude
Servicio alojado para trabajo de agente a largo plazo
En esencia, Claude Managed Agents es un conjunto de APIs que gestiona el tiempo de ejecución del agent. Tú defines lo que debe hacer el agente: el prompt del sistema, las herramientas, las restricciones. Anthropic lo ejecuta en un contenedor aislado en la nube donde Claude puede leer archivos, ejecutar código, navegar por la web y llamar a servicios externos a través de conectores basados en MCP.
La propuesta es sencilla: en lugar de pasar meses construyendo tu propio bucle de agentes, sandbox, orquestación de herramientas, recuperación de errores y gestión de credenciales, se lo entregas a Anthropic. Según la documentación oficial de Agentes Gestionados, el harness soporta caché de prompts integrada, compactación de contexto y optimizaciones de rendimiento — cosas que la mayoría de los equipos acaban construyendo desde cero.
El precio se basa en el consumo: tasas estándar de tokens API de Claude, más \0,08 $ por hora de sesión para el tiempo de ejecución activo. El tiempo de inactividad no cuenta. El tiempo de ejecución se mide por milisegundo. No hay cuota mensual fija. No hay licencia por agente.
… Esa estructura de precios me hizo mirar dos veces. Significa que el verdadero factor de coste no es el tiempo de ejecución en sí, sino lo hábil que se vuelve el bucle de herramientas de tu agente durante una sesión. Cada comando bash, lectura de archivo y búsqueda web aporta tokens. El \0,08$/hora es casi un error de redondeo comparado con lo que una sesión muy agentiva consume en inferencia.
! [imagen] (https://cdn.10b.ai/1777521612287-1.png)
Interfaces de sesión, arnés, sandbox y eventos
Aquí es donde la arquitectura me resultó interesante.
El blog de ingeniería de Anthropic sobre Agentes Gestionados describe tres componentes virtualizados, cada uno diseñado para evolucionar de manera independiente:
La sesión es un registro de eventos duradero al que solo se le puede añadir información. Cada mensaje de usuario, respuesta del asistente, llamada a herramientas y resultado de herramientas se registra como un evento tipado. Vive completamente fuera del arnés. Sobrevive a fallos, cortes de red y reinicios de contenedores. Dos primitivas de interfaz: appendEvent() y getEvents(). Eso es todo.
El arnés es el bucle del agente: llama a Claude, enruta las llamadas a herramientas, y gestiona el contexto. Es fundamental que Anthropic posee esto y lo actualiza a medida que los modelos mejoran. Descubrieron que un arnés construido para Claude Sonnet 4.5 incluía lógica de reinicio de contexto para manejar la "ansiedad de contexto", pero cuando llegó Claude Opus 4.5, esa ansiedad desapareció. El arnés antiguo estaba reteniendo activamente al modelo más reciente. Esa observación fue lo que impulsó toda la arquitectura.
El sandbox es el entorno de ejecución: un contenedor aislado con gVisor donde se ejecuta el código generado por Claude. La salida de red está por defecto denegada. El acceso al sistema de archivos está limitado. Las credenciales nunca se almacenan en el sandbox: se guardan en una bóveda segura y se acceden mediante un proxy. El sandbox se considera no confiable por diseño.
Sigo volviendo a esta separación. Es limpia. Pero no entendí completamente por qué importaba hasta que pensé en lo que sucede cuando se lanza el siguiente modelo.
Lo que resuelven los Agentes Gestionados
Infraestructura en tiempo de ejecución, sandboxing, sesiones reanudables
Si has intentado lanzar un agente en producción, ya conoces la lista: ejecución en sandbox, gestión de credenciales, persistencia de sesiones, recuperación de errores, observabilidad. Un desarrollador describió contar seis sistemas separados que su equipo construyó solo para mantener un agente funcionando en producción — cuatro de los cuales no tenían nada que ver con lo que el agente realmente hace.
Los Agentes Gestionados eliminan toda esa categoría de trabajo. Las sesiones pueden durar horas. Si una conexión se cae, la sesión se reanuda desde el registro de eventos duradero. Cada llamada a herramientas y modo de fallo es rastreable mediante observabilidad incorporada. Empresas como Notion, Asana y Sentry ya han integrado agentes construidos sobre esta infraestructura.
El impacto práctico es real. Un agente de codificación que lee una base de código, planifica una corrección y abre un PR. Un agente de investigación que funciona durante noventa minutos a través de docenas de búsquedas web. Estos patrones solían requerir meses de trabajo en infraestructura antes de poder empezar con la lógica del agente.
Por qué la desvinculación de cerebro y manos importa
…aquí fue donde algo hizo clic para mí.
Anthropic enmarca la arquitectura como la separación del "cerebro" (el modelo más el arnés que decide qué hacer) de las "manos" (las herramientas y entornos que realmente ejecutan el trabajo). Esa separación tiene una consecuencia específica: cuando se lanza un mejor modelo, el arnés se puede actualizar sin tocar la definición de tu agente.
En el antiguo diseño acoplado, cada sesión pagaba el costo completo de inicio del contenedor, incluso las sesiones que nunca tocaban el entorno. Cuando Anthropic movió el arnés fuera del contenedor, las sesiones que no necesitaban ejecutar código podían iniciarse sin esperar a que se aprovisionara un contenedor.
Pero el punto más profundo es sobre la durabilidad. Los arneses codifican suposiciones sobre lo que el modelo no puede hacer. Esas suposiciones se vuelven obsoletas a medida que los modelos mejoran. Si tu arnés es un sistema codificado que construiste tú mismo, heredas el costo de mantenimiento de mantener esas suposiciones actualizadas. Si Anthropic posee el arnés, ese costo se transfiere a ellos.
No estoy completamente seguro de cuánto se mantiene esa promesa en la práctica con el tiempo. Pero la lógica arquitectónica tiene sentido para mí.
Lo que los Agentes Gestionados No Resuelven por Defecto
Esta es la parte en la que pasé más tiempo reflexionando.
Validación de capacidades, reutilización entre agentes, ciclo de vida de gobernanza
Los Agentes Gestionados resuelven el problema en tiempo de ejecución de manera integral. Pero hay problemas adyacentes que no aborda, no por un defecto, sino porque están fuera de su alcance actual.
Validación de capacidades. Cuando un agente completa exitosamente una tarea compleja —por ejemplo, clasificar una categoría de alertas de seguridad o refactorizar un patrón de código específico— ese éxito no se captura como una capacidad validada y reutilizable. El registro de la sesión documenta lo que ocurrió, pero no hay un mecanismo para decir "este enfoque funcionó, encódalo como una estrategia que otros agentes puedan heredar." Cada sesión comienza de cero. Lo que Claude aprendió en una sesión no mejora automáticamente la siguiente.
Reutilización entre agentes. Puedes definir un agente una vez y referenciarlo por ID en varias sesiones. Eso es reutilización a nivel de configuración: mismo prompt, mismas herramientas, mismas restricciones. Pero no es reutilización a nivel de capacidad. Si el Agente A descubre una estrategia de depuración efectiva para un framework específico, el Agente B trabajando en un problema similar no se beneficia a menos que un humano actualice manualmente el prompt compartido del sistema.
Ciclo de vida de la gobernanza. La versión beta incluye permisos específicos, gestión de identidad y trazado de ejecución. Pero la cuestión de gobernanza más amplia —quién valida que los comportamientos de un agente sean seguros antes de propagarse, cómo auditas la deriva de capacidades con el tiempo—, esos patrones no forman parte de la superficie actual.
Podría estar leyendo demasiado en esto. Estos podrían ser elementos del roadmap futuro. Pero ahora mismo, Managed Agents proporciona una ejecución gestionada excelente sin acumulación de capacidades incorporada. La diferencia importa si estás pensando en la mejora del sistema a largo plazo y no solo en la automatización de tareas.
…algo está un poco confuso aquí. Creo que la brecha es deliberada —Anthropic está resolviendo primero el problema de infraestructura, y el problema de evolución de capacidades es otra capa diferente. Pero aún no estoy completamente seguro.
Managed Agents vs Claude Code Routines
Ejecución prolongada vs automatización activable
Esta comparación me confundió al principio, pero ahora es más clara después de mirar ambos.
Claude Code Routines son configuraciones guardadas — un prompt, repositorios, conectores — que se ejecutan automáticamente en un horario, mediante llamada API, o en respuesta a eventos de GitHub. Están diseñadas para tareas desatendidas y repetibles como clasificación nocturna, revisión de PRs o escaneo de desviación de documentación. Cada ejecución es una sesión nueva. Se aplican límites diarios (5-25 por día según plan). Consumen de tu uso de suscripción.
Claude Managed Agents es un entorno de ejecución alojado para trabajo autónomo a largo plazo. Las sesiones pueden durar horas. El sistema gestiona compactación de contexto, recuperación de errores y orquestación de herramientas. La facturación es por token más hora de sesión. No hay límites de ejecuciones diarias —pagas por lo que usas.
La distinción más simple: Routines es automatización activable. Managed Agents es un entorno de ejecución para infraestructura de agentes. Las Routines asumen que la tarea está acotada y es repetible. Managed Agents asume que la tarea es abierta y puede tomar tiempo.
Un agente de programación que planifica un refactor de varios archivos, ejecuta pruebas y abre un PR —ese es territorio de Managed Agents. Un script nocturno que etiqueta nuevos issues y publica un resumen en Slack —ese es una Routine.
Ninguno reemplaza al otro. Pero ninguno, por sí solo, convierte la ejecución exitosa en una capacidad reutilizable.
Quién debería evaluar Managed Agents
Basado en lo que he visto, Managed Agents vale la pena evaluar seriamente si tu equipo cumple con estas condiciones:
Ya has prototipado un agente y te has topado con un muro de infraestructura. El salto de "demo funcional" a "despliegue en producción" es donde la mayoría de los equipos se estancan. Si tu backlog incluye elementos como "construir aislamiento sandbox", "implementar puntos de control de sesión" o "gestión de credenciales de diseño", Managed Agents elimina toda esa categoría.
Las tareas de tu agente son de larga duración y de varios pasos. Si el agente necesita leer una base de código, planificar cambios, ejecutar código, ejecutar pruebas, ejecutar pruebas y abrir una PR — todo en una sesión que puede durar una hora — este es el tipo de carga de trabajo para la que están diseñados los Agentes Gestionados. Las tareas cortas y síncronas se atienden mejor con la API estándar de Mensajes.
Estás cómodo con el límite beta. Todos los endpoints requieren el encabezado beta managed-agents-2026-04-01. La coordinación multiagente y la autoevaluación aún están en fase de vista previa de investigación. Los comportamientos pueden cambiar. No construyas flujos de trabajo críticos en superficies que no han alcanzado GA.
Has considerado la cuestión del bloqueo. Una vez que tus agentes se ejecutan en la infraestructura de Anthropic, cambiar de proveedor no es trivial. La entrada del blog de Anthropic sobre Agentes Gestionados presenta esto como un compromiso deliberado: evolución de los exploits gestionados a cambio de acoplamiento a un solo tiempo de ejecución. Si tu arquitectura requiere mezclar modelos de múltiples proveedores, esta restricción importa.
No esperas herencia de capacidades por defecto. Managed Agents te ofrece una excelente ejecución gestionada — no es un sistema donde los comportamientos exitosos se acumulan o mejoran a sí mismos entre sesiones.
! [imagen] (https://cdn.10b.ai/1777521636346-5.png)
Preguntas frecuentes
¿Qué modelos soporta Managed Agents?
La beta pública soporta Claude Sonnet 4.6, Claude Opus 4.6 y Claude Haiku 4.5. Un gran contexto (1M de tokens) está disponible por defecto en Opus y Sonnet.
¿Cómo se valora?
Tasas estándar de token API de Claude para uso de modelos, más \0,08 por cada 1.000 búsquedas. Se excluye el tiempo de inactividad. No hay una tarifa mensual fija.
¿Cuál es la diferencia entre beta y vista previa de investigación?
La plataforma central — sesiones, sandboxing, ejecución de herramientas — está en beta pública. La coordinación multiagente y la autoevaluación (resultados) están en vista previa de investigación y requieren solicitudes de acceso separadas.
¿Puedo establecer límites de presupuesto por sesión?
No directamente dentro de Agentes Gestionados. Puedes establecer un límite mensual de gasto a nivel de organización en la Consola Claude, pero actualmente no se documentan los límites presupuestarios por sesión. Envolver la creación de sesiones con tu propia lógica para rastrear y terminar las sesiones descontroladas es la solución práctica.
¿Cada sesión comienza de nuevo?
Las sesiones mantienen el estado dentro de una sola sesión: sistema de archivos, historial de conversación, registro de eventos. Pero entre sesiones, no hay memoria incorporada ni transferencia de capacidades. Cada nueva sesión comienza con un entorno limpio.
¿Es esto lo mismo que Claude Code?
No. Claude Code es una herramienta de desarrollo para codificación interactiva. Managed Agents es un servicio de infraestructura a nivel de API para desplegar agentes autónomos a gran escala. Comparten ADN arquitectónico pero sirven a diferentes audiencias.
Todavía estoy analizando la arquitectura. La sesión, el arnés, el sandbox: cada uno virtualizado, cada uno evoluciona de manera independiente. El problema de tiempo de ejecución que resuelve es real, y para equipos atrapados entre el prototipo y la producción, esto cambia la línea de tiempo de meses a días.
Pero sigo notando el espacio entre “ejecución gestionada” y “capacidad que se acumula”. El registro de la sesión registra todo lo que sucedió. Aún no convierte lo que pasó en algo sobre lo que la siguiente sesión pueda construir.
Publicaciones anteriores:
👉 ¿Quieres entender cómo se conecta Claude Code a herramientas y agentes externos? Comienza con la base MCP:¿Qué es MCP? Explicación del Estándar de Conexión de Herramientas de IA
👉 ¿Construyendo agentes más allá de los prompts? Esto desglosa cómo funcionan realmente las habilidades en Claude Code:Habilidades de Claude Code Explicadas: Construye, Comparte y Extiende
👉 ¿Curioso sobre cómo se apilan las capas de infraestructura de agentes en sistemas reales? Aquí tienes la vista completa de arquitectura:MCP, CLI y GEP: Las Tres Capas del Stack de Agentes
👉 Si estás comparando infraestructura vs capacidad, esto explica la diferencia clave que la mayoría de los equipos pasa por alto:Habilidades de Agente vs Activos GEP: La Diferencia Real
👉 ¿Te preguntas cómo realmente escala la memoria del agente (y dónde falla)? Esto analiza los compromisos reales:Límites de Memoria del Agente Hermes y Compromisos
