Escalar Managed Agents: separar el cerebro de las manos

• Managed Agents, un servicio hospedado para agentes de larga ejecución, adopta una arquitectura basada en interfaces que se mantiene estable aunque el harness cambie con la evolución del modelo
• El harness codifica supuestos sobre tareas que Claude no puede realizar por sí solo, pero a medida que el modelo mejora, esos supuestos se vuelven obsoletos (stale) y generan sobrecarga innecesaria
• Así como un sistema operativo virtualiza el hardware con abstracciones como procesos y archivos, Managed Agents virtualiza los componentes del agente (sesión, harness, sandbox) para que puedan reemplazarse de forma independiente
• Al separar el cerebro (harness) de las manos (sandbox), se lograron mejoras de rendimiento de aprox. 60% menos en p50 TTFT y más de 90% menos en p95
• Este diseño funciona como un meta-harness capaz de adaptarse en el futuro a cualquier harness o sandbox que aparezca

---

Los supuestos del harness se vuelven obsoletos con la evolución del modelo

• El harness es una estructura que codifica supuestos sobre tareas que Claude no puede hacer por sí mismo, pero cuando el modelo mejora, esos supuestos dejan de ser necesarios
• En Claude Sonnet 4.5 existía un fenómeno de "context anxiety" en el que la tarea terminaba antes de tiempo al acercarse al límite de contexto, por lo que se añadió al harness una lógica de reinicio del contexto
• En Claude Opus 4.5 ese comportamiento desapareció, y la lógica de reinicio pasó a ser código innecesario
• Como se espera que el harness siga cambiando, se construyó el servicio Managed Agents sobre interfaces generales que no dependen de una implementación específica

Filosofía de diseño inspirada en los sistemas operativos

• Los sistemas operativos virtualizan el hardware mediante abstracciones como procesos y archivos, de modo que pueden ejecutar incluso programas que todavía no existen
• Así como el comando read() funciona igual sobre un disk pack de los años 70 o sobre un SSD moderno, las abstracciones duran más que el hardware
• Managed Agents sigue ese mismo patrón y virtualiza los componentes del agente
  • Sesión (session): un log append-only de todos los eventos ocurridos
  • Harness: el bucle que invoca a Claude y enruta las llamadas a herramientas
  • Sandbox: el entorno de ejecución donde Claude ejecuta código y edita archivos

Diseño inicial: los límites de un contenedor único (problema de la "pet")

• Al principio, la sesión, el harness y el sandbox se colocaban en un solo contenedor
• Eso tenía ventajas, como permitir la edición de archivos directamente por syscall y evitar diseñar fronteras entre servicios
• Pero surgió el problema de que el contenedor se convertía en una "pet" (una instancia individual que no puede reemplazarse)
  • Si el contenedor fallaba, la sesión se perdía
  • Si dejaba de responder, había que recuperarlo manualmente
• Desde la perspectiva de depuración, con solo el stream de eventos por WebSocket era imposible identificar dónde ocurría la falla, y acceder al shell del contenedor también era difícil porque incluía datos del usuario
• El harness asumía que todos los objetivos de trabajo estaban dentro del contenedor, así que cuando un cliente pedía conexión con su VPC, era necesario hacer network peering o ejecutar el harness dentro de su propio entorno

Separar el cerebro y las manos (arquitectura central)

• El "cerebro" (Claude y el harness), las "manos" (sandbox y herramientas) y la "sesión" (log de eventos) se separan en interfaces independientes
• Cada componente puede fallar o reemplazarse de manera independiente

El harness sale del contenedor

• El harness se mueve fuera del contenedor y llama al contenedor como si fuera cualquier otra herramienta mediante execute(name, input) → string
• El contenedor pasa a ser "cattle" (una instancia reemplazable)
• Si el contenedor falla, el harness lo trata como un error de llamada a herramienta, y si Claude decide reintentar, inicializa un contenedor nuevo con provision({resources})

Recuperación ante fallas del harness

• Como el log de sesión existe fuera del harness, no hay estado interno del harness que deba sobrevivir
• Ante una falla, se obtienen los eventos con wake(sessionId) → getSession(id) y se reanuda desde el último evento
• Durante el bucle del agente, el harness mantiene un registro duradero de eventos con emitEvent(id, event)

Frontera de seguridad

• En el diseño acoplado, el código no confiable generado por Claude se ejecutaba en el mismo contenedor que las credenciales, por lo que un prompt injection podía robar variables de entorno
• Si un atacante obtenía el token, podía crear nuevas sesiones sin restricciones y delegar trabajo
• La solución estructural fue separar el sistema para que el sandbox nunca pudiera acceder a los tokens
• Git: al inicializar el sandbox con un token de acceso al repositorio, se clona y se conecta al remote local de git, para que el agente pueda hacer push y pull sin manejar el token directamente
• Herramientas personalizadas MCP: los tokens OAuth se guardan en un vault seguro, y al llamar herramientas MCP mediante un proxy dedicado, las credenciales se recuperan del vault usando el token asociado a la sesión para invocar el servicio externo

