A mi hija le encantan los Squishys (he tenido que buscar cómo se escribía, no te voy a engañar). Son juguetes blandos de poliuretano que puedes achuchar, apretar y retorcer, y al rato vuelven a su forma original. Los hay de mil formas, desde una simple tableta de mantequilla hasta muñecos de toda clase.

Resulta que el otro día estaba jugando con un squishy en forma de Pokémon que le traje de China y que, de tanto apretar, tiene una grieta que le atraviesa el cuello. Ella había visto en un vídeo de YouTube Kids que hay gente que se dedica a arreglarlos, así que me pidió que le dijéramos a la IA que nos "previsualizara" el arreglo.

Y empezamos una serie de prompts, dictados por ella, en los que aprendió lo importante que es dar una orden precisa a una IA. Que lo que no dices, se lo inventa. Que un prompt es un contrato con letra pequeña, y la letra pequeña la rellena el otro. Después de diez o doce intentos conseguimos que Gemini entendiera lo que quería y tuvimos la foto del squishy arreglado.

Doce putos intentos. Para una foto de un Pokémon de goma.

Te cuento esta anécdota porque hoy voy a hablarte de las tripas de mi empresa. De esas cosas que muchos considerarían know-how supervalioso y guardarían bajo llave. Yo lo considero conocimiento. Y ya sabes cómo va eso por aquí: el conocimiento se comparte o se pudre.

Ya estamos usando la IA para administrar servidores en producción. Sí. El momento llegó hace poco, pero ha llegado. Todavía no dejamos a los agentes hacer de todo, pero ya hacen cosas. En máquinas de verdad, de clientes de verdad. Y cuando esto llega, llegan los problemas.

Porque añadir una capa de IA a tu empresa no es fácil. De hecho, creo que es más difícil que incorporar "personas humanas". A una persona nueva le explicas las cosas una vez, la ves trabajar, la corriges, y a la tercera semana ya sabe que la versión de PHP no se toca en viernes ni aunque venga Dios a pedirlo. A un agente se lo explicas hoy y en la siguiente sesión ha vuelto a nacer. Y en un entorno donde romper algo significa problemas serios, la libre interpretación no es una opción.

Mi hija podía permitirse doce intentos, un servidor de producción, no.

Aquí es donde entra un concepto que este año se ha puesto de moda y que, por una vez, se ajusta como un guante a lo que estamos viviendo: el harness.

Harness es arnés en español, y la palabra ya lo dice casi todo. El arnés de un caballo no lo hace más fuerte: hace que toda esa fuerza vaya a algún sitio en vez de dispersarse por el campo. El arnés de un escalador no lo hace mejor escalador: hace que el error no sea el último. Tracción y seguridad. Dirección y límite. Justo las dos cosas que le faltan a un modelo de lenguaje suelto en tu infraestructura.

En términos técnicos, el harness es todo lo que rodea al modelo y no es el modelo: las herramientas que puede usar, los permisos que tiene, la memoria que arrastra entre sesiones, quién revisa lo que hace y qué pasa cuando la caga. El término lo puso de moda Mitchell Hashimoto, el de HashiCorp, Terraform y mi adorado ghostty, con una idea que deberíamos tener enmarcada en cada CPD: cada vez que un agente se equivoca, no corrijas el error, corrige el entorno para que ese error no pueda repetirse. Ni un prompt más bonito ni un modelo más listo, simplemente estructura. Y lo dice un tío que era escéptico y se obligó a hacer su propio trabajo dos veces, a mano y con agentes, hasta saber qué podía delegar, no un vendedor de cursos.

OpenAI y Anthropic tienen ya sus artículos de ingeniería sobre el tema y la cosa tiene hasta genealogía: primero fue el prompt engineering (cómo le hablas), luego el context engineering (qué sabe) y ahora el harness engineering (qué le dejas hacer y cómo te enteras).

Y aquí viene lo que más me gusta de toda esta movida, porque encaja con lo que llevo años dando la brasa desde esta newsletter: el modelo es la pieza que menos importa. Es la que cambia cada seis meses, la que te venden cada semana como revolucionaria, la que mañana será otra. El harness es tuyo, y lo que es tuyo es lo único que de verdad controlas.

¿Y cómo lo estamos haciendo nosotros? Pues básicamente hemos recurrido a lo de siempre: git, usuarios, nodos de control y mucha vigilancia. Ya te gustaría que fuera más sexy, a mí también, pero es lo que hay...

Con las "personas humanas" llevamos tiempo haciendo esto con Semaphore y playbooks de Ansible. Un técnico no entra a un servidor a hacer lo que le dé la gana: lanza un playbook desde una interfaz, con unas credenciales que no ve, contra un inventario concreto, y queda registrado quién lanzó qué, cuándo y contra qué. Si te fijas, un playbook es un harness para humanos: no te deja hacer lo que quieras, te deja hacer lo que está escrito, probado y versionado.

Pues esto es la evolución de ese playbook a algo mucho más potente. Pero hay un salto, y es el que lo cambia todo:

    🧐 - "¿Pero eso no es Ansible con un chatbot delante?"

    👻 - "No. El playbook ejecuta lo que le dices. El agente decide qué hay que ejecutar. Y por eso hay que atarlo más corto."

