Como Funciona un Arnes de Agentes IA (Harness Engineering Explicado)

Los modelos van a cambiar 1000 veces y Tornés siempre se va a quedar. Samalman llamó este año el año de los agentes IA. Luego Antropic publicó dos artículos que te dejan claro que el contexto importa más que el modelo. Y Jensen Juan, el CEO de Nvidia, dijo en el GTC que el futuro de la IA no son los modelos, sino los sistemas operativos que lo rodean. Y lo que él llama un sistema operativo tiene otro nombre técnico, el arnés, un nombre que el 98% de las personas que están usando Cloud Code o Codex o Cursor no conoce.

Si te ha pasado que estos agentes un día están haciendo cosas increíbles y al próximo día están funcionando mal o fallando en lo más tonto, este video es para ti porque te voy a explicar tres cosas. Primero, ¿qué es un arnés de los agentes IA? Segundo, ¿por qué importa más que el modelo que estás usando? Y tercero, los tres pilares de el harness engineering o en español la ingeniería de arneses para que puedas empezar a construir los tuyos.

Bien, pero antes te agradecería un montón si me dejas un like en este video, no solamente porque me ayudas a mí y al canal, sino porque también le dices a tu YouTube que este tipo de videos te interesen. La pregunta natural que uno se hace cuando empiezan a fallar los modelos es como este modelo no es lo suficientemente bueno y la respuesta corta es no. Las grandes mejoras que han habido en la inteligencia artificial en este año no han venido solamente por modelos más potentes, sino que han venido en gran parte por las mejoras en los entornos donde se están ejecutando estos modelos. Y esos entornos son los que hoy conocemos como los arneses.

Si ya has visto mi video de agentes IA explicado en 18 minutos, esto te suena. Pero en grandes rasgos vimos que las plataformas como Cloud Code o Codex o OpenClot eran como las carrocerías que están alrededor, pero que tenían un motor atrás, el motor siendo el modelo de inteligencia artificial y la carrocería siendo el entorno donde se están ejecutando. Bueno, hoy día vamos a abrir esa carrocería y vamos a ver qué es lo que hay adentro y por qué puede hacer que funcione tan bien el motor y por qué esta puede ser incluso más importante que el motor que elijas.

El nombre del arnés viene de la analogía más literal que puede existir. Un arnés. Literalmente las riendas, la silla que le pones a un caballo, te sientas y lo montas es el arnés. es lo que te permite poder controlarlo. Tu modelo de inteligencia artificial es el caballo. Es potente, es rápido, pero el modelo por sí solo es un caballo alocado. Es capaz de generar miles y miles de distintas líneas de código. Es capaz de tomar decisiones completamente impredecibles y terminar al final en caminos que no son los que probablemente querías llegar a el arnés es todo lo que se construye a su alrededor, alrededor del caballo, para que vaya en la dirección correcta.

Técnicamente, un arnés está compuesto por cuatro cosas. El contexto que le das al modelo, las herramientas a las que puede acceder, la memoria que le permite recordar entre sesiones y el sistema de verificación que comprueba si lo que hizo fue bien hecho. Si te suenan estas cuatro piezas es porque la cubrimos en el video de los agentes IA. La diferencia es que ahí vimos que eran. Hoy vamos a ver cómo se construyen juntas y arman algo formal que se conoce como el harness engineering.