La sesión no es la ventana de contexto de Claude

• Las tareas de larga duración suelen superar la longitud de la ventana de contexto de Claude, por lo que se requieren decisiones irreversibles sobre qué conservar
• Compaction: Claude guarda un resumen de la ventana de contexto
• Herramienta de memoria: Claude escribe el contexto en archivos para poder aprender entre sesiones
• Recorte de contexto: eliminación selectiva de tokens, como resultados de herramientas antiguas o bloques de razonamiento
• El descarte irreversible de contexto puede llevar al fracaso porque es difícil predecir qué tokens necesitarán los turnos futuros
• Investigaciones previas exploraron almacenar el contexto como un objeto fuera de la ventana de contexto, al que el LLM accede de manera programática escribiendo código

Uso del log de sesión en Managed Agents

• La sesión funciona como un objeto de contexto que existe fuera de la ventana de contexto
• Se guarda de forma duradera en el log de sesión, no en el sandbox ni en un REPL
• La interfaz getEvents() permite seleccionar slices por posición del stream de eventos
  • Continuar leyendo desde el último punto leído
  • Retroceder algunos eventos antes de un momento específico
  • Releer el contexto antes de cierta acción
• Los eventos recuperados pueden transformarse en el harness y pasarse a la ventana de contexto de Claude
• Entre esas transformaciones se incluyen limpieza de contexto e ingeniería de contexto para lograr una alta tasa de aciertos en prompt cache
• La sesión solo garantiza almacenamiento y consulta duraderos, mientras que la gestión concreta del contexto se delega al harness para adaptarse a futuros cambios en los requisitos de los modelos

Muchos cerebros, muchas manos

Muchos cerebros (Many Brains)

• La separación entre cerebro y manos resolvió una molestia inicial de los clientes: al trabajar con recursos dentro de una VPC, ya no se necesita network peering
• En el diseño inicial, cada cerebro necesitaba su propio contenedor, por lo que la inferencia no podía empezar hasta terminar el aprovisionamiento del contenedor
• Incluso las sesiones que no necesitaban sandbox cargaban con el costo completo de configurar el contenedor, incluyendo clonado de repositorios, arranque de procesos y recuperación de eventos pendientes
• Tras la separación, el contenedor se aprovisiona como llamada a herramienta solo cuando hace falta, lo que elimina la latencia innecesaria
• La inferencia puede comenzar tan pronto como la capa de orquestación obtiene los eventos pendientes del log de sesión
• Aprox. 60% menos en p50 TTFT y más de 90% menos en p95 TTFT
• Escalar a muchos cerebros consiste simplemente en iniciar múltiples harnesses stateless y conectarlos a las manos solo cuando sea necesario

Muchas manos (Many Hands)

• Se necesitaba la capacidad de conectar cada cerebro a múltiples entornos de ejecución
• Claude debe razonar sobre varios entornos de ejecución y decidir cómo repartir el trabajo, por lo que es una tarea cognitivamente más difícil que usar un solo shell
• Al principio, por limitaciones de capacidad del modelo, el cerebro se colocó dentro de un contenedor único, pero a medida que la inteligencia mejoró, ese contenedor único terminó siendo una restricción
• En el diseño desacoplado, cada mano se trata como una herramienta execute(name, input) → string
  • Compatible con herramientas personalizadas, servidores MCP y herramientas propias
  • El harness no necesita saber si el sandbox es un contenedor, un teléfono o un emulador de Pokémon
• Como el cerebro y las manos no están acoplados, también es posible transferir manos entre cerebros

Conclusión: Managed Agents como meta-harness

• Es el mismo enfoque con el que los sistemas operativos virtualizaron el hardware para admitir programas que todavía no existían
• Managed Agents es un meta-harness no dependiente de un harness específico y ofrece una interfaz general capaz de alojar distintos harnesses
• Claude Code también puede usarse como un harness, y el sistema puede alojar harnesses de agentes especializados por tarea
• Sí existe una postura clara sobre la interfaz: Claude necesita capacidades de manipulación de estado (sesión) y de ejecución de cómputo (sandbox)
• El diseño de interfaces está orientado a escalar hacia muchos cerebros y muchas manos, y a una operación segura y estable a largo plazo
• No se hace ningún supuesto sobre la cantidad ni la ubicación de cerebros y manos