Agent Harness Engineering: estructurar agentes para que no se rompan

Addy Osmani, ingeniero de Google conocido por su trabajo en Chrome y rendimiento web, lleva semanas publicando reflexiones sobre la capa de infraestructura que rodea a los agentes IA. Su último hilo en Twitter —recogido en Hacker News el 10 de mayo— le pone nombre a algo que muchos equipos ya hacen de forma ad hoc: Agent Harness Engineering, el arte de construir el arnés que mantiene a un agente dentro de unos límites operativos razonables.

No es un framework nuevo ni una librería que instalar. Es una disciplina de diseño: decidir qué herramientas expone el agente, cómo valida sus propias salidas, qué ocurre cuando falla un subagente y quién tiene la última palabra antes de que algo irreversible suceda. La idea es sencilla en papel y notoriamente difícil en producción.

Qué entiende Osmani por «harness»

El término viene del mundo del testing: un test harness es el conjunto de utilidades que envuelven el código bajo prueba para controlarlo y observarlo. Osmani traslada la metáfora a los agentes: el harness es todo lo que no es el modelo en sí —los hooks, los guardianes de entrada y salida, los logs estructurados, los timeouts, los fallbacks— y que determina si el agente se comporta de forma predecible en un entorno real.

En el ecosistema Claude esto tiene una traducción directa. Claude Code ya ofrece varios puntos de anclaje naturales para construir ese andamiaje:

• Hooks (`PreToolUse`, `PostToolUse`, `Stop`): comandos shell que se ejecutan en eventos del ciclo de vida. Un hook `PreToolUse` puede, por ejemplo, interceptar cualquier llamada a una herramienta de escritura en disco y registrarla antes de que ocurra, o cancelarla si no cumple una política.
• MCP servers: al exponer solo los servidores MCP estrictamente necesarios para una tarea, se reduce la superficie de acción del agente. Un agente con acceso a cuarenta herramientas es más difícil de controlar que uno con cinco.
• Subagentes con scope acotado: delegar en subagentes especializados permite aplicar políticas distintas a cada capa. El subagente de búsqueda solo busca; el de escritura solo escribe; el orquestador no toca el sistema de archivos directamente.
• Skills como contratos: un skill bien definido no es solo contexto reutilizable, es también una especificación implícita de lo que el agente debe y no debe hacer dentro de ese dominio.

Por qué importa ahora

La proliferación de agentes autónomos ha adelantado un problema que hace dos años era teórico: los agentes fallan de formas que los modelos solos no fallaban. Un modelo que responde mal a una pregunta es fácil de corregir; un agente que encadena diez llamadas a herramientas y termina en un estado inconsistente es mucho más difícil de depurar y, según el contexto, puede tener consecuencias reales.

Los equipos que trabajan con Claude Opus 4.7 y su ventana de 1M de tokens tienen ahora más capacidad de meter contexto en un solo agente, lo que puede tentar a construir monolitos en lugar de pipelines acotados. La advertencia implícita de Osmani es que más contexto no resuelve el problema del control: un agente con más memoria sigue necesitando un harness que defina qué puede hacer con esa memoria.

Para quién es relevante

Esta discusión interesa principalmente a tres perfiles:

1. Ingenieros que ya tienen agentes en producción y han visto fallos en cascada o comportamientos inesperados que no sabían cómo etiquetar ni prevenir.
2. Equipos que están migrando flujos de trabajo a Claude Code y necesitan decidir cuánta autonomía ceder al agente y dónde poner frenos.
3. Desarrolladores de plugins y MCP servers que diseñan herramientas pensando en que serán invocadas por agentes, no por humanos, y que deben anticipar inputs malformados o secuencias de llamadas aberrantes.

El hilo de Osmani tiene poco engagement en Hacker News por ahora —tres puntos y ningún comentario en el momento de indexación—, pero la discusión que plantea es de las que suelen crecer con retraso, cuando los equipos se topan con el problema en producción y buscan vocabulario para describirlo.

---

Desde ElephantPink llevamos meses viendo cómo equipos con arquitecturas de agentes sólidas y equipos con caos total usan exactamente las mismas herramientas. La diferencia casi siempre está en si alguien pensó el harness antes de poner el agente a correr. Que alguien con la visibilidad de Osmani le ponga nombre formal es útil, aunque la disciplina todavía esté lejos de tener estándares consolidados.