Y aquí viene una parte que el 98% de las personas no entienden. Y digo 98 simplemente por tirar un número. Pero es que los modelos ya cambian cada 3 meses. Hoy sale el Opus algo punto algo. En tres meses sale la nueva versión, después la nueva versión, después sale algo de otra empresa, de otro modelo que funciona mejor, luego sale algo de Google, luego sale algo de Open AI, después de Antropic y si construyes tu sistema encima de un modelo, cada vez que va saliendo uno nuevo, tu sistema entero va quedando obsoleto. Tienes que reaprender, tienes que reescribir todo, porque no es simplemente llegar y cambiar el modelo. Pero si llegas y construyes todo alrededor de un arnés que está bien orquestado y bien armado, ese arnés es completamente tuyo porque los archivos son tuyos, el repositorio es tuyo, son las reglas que tú escribiste con los procesos que tú definiste. Y dentro de ese arnés, el modelo es intercambiable. Hoy lo conectas a Cloud, mañana lo conectas a Gemini, después estás con los de Open AI, después un modelo open source que corre en tu máquina, da igual, pero el arnés no está cambiando, solamente está cambiando el cerebro. Por eso es super importante esta frase, los modelos cambian cada 3 meses. Tu arnés no. Y ese cambio mental de pasar a obsesionarte en vez de el modelo, a obsesionarte con el arnés es lo que separa ese 2% del 98%. es la jugada más segura que podemos hacer al largo plazo.

Y aquí hay un caso que ilustra esto perfectamente. Versel, la empresa que hace V0, esta plataforma o software que construye interfaces y herramientas y aplicaciones con IA, que era como otra versión de Bolt o de Lovabol, tiene otro agente que se llama D0. La D viene de data, es una gente que únicamente se dedica a hacer queries y analizar grandes cantidades de data. En la primera versión, los ingenieros de Versel hicieron lo que parecía más lógico en ese momento. Le dieron a la gente bastantes herramientas que fueron hiperespecializadas, específicamente 16, para ir haciendo distintos queries como queries SQL o funciones para conectarse a bases de datos específicas, funciones que marcaban al modelo un paso a paso de cómo pensar y en fin, la lógica detrás es lo importante era si es que le damos las herramientas perfectas no se va a equivocar. Cuento corto pasó lo contrario. En el momento que le quitaron el 80% de las herramientas, le dejaron solamente el acceso a Bash y a un sistema de archivos básicos, herramientas que ya existen en cualquier computador. Y el resultado fue tres veces más rápido, gastando un 47% menos en tokens y el éxito de la gente subió de un 80 a un 100%. Según el propio artículo de Verel, este agente que es más simple le ganó a ese agente más complejo en todas las pruebas. Y la lección aquí es bastante clara. Un arnes que está muy cargado con información va a funcionar peor. Un arnes mínimo gana siempre a un arnés inflado y esto no aplica solamente en verel, sino que es un patrón que se repite. La gente piensa que mientras más herramientas, más reglas, más instrucciones, va a tener un agente más potente, pero en realidad es al revés.

Y aquí también nace otro problema de los que llevamos usando agentes por bastante tiempo y es que cuanto más tiempo vas usando la más tonta se vuelve. No sé si te ha pasado, pero empiezas una sesión de Cloud Code o de Codex, vas avanzando, las primeras horas van bien y de repente el código se empieza a romper, empieza a olvidar ciertas cosas, empieza a contradecirse. Y hay un issue que está justamente abierto en GitHub sobre todo esto. Habla de la degradación que empieza en un 40%. La gente recomienda directamente limpiar esa ventana, comprimirla una vez que llegues al 48% o directamente iniciar una nueva sesión. Y la degradación, de hecho, podemos ver acá que empieza incluso antes, empieza cercano al 20%, esto pasa con los modelos que tienen ventanas hasta de 1 millón de tokens o incluso más en un futuro, que tengan más espacio no significa que van a ser mejores, sino que tiende a degradarse incluso y suele ser peor.

Entonces, ¿cómo evitamos la degradación y que pase este tipo de cosas? ¿Cómo evitamos que esa ventana de contexto se sature? Aquí viene la solución de sacar la memoria fuera del modelo. Y la gente que está construyendo buenos arneses lo hace justamente así. El modelo no carga toda la conversación. El modelo solamente carga lo esencial, un punto de entrada. Y todo lo demás lo va devolviendo en archivos del proyecto, archivos de texto, una base de datos, avances del proyecto, carpeta de progreso y lo que el modelo va necesitando lo va a buscar. Lo que ya hizo lo va anotando y lo va dejando afuera. Entonces, su ventana de contexto se va manteniendo limpia. Anota lo que tiene que hacer aún y las cosas que ya van haciendo en un archivo. Esto es el primer pilar y vamos a verlo bien.

