Harness de agentes IA: donde se gana o se pierde

El harness de agentes IA es donde está el trabajo de verdad

Esta semana se han juntado cuatro lecturas que cuentan la misma historia desde ángulos distintos. Tenex, Ramp, Vercel y un ingeniero que vive dentro de Claude Code explican cómo han montado su harness de agentes IA, es decir, todo lo que rodea al modelo: el contexto que recibe, las herramientas que usa, cómo se recupera cuando algo se cae y cómo te avisa a ti.

Y las cuatro llegan a una conclusión que comparto bastante: el modelo importa, pero lo que separa un agente que funciona en producción de una demo bonita está alrededor.

Tenex: el proyecto vive en el repo

Tenex es una empresa de unas 75 personas que trabaja con grandes empresas y con mid-market, según contaron en Latent Space. En su artículo Building an AI-Native SDLC explican MetaHarness, el sistema con el que desarrollan.

La idea central es tratar el contexto como código. Cada proyecto tiene un “registro del proyecto”: un repo de Markdown, junto al código, con lo que es verdad ahora, lo que se pretende construir y lo que ha pasado. Linear, GitHub y los informes al cliente son vistas de ese registro, no una segunda versión de la verdad. El estado no lo escribe nadie a mano: se calcula a partir del registro.

Lo que más me gusta es cómo usan la validación. Su CLI, tenex validate, no se limita a decir que algo falla. Te dice qué ticket apunta a qué hito que no existe y qué hacer para arreglarlo, con un mensaje lo bastante preciso como para que el agente se corrija solo y vuelva a pasar el chequeo. Y si un agente intenta marcar un ticket como hecho sin PR, sin tests o sin aprobación enlazada, el sistema no le deja. Al humano solo le llega lo que el agente no ha podido demostrar.

También mantienen más de cincuenta skills compartidas, versionadas y probadas como si fueran software. Cuando un proyecto descubre una forma mejor de revisar una arquitectura, la mejora va a la skill y todas las sesiones siguientes la heredan.

Ellos mismos ponen dos límites honestos: para un equipo pequeño con un solo proyecto puede ser excesivo, y nada de esto funciona si el equipo no se compromete a escribir las cosas. Para empezar recomiendan algo muy razonable: tres carpetas (lo que es verdad, lo que queremos construir y lo que ha pasado), un plan para un proyecto real y un validador, aunque sea pequeño.

Si has leído lo que escribí sobre vibe coding vs SDD, verás que esto es Spec-Driven Development llevado a toda la organización.

Ramp: construir el harness en casa

Ramp ha contado cómo ha construido Laminar, el harness interno sobre el que corren sus productos con agentes. Antes probaron prácticamente de todo: SDKs de los proveedores de modelos, APIs de agentes gestionados, agentes open source, frameworks y soluciones de terceros.

La lista de lo que acaba haciendo un harness en producción es larga: guardar el historial de conversación de forma segura, compactar sesiones, interfaces estándar para llamar a herramientas, cola de mensajes para que el usuario pueda corregir al agente mientras trabaja, subagentes, interacciones con humanos, chat con varias personas y observabilidad.

El dato que me hizo parar: la primera versión de Laminar se hizo en seis semanas y el código lo generaron agentes. Cinco meses después, todos los productos con agentes de Ramp corren sobre él. Eso sí, ellos mismos lo matizan: construir en casa nunca ha sido tan barato, pero sigues necesitando buenos ingenieros de guardia, que mantengan la plataforma sana y que entiendan qué necesitan de verdad los equipos de producto.

Para mí, la lección no es “constrúyete tu propio harness”. Es que hoy un equipo pequeño y con experiencia puede hacerlo, y que esa decisión tiene un coste de mantenimiento que no desaparece.

Vercel: que una caída no te haga perder el trabajo

Vercel ha publicado durable-harness, un paquete open source para que harness como Pi, OpenCode, Codex o Claude Code sobrevivan a caídas en la nube, en Vercel o en tu propio Postgres.

El mecanismo es sencillo de explicar: antes de cada llamada al modelo o a una herramienta se registra la intención, y al terminar se registra el resultado. Si la función muere a mitad de turno, otra lee el log y sigue donde se quedó. Lo que ya terminó no se repite, así que tampoco pagas dos veces los tokens de una llamada que ya acabó.

Lo que más me ha gustado es el detalle de las herramientas. Cada una declara qué pasa si se interrumpe. Una consulta se marca como segura para repetir. Un reembolso se marca para no repetirse nunca: el modelo recibe el aviso de que puede que ya se hiciera y decide si comprobarlo antes. Es una de esas decisiones de diseño que parecen pequeñas y que te ahorran un disgusto en producción.

Claude Mods: el harness que mira hacia ti

La cuarta lectura va en otra dirección. Dan McAteer explica en Latent Space qué son los Claude Mods: plugins de Claude Code con funciones en TypeScript o JavaScript que reaccionan a eventos (un prompt, una llamada a herramienta, el render de la interfaz) y pueden observarlos, cambiar cómo se muestran o sustituir el comportamiento por defecto. Claude Code ya trae seis integrados.

Su tesis es que el harness, que nació para conectar al agente con la máquina, está girando para conectar al agente con la persona. Decide cuándo te interrumpe, qué te enseña y qué decisiones necesita de ti. Me encaja con algo que veo cada semana: cuando el agente trabaja rápido, lo escaso es tu atención.

Me gusta que el autor cuente también las pegas. Su supervisor saltó en 99 de 111 turnos, y cuando algo te avisa siempre, acabas ignorándolo. Según el README del mod, cada chequeo cuesta unos 5.000-6.000 tokens en una sesión de 50.000. Y los mods no van en sandbox: corren con tus permisos, leen tus ficheros y ven tus prompts. Yo, antes de instalar el mod de otra persona, leería el código.

Lo que me llevo para equipos que adoptan agentes

Si tuviera que quedarme con tres ideas:

1. El contexto es parte del sistema. Si las decisiones no están escritas y versionadas junto al código, el agente no las conoce. Y la validación que da errores precisos es lo que permite que el agente se corrija solo.
2. Diseña para cuando algo falla. Turnos que se caen, herramientas que no se pueden repetir, sesiones largas. Pensarlo desde el principio es mucho más barato que descubrirlo con un cliente delante.
3. Cuida la atención humana. Cada aviso que añades compite por tu atención. Lo que llegue a una persona tiene que ser lo que de verdad necesita su criterio.

Justo de esto va nuestro taller de Spec-Driven Development en la TRG26: de pasar de developers usando IA cada uno por su cuenta a un sistema de equipo con specs, skills y validaciones. Y si quieres ver cómo lo hace el equipo de Claude Code en la parte de revisión, te dejo este otro post.

En onext ayudamos a empresas y equipos a adoptar agentes de IA con método, y buena parte de ese trabajo es justo este: montar el harness que hace que los agentes sean fiables. Si estás en ese punto, escríbeme desde onext.es y lo hablamos.