No es el modelo, es el arnés

El mejor modelo de Anthropic no consigue usuarios. Mientras tanto, herramientas más baratas se los llevan a puñados.

Léelo otra vez.

No es que el modelo sea malo. Es de los mejores que hay. Pero le cuesta atraer gente mientras alternativas más económicas prosperan. Y ahí, en esa frase incómoda, está el tema de hoy.

Llevamos dos años preguntando lo que no toca. ¿Cuál es el modelo más potente? ¿Quién saca la siguiente versión? ¿Cuántos tokens de contexto? Preguntas de espectador. La partida se juega en otro sitio.

El modelo es el motor, no el coche

Tener el mejor motor del mundo en el suelo del garaje no te lleva a ningún lado.

Eso es un modelo de lenguaje suelto: potencia sin chasis. Lo que convierte esa potencia en algo útil es todo lo que hay alrededor. Cómo le pasas la información. Qué herramientas le das. Qué límites le pones. A eso los que trabajan de verdad con esto le empiezan a poner nombre: el arnés.

En inglés lo llaman harness, y no es casualidad que la palabra esté apareciendo justo ahora en los sitios donde se cuece esto. El arnés es la estructura que agarra al modelo y lo pone a trabajar dentro de un flujo real: qué lee, en qué orden, con qué instrucciones fijas, con qué herramientas puede actuar y dónde se le cortan las manos.

El modelo es intercambiable. El arnés es lo tuyo.

Un fichero que le dice al agente cómo comportarse

Baja esto a lo concreto, que si no se queda en humo.

Una de las piezas de ese arnés es un simple fichero de texto. En el mundo del código lo llaman «agent.md»: un documento donde le explicas al modelo cómo tiene que trabajar en tu proyecto, qué normas seguir, qué no tocar. No es magia. Es escribir las reglas una vez para no repetirlas mil.

Suena a poco. No lo es.

Es la diferencia entre un becario al que le explicas la casa el primer día y otro al que se lo explicas cada mañana desde cero. Uno acumula criterio. El otro te desgasta.

El modelo aporta la inteligencia bruta. El arnés aporta el criterio de tu casa. Sin lo segundo, lo primero es un genio sin instrucciones dando tumbos por tu vault.

Y aquí aplica el efecto compuesto: cada regla que dejas escrita en ese fichero trabaja para ti mañana, y pasado, y dentro de seis meses. Un «agent.md» bien pensado rinde cada día sin que vuelvas a tocarlo.

Cómo se ve un arnés que lleva meses encendido

Hasta aquí la teoría. Ahora os abro la puerta de mi casa, que es donde esto deja de ser una idea bonita.

En mi vault de Obsidian, dentro de una carpeta llamada «000 NEXUS», vive el sistema de agentes que tengo trabajando. No hay base de datos. No hay panel de control. Hay carpetas y ficheros de texto.

El tablero de trabajo, por ejemplo, es literalmente una carpeta con cuatro subcarpetas: «programadas/», «pendientes/», «en-curso/», «hechas/». Cada encargo es un fichero .md con un frontmatter. Y la carpeta donde está ese fichero es su estado: no hay ninguna propiedad «estado» que mantener sincronizada, porque mover el fichero de carpeta ya es cambiar de columna. Esa operación el sistema operativo la hace atómica. Por eso dos agentes nunca se pisan la misma tarea: el segundo que llega se encuentra el fichero ya movido.

Un script, «lanzador.py», late una vez por minuto. Mira las tarjetas de «pendientes/», lee el campo «pide» de cada una, una frase en sustantivos, tipo «redactar artículo desde selección», y lo casa contra el campo «atiende» de los perfiles de agente que tengo instalados. Si casa, despacha. Si nadie la reclama en quince minutos, el propio lanzador escribe en el registro de la tarjeta por qué se ha quedado ahí parada. Y si un agente se cuelga más de cuarenta y cinco minutos, la tarjeta cuenta como zombi y vuelve al montón.

Ahora la parte que va al grano del artículo. El perfil del agente que escribe estos textos declara esto: «modelo_capacidad: avanzado».

No dice «Claude Opus». Dice avanzado.

La traducción de ese nivel a un modelo concreto vive en otro fichero, «modelos.yml», que ocupa veinte líneas y tiene tres niveles: mínimo, estándar y avanzado, cada uno apuntando a su modelo por cada arnés instalado en la máquina.

¿Qué significa eso en la práctica?

Que el día que salga un modelo mejor, o más barato, o de otra empresa, yo cambio tres líneas de YAML y todo el sistema, los ocho perfiles, las skills, el tablero, los flujos encadenados, sigue funcionando igual. Media tarde. El arnés ni se entera.