Llegamos a los tres pilares del harness engineering y el primero es la base de todo y es que el harness vive en tu código. No es una aplicación, no es magia externa, son archivos, archivos que están guardados en una carpeta, nada más. Estos archivos se interrelacionan entre sí y se referencian distintos archivos entre ellos. Esto es lo que distingue a la gente que usa Cloud Code o Codex a un nivel superficial versus a la gente que está armando sistemas de verdad. Si viste mi video de agentes en 18 minutos, probablemente recordarás un archivo que se llama el agents.markdown agentsmd o el cloud md si es que usas cloud code. Y ese archivo de ahí es el punto o el archivo de entrada de tu agente. Esto es lo primero que se inicia y se carga antes de iniciar cada sesión. Es lo primero que lee antes de iniciar cada sesión. Es como el archivo base. Es la descripción que le das a un nuevo empleado cuando empieza a trabajar contigo. ¿Quién eres? ¿Qué haces? ¿Qué vas a hacer? ¿Dónde están las cosas? ¿Qué tienes que hacer antes? Pero lo importante es mantenerlo corto, ya que se carga siempre antes de cada sesión, por ende, te consume un contexto. Entonces, estar precargando constantemente todo ese archivo, un archivo muy extenso, ya vimos que no nos convenía y lo ejemplificamos claramente con el caso de Vel, que le cargaron muchas herramientas. Entonces tenemos que mantener este agents.md corto. Y aquí viene algo clave. El archivo se llama agents.md porque es estándar. Es un estándar abierto y cualquier agente serio del 2027 va a entender ese archivo y esa es una muy buena práctica para nocarte solamente a un arnés. Ya no pasemos y no los hagamos como Cloud MD. Si estás en Cloud Code, usa el HNCMD, funciona exactamente igual, pero puedes ir cambiando entre arneses. Eso es lo importante. No te casas con una herramienta, tu arnes es portable, pero el agent no es lo único, también hay más archivos. Tiene un script de iniciación que verifica que las cosas estén en buen estado antes de empezar. Por ejemplo, va a correr test, verificar si es que hay archivos rotos, valida que la estructura es la que la gente espera y si algo falla para, o sea, no empieza a trabajar si es que el sistema está roto, que eso también es algo muy importante. Tiene un archivo de tareas, puede ser un Jason, un linear, un markdown, da igual. La mayoría de los casos es un JSON, pero también puede ser un linear, da igual. Pero aquí están las cosas que tenemos que hacer. ¿Cuáles son los próximos pendientes, las tareas que tenemos que realizar? tiene distintos estados, los pendientes, progreso, etcétera. Lo que nos lleva también a la siguiente carpeta, que es la carpeta de progreso. Y aquí es donde la gente va guardando lo que va haciendo. Resultados de cada paso, decisiones que se han ido tomando, archivos que tocó. De esta manera, cuando vas lanzando agentes nuevos, no tiene que leer todo el proyecto de nuevo, sino que va allá, entiende en qué se quedó y después retoma desde ahí. Lo clave que tenemos que entender es que el arnés no es un wrapper que envuelve al modelo, es un repositorio que ordena al modelo, que le da la estructura al modelo, que le da un patrón de navegación.

