Escuché el episodio de Attention Spent (Turing Post) donde la presentadora recoge lo que se habló en la conferencia AI Engineer de Nueva York, y el debate me pareció el mejor resumen del momento actual de la ingeniería de IA. En un extremo, ingenieros quitando instrucciones y orquestación porque el modelo ya hace el trabajo solo. En el otro, equipos construyendo sistemas que coordinan decenas de agentes, les gestionan memoria y permisos, y los dejan trabajar durante días. Los dos tienen razón, y es porque están hablando de dos cosas distintas.

Qué es un harness, en una línea

El harness es el software que rodea al modelo y gestiona su ejecución, sus herramientas, su contexto y sus interacciones con el mundo. El modelo razona y decide; el harness ejecuta. Un "agente" es el sistema completo; un "framework" (LangGraph y similares) es la librería con la que puedes construir el harness — pero no es obligatorio: un loop de 25 líneas que le da bash a un modelo y ejecuta sus comandos ya es un harness mínimo. El episodio lo muestra con el "smallest coding agent" de Focus AI, que son unas 25 líneas de código.

La distinción que ordena el debate

Un ingeniero que pasó por Cursor (y habló de su trabajo en GroqBot) divide el harness en dos capas: el runtime (ejecuta herramientas, gestiona el entorno, guarda estado) y la context orchestration (decide qué información ve el modelo, qué herramientas se le exponen, cómo se representa el trabajo previo). La tesis del episodio es que una de esas capas envejece y la otra no.

El "harness tax": el costo de lo que ya no hace falta

Aquí entra la evidencia. El episodio cita estudios de UC Berkeley, Apple y EPFL que compararon harnesses distintos sobre tareas de código e ingeniería de machine learning. Resultado: los harnesses más sofisticados no produjeron puntuaciones significativamente mejores, pero el costo de completar las tareas varió de forma sustancial. Es el harness tax: instrucciones extra, llamadas de más, interacciones con herramientas innecesarias.

El caso de Cursor lo confirma: en su post sobre eficiencia de tokens, recortaron ~66% de su system prompt, eliminando entre otras cosas las instrucciones que animaban al modelo a usar sub-agentes. ¿Por qué quitar algo que un ingeniero puso a propósito? Porque tras el post-training el modelo ya decidía bien cuándo delegar. La instrucción dejó de aportar.

Y sin embargo, cuando el trabajo pasó de agentes de código a GroqBot (un colega autónomo más general), el mismo equipo volvió a agregar instrucciones y guardrails. Porque ahora el sistema debía decidir cuándo pedir permiso, cómo comunicar progreso sin abrumar y cómo gestionar trabajo a lo largo de días. Eso no era compensar una debilidad del modelo: era una exigencia nueva del alcance.

Lo que no envejece

Tres ejemplos del episodio valen por todo el resto:

• Arca (infraestructura de pagos) no deja al agente "pensando" 24 horas mientras espera que un cliente responda o que llegue un pago. Usa un sistema de eventos: el agente registra interés en eventos futuros y se reanuda cuando ocurren, con wakeups programados para lo que no llega. Lo que se preserva no es la conversación — es el estado de la tarea.
• Anthropic, en su presentación de servicios financieros, separa dos preguntas: ¿el modelo sabe qué acción tomar? y ¿el sistema está autorizado a ejecutarla? Un agente investiga un trade break, propone una enmienda, pero un deterministic hook exige aprobación de un humano antes de modificar la orden. Da igual lo persuasiva que suene la explicación del modelo: el requisito se cumple por software, fuera del modelo.
• Google DeepMind describe blind credentials: en vez de exponer credenciales reales dentro del sandbox, se le dan al modelo valores ficticios y un proxy sustituye las reales al enviar la request.

Y en el otro extremo, DeepSeek (creator mode) con un sistema de ciclo de vida de herramientas permite al agente registrar una utilidad, usarla y eliminarla en runtime. El harness deja de ser un conjunto fijo. La pregunta que queda abierta — quién verifica la herramienta generada, qué permisos recibe — la responde, de nuevo, el runtime.

El aprendizaje que me llevo

Las partes del harness que compensan debilidades del modelo se vuelven obsoletas cuando el modelo mejora. La infraestructura que ejecuta, hace cumplir permisos y preserva estado no desaparece: se vuelve más exigente. Y hay una disciplina asociada que casi nadie tiene: borrar. Los harnesses acumulan parches — el modelo se equivoca, agregas una instrucción; se equivoca de otra forma, agregas un check; el modelo mejora y las instrucciones quedan, celebrando problemas que ya no existen.

No es "el harness está muerto". Es: mide qué aporta cada capa y borra lo que ya no.

Fuente: Turing Post, Attention Spent — episodio "AI Models Are Eating Their Harnesses. Now What?" (2026), con notas de la conferencia AI Engineer de Nueva York. Empresas citadas: Anthropic, Google DeepMind, Cursor, DeepSeek, Arca, Groq y Focus AI.