Eso es lo que quiero decir cuando digo que el modelo es intercambiable.

Cambiar de motor cuesta media tarde; construir el coche, meses

Pongámoslo en una tabla, que se ve mejor.

	Cambiar de modelo	Construir el arnés
Qué tocas	Tres líneas de un fichero de configuración	Perfiles, límites, rutas, flujos, registros
Cuánto tarda	Una tarde	Meses, y no termina nunca
Quién puede hacerlo	Cualquiera, el mismo día del lanzamiento	Solo quien conoce tu casa
Se puede copiar	Sí, en el acto	No: es tu criterio escrito
Caduca	Cada pocos meses	Se revaloriza con el uso
Qué te deja si lo quitas	Nada	Todo lo demás sigue funcionando

La última fila es la importante. Si mañana me quedo sin el modelo que uso, mi sistema sigue teniendo sus perfiles, sus reglas, sus carpetas-estado y sus flujos. Le pongo otro motor y arranca. Si tuviera lo contrario, el mejor modelo del mercado y ningún arnés, tendría exactamente lo mismo que tiene cualquiera que se acaba de registrar esta mañana.

La pastilla mágica no existe (y duró 24 horas)

Cuando alguien vende que un modelo lo resuelve todo solo, desconfía.

El ejemplo perfecto llegó con la marca de agua de Anthropic. La idea: marcar los textos generados por IA para que el profesorado pudiera cazar las trampas de los alumnos. La gran esperanza contra el copia-pega con IA.

El entusiasmo duró 24 horas.

Una promesa técnica presentada como solución definitiva, desinflada al día siguiente. No porque la tecnología sea mala, sino porque el problema nunca fue de una sola pieza. Los problemas reales no se arreglan con un botón. Se arreglan con un sistema, y los sistemas se construyen despacio.

Lo mismo que el bambú, que pasa años echando raíces bajo tierra antes de que veas asomar el primer tallo.

Los que ya lo han pillado están dentro de los bancos

Mientras el debate público sigue en «qué modelo es mejor», hay gente aplicando lo otro sin hacer ruido.

Los becarios que entran ahora en la banca llegan con la IA bajo el brazo. Y se está dando la vuelta a la tortilla: son ellos los que le enseñan a sus jefes cómo funciona esto. No el modelo en abstracto. El uso. Cómo meterlo en el trabajo de cada día.

Fíjate dónde está el conocimiento que importa. No en quién tiene acceso al modelo más caro, que lo tiene cualquiera, sino en quién sabe montarlo en un flujo que resuelve algo. Esa es la brecha real. No la de los modelos disponibles. La del uso.

Lo que no hay que hacer (esto me lo ha enseñado la cicatriz)

Un arnés no se diseña en una libreta. Se construye a base de romperlo. Os cuento los cuatro errores que más tiempo me han costado, porque os vais a encontrar los mismos.

1. Escribir las reglas en el prompt y no en un fichero. Si el criterio de tu casa vive en la conversación, muere con la conversación. Mañana abres una ventana nueva y estás explicando otra vez lo mismo. Las reglas van a disco. Siempre. Un prompt es una orden; un fichero de perfil es una institución.

2. Filtrar por lista negra en vez de por criterio positivo. En mi tablero, el filtro que decide qué fichero cuenta como tarjeta preguntaba al principio «que no se llame así, ni así, ni así». Cada documento nuevo que metía en la carpeta, un README, una plantilla, reaparecía como una columna basura. Me pasó dos veces antes de darle la vuelta: ahora pregunta en positivo, «es tarjeta lo que declara un campo pide». Un documento nuevo queda fuera solo, sin tocar nada. Define por lo que las cosas son, no por lo que no son.

3. Dar por hecho que las rutas existen. Uno de mis perfiles apuntaba a una skill en una carpeta que no era la suya: faltaba un nivel en la ruta. Ese fichero no se habría encontrado jamás. Estuvo ahí escrito, tan tranquilo, hasta que reorganicé la biblioteca y lo vi. Lo que no se ejecuta nunca, no falla nunca, y por eso no te enteras.

4. No comprobar cómo lee tu sistema lo que escribes. Mi favorito. En las tarjetas programadas hay un campo de hora. Si escribes «hora: 08:00» sin comillas, el parser de YAML no lee «las ocho»: lee una cifra en sexagesimal y te devuelve 480. La tarea no se lanzaba y no había nada roto que mirar. Ahora la plantilla lleva el aviso en mayúsculas: entre comillas siempre.

¿Ves el patrón? Ninguno de los cuatro es un problema del modelo. Los cuatro son problemas del arnés. Y los cuatro se arreglan una vez y quedan arreglados para siempre, que es justo lo contrario de perseguir el modelo del mes.