Y esto nos lleva al segundo, pilar. No ocupes un agente para todo. Aquí hay un patrón que Antropic publicó hace poco en su archivo de Here iss how we built our multiagent research system. Y el resumen es que en un sistema de investigación tenemos que tener un agente líder u orquestador que va mandando a distintos y pequeños subagentes a hacer distintas tareas. Te explico un poco la lógica. Supongamos que tenemos que hacer una tarea supergre, por ejemplo, implementar un nuevo feature completo en un código. Si le pides solamente a una agente que haga todo, ese agente va a leer el código, va a planear, va a escribir, va a corregir. Y no solo se va a demorar mucho porque fue secuencial, sino que para cuando termine su ventana de contexto va a estar copada, va a estar al 90% y no va a estar pensando bien. Y ya vimos previamente qué es lo que pasa cuando se llena una ventana de contexto. En cambio, si tenemos un agente líder que es capaz de separar y delegar distintos roles, entiende la tarea grande. Después, un agente que se dedica solamente a leer código, un agente implementador que solamente escribe código nuevo y un agente revisor que verifica que las cosas que se están haciendo se hicieron bien. Cada uno va a estar con un contexto limpio, un contexto nuevo. Cada uno va a tener una tarea concreta y después la va a ir escribiendo en la carpeta progress y le van reportando, ¿verdad?, a este roadmap, por así decirlo. De esta manera, el siguiente agente puede leer y cargar todo sin tener que necesariamente ver todo, sino retomar desde exactamente ese punto. Al final es como una empresa común y corriente, o sea, tenemos un jefe que delega y pequeños agentes o personas que van ejecutando. Este sistema también lo cubrimos un poco más en el video que lancé de mi equipo multiagente con OpenCloud, donde voy mostrando cómo delegué y tengo distintos subagentes que cumplen distintos roles, pero el patrón se puede aplicar para cualquier caso. Cloud Code lo puede hacer, OpenCl lo puede hacer, Codex lo puede hacer y el concepto es lo que importa, no la herramienta en sí. Por eso, un solo agente que hace todo siempre va a perder contra un equipo multiaente.

Y el tercer pilar, que es probablemente uno de los más difíciles de implementar y darse cuenta si se está haciendo bien, es la verificación. La inteligencia artificial te puede mentir y no te miente con una mala intención, sino que una entrada puede ser completamente verosímil para la IA, ya que puede tener una vectorización muy parecida. Si los vectores son muy similares, podría creer que esto es cierto, porque al final, cuando traducimos todo esto y vectorizamos cada palabra, pasa por un proceso de embeding que se transforman en puntos, en un espacio vectorial y ocurren una serie de ecuaciones matemáticas, que es maravilloso. Pero el resumen, para no entrar tanto en lo técnico es que se transforman en números y después vectores y después se hacen operaciones vectoriales y después te devuelve y te da una palabra. Entonces puede darte a veces respuestas que parecen ciertas pero que no lo son realmente ya simplemente son bastante verosímiles. Entonces cuando una gente te dice, "Ya terminé este feature, todo está en orden, todo está funcionando bien", no le creas. Ese es el problema más difícil de trabajar con agentes. Es que a veces el código se ve bien, parece convincente hasta que lo pruebas y a las 3 horas te das cuenta que realmente estaba roto. Y la solución aquí no es desconfiar todo el tiempo, claramente no, la mayoría de las veces lo tiene bien. La solución es que el arness mismo sea capaz de verificar el trabajo y verificar tiene varias capas. Tests automatizados que podemos correr. Linter y type check es que es una interfaz. Podemos usar el mismo Playwrght para autodiagnosticar, que literalmente abre un navegador personalizado y empieza a comprobar el flujo. De hecho, este es el sistema que yo más estoy usando al día de hoy. Literalmente le pido que abra un Playwrite y empiece a hacer los diagnósticos, encuentre los errores. Ahí tengo un video de Playwright con Cloud Code que puedes ver está s super bueno y explico en profundidad cómo usar Playwrght, pero aquí ya me estoy desviando y encima de eso tienes un agente revisor que es un subagente de los que ya hablamos que lee el código, que ejecuta los tests y que va aprobando o rechazando estos cambios. Entonces puede aprobar o rechazar directamente los trabajos del implementador. Y el agente no termina porque dice que terminó. El agente termina porque el arnés fue capaz de validar que efectivamente terminó. Y aquí pasa algo también que es superbonito, porque como todo estos son archivos que están en una carpeta, si el revisor detecta que hay cosas mejorables, puede ir mejorando el arnés mismo, puede actualizar el agent MD, puede ir agregando nuevas reglas, entonces el arés se va automejorando a sí mismo. Y esto es lo que se conoce como un self improving loop. Lo cubrí también en el video de agentes IA en 18 minutos y es la base de por qué un agente que lleva contigo al final bastante tiempo va a ir mejorándose continuamente si es que no le populamos el contexto y no lo inundamos de contexto innecesario.