Seguramente la primera opción de cualquiera, y la nuestra también, hubiera sido instalar el agente en cada servidor y a correr. Es lo intuitivo: el agente donde está el trabajo. Pues no. Cada instalación guarda su propia memoria en el home del usuario y esa memoria no se sincroniza con nada. Con diez servidores tienes diez cerebros aprendiendo cosas distintas, corrigiéndose por separado, y a la tercera semana no se ponen de acuerdo ni en cómo cojones se llama tu empresa.

Y hay algo peor, que me hizo ver (para mi vergüenza) un hilo de Twitter que prometía montar una empresa de un millón de dólares con un equipo de bots. Quítale el millón y el humo y quedaba una verdad incómoda: los agentes escriben su propia memoria mientras trabajan. Es su superpoder y su trampa, un error que se guarda una vez deja de ser un error y pasa a ser un dato. Y los datos se repiten.

La memoria no es un checkbox, la memoria es mantenimiento, es estructura.

Así que le dimos la vuelta. Los agentes viven donde siempre vivió Semaphore: en los nodos de control, con usuarios de servicio propios, credenciales propias, los permisos justos para su trabajo y, de momento, los mismos playbooks como herramientas. Y lo que es verdad sobre nosotros no vive en la cabeza de ningún agente: vive en un repositorio, en ficheros Markdown, en nuestro git y no en la nube de nadie, versionado como cualquier otro código y desplegado a los nodos como se despliega el resto.

Te cuento qué hay dentro, que es menos de lo que parece:

• Un MEMORY.md con quiénes somos: cómo trabajamos, qué estándares seguimos, qué no se negocia. Cabe en cuatrocientas palabras y lo lee todo agente antes de mover un dedo.
  
  
• Un DECISIONS.md que es un registro de decisiones: fecha, qué se eligió y por qué. Lo nuevo pisa lo viejo y nadie reabre una decisión cerrada sin avisar antes a un humano. La mitad del caos con agentes viene de que vuelven a discutir cosas que ya estaban decididas.
• Una carpeta agents/ con un fichero por rol: una frase que dice qué hace, una línea que dice qué no toca jamás y la lista corta de herramientas que tiene permitidas. Un agente para todo es un agente que recuerda de todo, y recordar de todo es la forma elegante de no recordar nada.
  
  
• Una carpeta skills/ con lo que enseñamos una vez y queremos que se recuerde siempre. Lo que explicas en un chat se muere cuando se enfría la conversación. Lo que está en un fichero, no.
  
  
• Y por cliente o por proyecto, otro MEMORY.md más pequeño con el contexto de ese entorno concreto. Lo que un agente aprende en una sesión (el estado de hoy, el error de este despliegue) se queda en el nodo, sucio y local, sin contaminar lo que vale.

Nada de esto es ciencia, es un repo de git con ficheros de texto. Lo difícil no es escribirlos, es mantenerlos vivos.

Para eso hay dos reglas y un bicho raro. La primera regla: todo lo que despliega, publica o gasta pasa por borrador y por una persona que aprueba. Como a un técnico junior recién llegado, exactamente igual: "es una IA" no es un rol de seguridad. La segunda: cuando corregimos algo, no lo corregimos como la excepción de hoy sino como la regla de siempre, "siempre X, nunca Y", y va al repositorio para todos los roles a la vez.

Y el bicho raro que aún no funciona como debe, pero estamos en ello: un agente cuyo único trabajo es revisar cada semana la memoria de los demás y proponer qué se borra. Sí, un agente vigilando a otros agentes. Ya sé cómo suena, pero guardar sabe cualquiera; lo difícil es borrar.

La métrica que de verdad miramos es una sola: cuántas veces vuelve un agente a repetir algo que ya le corregimos. Si ese número no baja, el arnés es demasiado débil.

Y ahora la verdad, porque a esta newsletter no venimos a vender humo:

    🤔 - "¿Y esto lo tenéis en producción?"

    👻 - "En producción, sí. En un puñado de servidores, no en todos. Y con la mano en el botón."

Esto está en bragas. Continuamente cambiamos algo del repositorio cuando descubrimos un agujero nuevo. Que es, si lo piensas, exactamente lo que decía Hashimoto: el harness no se termina, se engorda a base de errores. Si te lo cuento ahora, a medio hacer, y no dentro de un año con el lacito puesto, es porque el camino es la parte interesante. El resultado ya te lo contarán otros en LinkedIn, con carrusel.

¿Que si esto lo hemos inventado nosotros? Ni de coña. Es lo que cualquier equipo de sistemas decente lleva veinte años haciendo con los humanos: mínimo privilegio, una sola fuente de verdad, revisión antes de tocar producción, documentación que sobrevive a la persona. Lo único nuevo es que ahora el junior no tiene vergüenza, no se cansa y no duda nunca.

Acojona. Razones de más para atarlo corto.

Y vuelvo al squishy, que se me olvida. Lo bonito de un squishy es que lo aprietas todo lo que quieras y vuelve a su forma. Eso es exactamente lo que queremos de un agente: que cada sesión empiece con la misma forma, la que está en el repositorio, por mucho que la anterior lo haya estrujado. La grieta del Pokémon salió por apretar siempre en el mismo sitio sin que nadie mirara, la memoria de un agente se agrieta igual: por donde nadie revisa. Nosotros ya tenemos a alguien mirándole el cuello cada semana.

Mi hija necesitó doce intentos para que la IA entendiera qué quería, el harness es escribir esos doce intentos una sola vez, meterlos en git, y que ningún servidor tenga que volver a pasar por los otros once.

¡Feliz Domingo!