El harness no limita a Astra ni a Fable 5.1. Lo que estorba es uno rígido

Hace semanas el harness era dogma. Un sistema que controla al LLM, le pone raíles y lo guía. Sin él, el modelo se perdía. Ahora aterrizan Astra (GPT-6 Astra) y Fable 5.1 (Claude Fable 5.1) y parte de la comunidad ha girado: el harness sobra. Limita a modelos cada vez más cerca de la AGI y los vuelve más torpes.

Ese sentimiento no es postureo. Quien haya visto a Astra o a Fable 5.1 resolver solos lo que antes pedía tres reglas encima entiende de dónde sale. La conclusión, en cambio, no se sostiene.

Lo que sobra es lo que compensaba

Cuando el modelo era menos capaz, el harness tenía que compensar. Reglas que le corregían el tiro. Capas que rellenaban huecos. Traductores entre lo que el modelo entendía y lo que el sistema necesitaba. No era arquitectura. Era muleta.

Con un modelo frontera esas muletas se notan. El modelo ya extrae el dato, ya planifica el siguiente paso, ya escribe un código decente. Encima le cae una capa que vuelve a hacer el mismo trabajo, peor, y le pisa el resultado. El sistema se siente más tonto. La gente mira el harness y dice: fuera.

Ahí está el salto que no cuadra. De que sobren las capas que rellenaban huecos no se sigue que sobre todo el harness. Lo que sigue haciendo falta es el que da estructura: el mapa, no el tutor que le dicta la respuesta.

El harness no compite con la inteligencia del modelo. Le da el mapa para usarla sin perderse.

Quien arranca el harness entero porque Fable 5.1 "ya lo pilla" está tirando el mapa junto con la muleta. A la semana reaparece el mismo caos: contexto hinchado, herramientas descubiertas a ciegas, un toque a red que nadie autorizó. El modelo no se ha vuelto torpe. Le has quitado el sitio.

El modelo no firma cheques ni recuerda lo que no le diste

Un modelo más capaz hace mejor las tareas que le dejas. No decide por ti qué datos son ciertos. No garantiza que no toque la red o el dinero sin permiso. No recuerda lo que no está en su contexto. Eso sigue siendo código.

Ahí se mezcla el debate. El modelo razona. El código garantiza. Si dejas que el razonamiento sustituya a la garantía (ya es tan listo que no hace falta cortarle el acceso) has cambiado de oficio: de ingeniero a creyente.

El harness marca la raya entre lo que el modelo decide y lo que el sistema no puede permitirse dejar a criterio. Confundir las dos cosas produce tanto el harness asfixiante como el "quítame todo y que Astra se apañe".

Dónde un harness bien hecho sí sube el techo

No hay un benchmark que demuestre esto. Es criterio de ingeniería, el que aplico en producción: compactar ventanas cuando crecen, destilar a memorias que solo se activan en el flujo que toca, montar una chuleta de herramientas y poner guardrails concretos. Flexible. Que guía y orienta. Que no encierra.

Compactar es elegir qué se queda

La compactación de contexto no existe para ahorrar tokens por deporte. El problema de la ventana no es que se llene. Es que se llene de ruido. Truncar es cortar por el final y rezar. Compactar es destilar: quedarte con lo que sigue siendo relevante y tirar el resto.

Una porción significativa de una ventana de 128.000 tokens ya son 32.000 tokens. Si esa tira es historial muerto, logs de herramientas y rodeos, el modelo está leyendo basura con cara de trabajo. Compactar antes de que ocurra no le recorta inteligencia: le quita interferencia.

Caber más tampoco arregla el ruido. Un contexto de 200.000 tokens admite 1,56× esa ventana de referencia. Más sitio para la misma morralla no la convierte en señal.

Memorias que solo se despiertan cuando toca

Meterlo todo en la ventana es el atajo perezoso. La información no tiene que vivir ahí siempre. Se destila lo relevante a memorias que solo se activan en los flujos y los turnos donde importan. Eso es hybrid RAG: no un almacén que vomita documentos en cada prompt, sino conocimiento que se despierta cuando el flujo lo pide.

El modelo no paga el coste de ese conocimiento en cada turno. Lo tiene a mano cuando el mapa dice que toca. En producción, eso es la diferencia entre un agente que recupera la ficha del cliente en el flujo de facturación y uno que la arrastra mientras debuggea un log.

La chuleta ahorra el turismo

Un modelo frontera no debería gastar contexto descubriendo qué herramientas tiene. Se lo das hecho. Definir las herramientas y montar un índice (una chuleta, un mapa de dónde está cada cosa) evita la sobre-exploración: ese tira y afloja en el que el LLM prueba tres APIs, lee dos schemas y todavía no ha empezado el trabajo.

La chuleta no le dice cómo pensar. Le ahorra el turismo. El recurso que no gasta buscando el destornillador lo gasta en usarlo.

Guardrails que caben en cuatro líneas

Guardrails: límites concretos para que el modelo no se exceda en determinadas cosas ni alucine. "No toques pagos sin confirmación humana." "No inventes un identificador que no hayas leído." Eso se cumple. Un reglamento de cuarenta páginas se pelea consigo mismo: cada regla nueva entra en conflicto con las anteriores y el sistema empieza a negociarse a sí mismo. El muro no alinea. Fragmenta el criterio.

Lo que de verdad molesta a un modelo top

Hay harness que estorba. Negarlo sería panfleto.

Las capas que re-derivan datos que el modelo ya extrae bien. El modelo hace el trabajo y la capa lo pisa. El resultado sale peor y, encima, más lento.

Las reglas que se acumulan. Cada una nació para tapar un caso. Juntas se pelean. El modelo gasta tokens en reconciliar instrucciones contradictorias en vez de resolver el problema.

La fragmentación del contexto en capas que el modelo necesitaba entero. El síntoma es clásico: ningún componente está roto y el sistema parece más tonto. Le has partido el mapa y le pides que razone con trozos.

Y el vicio de compensar un control malo con otro control encima. Si una capa ya está restando, apilar otra no restaura capacidad. La esconde.

Eso es lo que la comunidad está oliendo cuando dice que el harness vuelve torpes a Astra y a Fable 5.1. No se equivoca en el olor. Se equivoca en el diagnóstico: el problema es el harness rígido, el que re-deriva y fragmenta.

Si quita más de lo que aporta, se rediseña

Un harness bien diseñado es flexible y orientador. Guía. No encierra. La prueba no es cuántas cosas controla. Es cuánta capacidad del modelo deja libre para lo que el modelo hace mejor.

Si una capa quita más capacidad de la que aporta como garantía, se rediseña o se revierte. No se compensa con otra capa encima.

El que no limita la inteligencia del modelo sigue siendo imprescindible. El que se la come, no.