M llegado a este punto probablemente te estás preguntando, bueno, Benja, entonces, ¿cuál es el mejor arnes que puedo usar? ¿Uso cloud Code, Codex, cursor? Y aquí viene la respuesta que la mayoría de la gente no entiende y es que cada uno de estos son arneses. Cada uno es una implementación distinta de todo lo que acabamos de ver. Cloud Code es un arnés, tiene su forma de organizar el agents.m, lo llama cloud.md, pero tiene sus formas. Codex es otro arnés, son los mismos tres pilares, distinta implementación. Cursor es otro arnés, también es un poco más enfocado quizás en el editor. Open Close también es un arnés abierto, autoinstalable, sí puedes usar distintos modelos, pero al final si entiendes los tres pilares, saltarte entre plataformas es bastante trivial. Si no entiendes los pilares, vas a tener que estar reaprendiendo cada nueva plataforma constantemente. Y eso es exactamente lo que hace la diferencia. La gente está obsesionada con cuál es el mejor agente, cuál es el mejor modelo, pero se está haciendo la pregunta equivocada. La pregunta correcta sería, ¿está mi arnés bien construido? Porque si mi ar está bien construido, hoy día puedo estar usando Cloud Code. Pero si mañana Open AI decide lanzar GPT8, me quiero cambiar a su entorno y me voy a cambiar a Codex, pero quizás el día de pasado mañana va a lanzar Antropic Opus 9 y va a mejorar y me voy a querer cambiar para allá, pero si mi Arnese está bien construido, mi sistema va a seguir funcionando exactamente igual. El arnés es 100% tuyo, el caballo lo estás alquilando y esa es la mentalidad al final que tenemos que tener para poder apalancarnos con certeza de que estamos construyendo sistemas sólidos.

Aquí van tres casos para poder comenzar a construir tu arness hoy día, no en 6 meses. Primero, escribe tu agents.m. Crea un archivo que se llama agents.m en la raíz de tu proyecto. No tiene que ser perfecto. Abre Cloud Code o Codex y dile, "Hazme preguntas de estilo entrevistas para construir nuestro Agents MD." Quiero que sepas qué hace este proyecto, qué reglas tiene que seguir, cómo va a funcionar y la gente te va a empezar a hacer preguntas y después ya a tener tu agenc MD listo. Importante eso sí, que no pase las 200 líneas porque si no ya empieza a tener mucho, mucho ruido y ya vimos qué pasa cuando hay mucho contexto. Recordemos que este se inicia en cada nueva sesión a lo más arriba. Si es muy largo, obviamente vaya a gastar más tokens y vaya a llegar antes a ese límite de tokens o a ese límite de tokens o a ese punto en verdad donde se empieza a degradar la calidad de las respuestas.

Segundo, agrega un script de verificación, es decir, init.sh. Vas a crear este archivo init.sh o lo que sea en tu caso, pero se va a encargar de verificar si es que está el proyecto en buen estado antes de comenzar. Hay algo bastante simple. corre los test necesarios, verifica los agents.m, valida la estructura básica y le dices al final también a tu agente agents.md, tipo ejecuta elinit.sh ch antes de empezar a hacer cualquier cambio. Si falla, no continúes, pide ayuda. Y de esta manera podemos asegurarnos de que no va a estar en un loop constante en un proyecto que está roto, que no está funcionando. De esta manera estás evitando que tu agente esté trabajando horas en un proyecto roto, ya que el arnés es capaz de detectar el problema antes que el agente.