Por dónde empiezas el tuyo

Vale, Marcos, muy bonito lo tuyo. ¿Y yo qué hago el lunes?

Esto, en este orden. Sin escribir una línea de código.

Uno: abre un fichero de reglas y escribe tres. Solo tres. Las que ya estás repitiendo cada vez que abres el chat. «Escribe en español de España.» «Nunca inventes una cita: si no la tienes, dilo.» «No toques nada fuera de esta carpeta.» Ese fichero es tu primer arnés. Ya lo tienes.

Dos: escribe lo que el agente NO puede hacer. Esta parte se salta todo el mundo y es la que más vale. Mis perfiles llevan una sección de garantías: «solo lectura sobre estas entradas», «no publica en ningún sitio», «escritura limitada a esta ruta». Un agente sin límites escritos es un becario con las llaves de la caja fuerte.

Tres: dale un sitio fijo a las salidas. Que el resultado caiga siempre en la misma carpeta, con el mismo patrón de nombre y la fecha delante. Suena a manía de ordenado. Es lo que hace que puedas encadenar un agente con el siguiente sin pensar: la salida de uno es la entrada del otro porque los dos saben dónde mirar.

Cuatro: obliga a que deje rastro. Que cada vez que trabaje escriba una línea de registro: qué hizo, sobre qué, con qué resultado. En mi sistema es norma obligatoria, y la razón es de una frase: una tarea en curso sin rastro es indistinguible de una tarea colgada. Sin registro no sabes si tu agente está trabajando o muerto.

Cinco: no toques nada hasta que se rompa. Y cuando se rompa, no arregles ese caso: arregla la regla y escribe la cicatriz al lado. Mis perfiles llevan un changelog que dice qué falló y qué se cambió por ello. El del redactor va por la versión ocho. Ocho cicatrices, ocho cosas que ya no me vuelven a pasar.

Eso es el efecto compuesto aplicado a un sistema. Cada fallo que documentas deja de costarte dinero y empieza a rentarlo.

«Ya Marcos, pero el modelo se salta tus reglas»

Me lo dicen mucho, y tienen razón a medias. Vamos con ello.

«Yo puse mi fichero de instrucciones y el modelo se lo pasa por el forro la mitad de las veces.»

Cierto. Pasa. Un fichero de reglas es persuasión, no es una barrera, y un modelo suficientemente creativo encuentra la manera de saltárselo. Por eso el arnés no es solo el fichero. En mi sistema hay cosas que el agente no puede hacer aunque quiera: el estado de una tarea es la carpeta donde vive, así que no puede «marcarla como hecha» sin mover el fichero. Y hay una lista blanca de quién puede crear encargos: un agente raso no está en ella, y si aparece un encargo con un origen que no está en la lista, se bloquea solo. El fichero convence; la estructura obliga. Necesitas las dos.

«Pero es que el modelo nuevo sí que es un salto de verdad.»

A lo mejor sí. Me alegro. Yo cambio tres líneas de YAML y me lo llevo puesto mañana. Tú, si no tienes arnés, te llevas puesto… el modelo. Que es lo que tenías antes, pero más rápido.

«Esto solo vale si sabes programar.»

Mi sistema tiene un script de Python. Uno. El resto son carpetas, ficheros de texto y reglas escritas en español. La parte difícil no ha sido nunca el código: ha sido decidir qué hace cada agente y dónde se le paran los pies. Eso no se programa. Se piensa. Y lo piensas tú, que eres el que conoce tu trabajo.

Desde un sistema encendido, no desde una demo

Yo llevo años con esto funcionando de verdad.

Agentes trabajando sobre mi Obsidian, en un Mac Mini encendido 24/7, con sus ficheros de reglas, sus skills y sus límites. No es una demo de un rato para grabar un vídeo bonito. Es un sistema en producción que se equivoca, se corrige y sigue.

Y desde ahí te digo lo mismo que se ve en los datos: deja de perseguir el modelo del mes. Los modelos van y vienen. Lo que se queda, lo que compone, es el arnés que construyes alrededor: tus reglas escritas, tus flujos, tu criterio metido en ficheros que el modelo lee y obedece.

Cambiar de modelo es cambiar de motor. Media tarde. Construir el arnés es construir el coche. Eso es lo que no te puede copiar nadie.

Así que la próxima vez que salga el titular de «el nuevo modelo que lo cambia todo», hazte la pregunta buena: vale, ¿y qué arnés le vas a poner para que trabaje en lo tuyo?

Ahí está tu ventaja. No en el motor. En todo lo demás.