Anthropic publicó recientemente una práctica de ingeniería sobre Harness. En la superficie habla de implementación de producto, pero en realidad responde a una pregunta de más largo plazo:
Cuando las capacidades de los modelos cambian continuamente, ¿qué capas de un sistema Agent deben permanecer estables y cuáles deberían poder reemplazarse con rapidez?
Juicio Central
Mi lectura principal de este artículo es que la infraestructura de agentes se parecerá cada vez más a un Agent OS ligero.
El punto no es “fijar en código el mejor flujo de hoy”, sino “definir abstracciones de sistema estables a largo plazo”.
Por Qué Esto Importa
Muchos frameworks de agentes suelen tener estos problemas:
- convierten carencias temporales del modelo en arquitectura permanente
- confunden la ingeniería de prompts con límites del sistema
- convierten un parche útil una vez en una dependencia de largo plazo
Los modelos se harán más fuertes. Un parche razonable hoy puede ser deuda técnica mañana.
La Solución de Anthropic: de un Harness Concreto a un Meta-Harness
Esta idea no promete una forma fija de orquestación, sino que abstrae tres interfaces estables:
session: historial recuperable de eventos y estadoharness: bucle de razonamiento y planificación (brain)sandbox: entorno de ejecución y capacidades de herramientas (hands)
Una vez separadas, el sistema es más fácil de reemplazar, recuperar y ampliar.
1) Session No Es la Ventana de Contexto
Una idea clave es: Session no equivale al contexto del modelo.
Session debería ser un registro de eventos consultable, reproducible y recuperable, no una concatenación del historial que se introduce directamente en el modelo.
El valor de hacerlo así:
- trimming no significa que la historia desaparezca
- compaction no significa que los hechos se pierdan
- la recuperación tras un fallo puede volver a la capa de eventos, en vez de depender de una memoria resumida
2) Harness Es una Capa de Orquestación Reemplazable
Harness debería centrarse en la planificación y la ejecución, no en poseer estado de negocio.
Una interfaz ideal se parece más a:
execute(name, input) -> string
Esto significa que el modelo solo necesita saber “qué capacidad puedo invocar”, sin quedar atado a un dispositivo, contenedor o sistema operativo concreto.
3) Sandbox Son las “Manos”, No el “Cerebro”
Cuando brain y hands están desacoplados:
- el entorno de herramientas puede evolucionar de forma independiente
- distintas infraestructuras pueden conectarse en paralelo
- no hace falta precalentar un entorno de ejecución completo para cada sesión
Esto mejora directamente el arranque y la capacidad de escalar.
Ideas Sobre Rendimiento y Seguridad
Esta separación normalmente mejora a la vez el rendimiento y la seguridad.
En rendimiento:
- se puede iniciar primero el brain y levantar las hands bajo demanda
- se reduce la latencia hasta el primer token (TTFT)
En seguridad:
- no se exponen credenciales de alto valor directamente al modelo
- se usan proxy / vault controlados para acceso indirecto a credenciales
- los límites de seguridad se construyen sobre restricciones del sistema, no sobre “el modelo no debería poder hacerlo”