Y el paso tres es separar tu agente en roles. No tengas un agente que hace todo, crea por lo menos tres. un agente líder que se encargue de orquestar, un agente implementador que escriba código y un agente revisor que lo vaya revisando. Es importante, a cada gente le puedes asignar un modelo. Supongamos que te interesa que el que escribe código no use un modelo tan caro, pero el que audita sí use un modelo un poco más caro, así puedes también ahorrarte un poco más. En Cloud Code estos agentes van apareciendo bajo la carpeta agents. En codex es casi lo mismo y la herramienta cambia, pero el patrón es el mismo. Y cada vez que lance un subagente, también asegúrate de que vaya escribiendo como el resultado de un archivo, no en el chat, sino en un archivo, por ejemplo, en progress. De esta manera, el siguiente subagente puede ir leyendo este contexto antes de poder y lanzar y investigar quizás la misma información que ya fue investigada.

Y todo esto que acabas de ver es la base. Son tres pilares clave. El repositorio del sistema orquesta varios agentes y verifica todo. Son tres pasos: el agent markdown, el script de verificación y la separación de roles. Y una sola mentalidad, construye el arnés y no te preocuparás más del modelo. En los próximos meses, los modelos van a ir actualizándose constantemente. La pelea por quién está sacando los mejores modelos hace que vayan bajando los costos y vayan siendo cada vez más inteligentes. Los modelos van a cambiar 1000 veces y Tornés siempre se va a quedar. Eso es lo que la mayoría de la gente no entiende. Están persiguiendo siempre los modelos y cada vez que sale algo nuevo están empezando de cero. Mientras tanto, la gente inteligente está enfocándose en construir buenos arneses y cuando sale un modelo mejor, simplemente le cambian el cerebro y siguen con lo suyo. Esa es la diferencia.

Si te gustó este video, agradecería un montón si es que le dejas un like aquí abajo. No sabes cuánto me sirve. Le metimos bastante esfuerzo. También así le dices a tu YouTube que este tipo de videos te gustan y te los empieza a sugerir cada vez más. Te agradecería mucho también si me dejas un comentario. Todo tipo de interacción me sirve muchísimo, muchísimo. Y no sé si te diste cuenta, pero mencioné bastante durante este video e hice referencia a uno de mis videos anteriores que se llama Agentes y 18 minutos. Ahí entramos en profundidad en cada uno de estos elementos. ¿Qué es el agent loop? ¿Cómo funciona el contexto? La memoria, las herramientas, cómo referenciamos archivos entre sí. El video que tienes que ver después de este es el agente Gan 18 Minutos. Te lo voy a dejar abajo en la descripción. Este video es la arquitectura, pero ese video, el agente G en 18 minutos es toda la base teórica que tienes que conocer.

También se le interesa conocer un espacio donde estamos construyendo agentes IA constantemente con cinco sesiones semanales, concursos y videos ascrónicos y la comunidad más activa de automatizaciones, agentes de inteligencia artificial, hispanohablante, recomiendo que te des una vuelta por Imperio. Aquí tenemos varios casos, o sea, gente que está eh vendiendo automatizaciones como Reito, que cerró dos clientes recién, otro caso como Vincent aquí, que también cerró otro cliente. Yo vendiendo con IA. Fíjate acá, Einar construyó una aplicación desde un barco. José que lanzó su primera aplicación y entre todos en verdad como que es un sistema bastante lindo como de retroalimentación donde estamos constantemente viendo qué es lo que se está construyendo en el mundo real, compartiendo nuestros logros, vamos ayudándonos entre todos y no solamente es como un lugar donde publicamos nuestras cosas, sino que también tenemos estas cinco sesiones en vivo donde puedes entrar y construimos entre todos en conjunto, además de clases, soporte y un lugar que en verdad es genial, es genial. Estoy super contontento con la comunidad que se ha formado. Date una vuelta por Imperio si es que estás serio con construir agentes para vender o para implementar en tu negocio.

Dicho y hecho eso, espero verte en Imperio y si no te veo en Imperio, te veo en este video de agentes ya en 18 minutos que recomiendo que veas. Ya nos vemos hasta la próxima.