Harness engineering: deja de cambiar el modelo y arregla el harness

No puedes tocar los pesos del modelo. Pero eres dueño de cada línea de código a su alrededor. Ese código es el harness, y ahí vive casi toda tu ventaja.

Cada semana alguien me cuenta que su agente se volvió más inteligente porque cambió a un modelo más nuevo. A veces es cierto. La mayoría de las veces movió la única variable que no controla y dejó intacta la que sí controla.

Llevo 25 años poniendo código en producción. A fines de 2025 construí solo una fintech cripto de 13 apps con agentes de IA, en 70 días. El caso de estudio tiene los números reales. Esta es la parte que nadie pone en la landing page: el modelo que usé era el mismo que tenían todos. La diferencia no estaba en la inteligencia. Estaba en la estructura que armé a su alrededor. El harness.

Esta es una guía para mejorar ese harness. Si quieres la definición directa primero, lee qué es un harness de agente. Esta página es la práctica de hacer que el tuyo sea mediblemente mejor, de alguien que usa uno mínimo todos los días.

Agente es modelo más harness

Empieza por la definición más limpia que se ha publicado. LangChain lo dijo en cuatro palabras: Agent = Model + Harness. El modelo aporta la inteligencia. El harness hace que esa inteligencia sirva.

Desarma un harness y te quedan cuatro partes, y todo texto serio llega a las mismas cuatro: un loop del agente que sigue llamando al modelo hasta terminar el trabajo, una interfaz de herramientas a través de la cual el modelo actúa, una gestión de contexto que decide qué ve el modelo en cada turno y mecanismos de control que evitan que todo se vaya al barranco.

Fíjate en lo que hay en esa lista. Nada de eso es el modelo. Todo es tuyo. Cuando se habla de “prompt engineering”, se habla de un mensaje. Cuando se habla de “context engineering”, se habla de una ventana. Harness engineering es la capa por encima de ambas: diseña el sistema que reinicia el contexto, pasa el estado de una sesión a otra y verifica el resultado antes de llevarlo a producción. Es la capa con más margen de mejora, y es la capa que casi nadie está construyendo a propósito.

La industria está mejorando los harnesses al revés

Este es el reflejo habitual cuando un harness rinde poco: agregarle cosas. Colgarle otro MCP server. Inyectar más instrucciones en el system prompt. Lanzar un subagent para que vaya a buscar contexto. Conectar un modo de planificación, un servicio de memoria, un router.

Cada una de esas adiciones consume el único recurso que el modelo gasta antes de escribir una sola línea: el context window.

Mario Zechner, que creó el agente de código pi, describió la frustración sin rodeos: los harnesses más populares se volvieron opacos e inestables porque sus system prompts y el contexto inyectado cambiaban a espaldas del usuario. No puedes mejorar lo que no ves. Y no puedes ver un harness que esconde la mitad de lo que le da al modelo.

La solución contraintuitiva, la que de verdad funciona: hacer el harness más chico y más transparente, en vez de más grande y más ingenioso.

Un harness que sí puedes ver

Para mejorar un harness necesitas uno que te quepa en la cabeza. Por eso uso pi, un agente de código open source de earendil-works. No porque tenga más funcionalidades. Porque tiene las mínimas, y no esconde ninguna.

pi, el harness completo de un vistazo

4

herramientas integradasread, write, edit, bash

~150

palabras de system promptno miles de tokens

0

MCP servers por defectoherramientas de CLI en su lugar

BYOK

cualquier proveedorClaude, GPT, Gemini, local

pi le da al modelo cuatro herramientas: read, write, edit y bash. El system prompt tiene unas 150 palabras, con la idea de que un modelo de frontera entrenado en millones de sesiones de programación ya sabe ser un agente de código y no necesita mil tokens recordándoselo. El loop del agente cabe en una página de lógica: llama al modelo, ejecuta las herramientas que pidió, le devuelve los resultados y repite hasta que deja de pedir. Eso es todo.

No es un juguete. La gracia de un harness transparente es que, cuando el agente hace una tontería, ves exactamente cuál de las cuatro piezas la causó y arreglas esa pieza. Intenta hacer eso con un harness que inyecta contexto que no tienes permitido leer.

✗

El harness pesado

1. 01System prompt con miles de tokens de andamiaje
2. 02Tres MCP servers se comen la ventana antes de que escribas
3. 03Contexto inyectado donde no lo puedes inspeccionar
4. 04Subagents que se lanzan invisibles y devuelven un resumen
5. 05Depuras el modelo porque no ves el harness

✓

El harness mínimo

1. 01System prompt de 150 palabras que el modelo ya entendía
2. 02Cero MCP servers, herramientas de CLI con help legible
3. 03Cada token en la ventana es uno que sabes nombrar
4. 04Los subagents son explícitos: llamas a pi desde bash y lo ves trabajar
5. 05Depuras el harness porque puedes leerlo entero

Los tres ejes que de verdad controlas

Cuando ves el harness, mejorarlo deja de ser algo vago. Todo cambio que vale la pena mueve exactamente una de tres cosas: lo que ve el modelo, lo que puede hacer el modelo y lo que sobrevive cuando termina la sesión. Domina esas tres y le hiciste ingeniería a tu harness. Ignóralas y solo estás cambiando de modelo y cruzando los dedos.

Dónde están las ganancias de verdad

1. 01

   Lo que ve el modelo

   El context window es un presupuesto fijo, no una sugerencia. Cada token gastado en boilerplate, output crudo de herramientas o un schema de MCP que el modelo nunca usa es un token que no se gasta en tu problema real. Mejorar el harness empieza por defender la ventana.

   Recorta el system prompt. Filtra el output de las herramientas en el origen.
   Quita los MCP servers que no usas todos los días.

   +
2. 02

   Lo que puede hacer el modelo

   Las herramientas son las manos del modelo. Más herramientas no significa más capacidad. Significa más superficie y más costo en tokens. Un puñado de herramientas afiladas y combinables, más un shell, le gana a una pared de herramientas estrechas. Apuesta por progressive disclosure, no por un menú más grande.

   read, write, edit y bash cubren la mayor parte del trabajo.
   Agrega una herramienta solo cuando bash más una CLI de verdad no alcancen.

   +
3. 03

   Lo que sobrevive a la sesión

   El modelo olvida todo en el momento en que se reinicia el contexto. La memoria no se compra. Se escribe: un archivo de instrucciones, un plan, un log de progreso, commits. El harness que persiste el estado de forma limpia es el que saca adelante trabajo grande.

   AGENTS.md, PLAN.md, un log de progreso, un commit por feature.
   La spec es la memoria que el agente no tiene.

El resto de esta guía es una sección por eje, con los movimientos concretos que hago.

Eje uno: defiende el context window

El context window es el único recurso realmente escaso de todo el sistema, y la mayoría de los harnesses lo gasta como si fuera gratis. Las dos mayores fugas son el system prompt y el output crudo de las herramientas.

La fuga del system prompt es fácil. Lee el tuyo. Cada frase que le dice a un modelo de frontera algo que ya hace bien es una frase que pagas en cada turno, para siempre. La respuesta de pi es un prompt de 150 palabras. El tuyo no tiene que ser tan corto, pero aplica la prueba: si borrar una línea no empeora al agente, esa línea es ruido. Córtala.

La fuga del output de herramientas es más grande y más silenciosa. Un solo git status en un repositorio con mucho movimiento puede ser dos mil tokens. Una corrida completa de tests puede ser veinticinco mil. El modelo no necesita todo eso, necesita la señal, pero un harness ingenuo vuelca el chorro entero en la ventana y lo llama contexto.

Este es el cambio de mayor retorno que puedes hacerle a un harness y casi nadie lo hace, porque los tokens se fugan en un lugar que nunca miras: dentro de los resultados de las herramientas. Pon un filtro ahí y cada sesión, en cada proyecto, se vuelve más barata y más precisa de una vez.

A dónde se va realmente la ventana

Cuatro fugas, cuatro arreglos. Ninguno requiere un modelo más inteligente. Todos son puro trabajo de harness.

Qué se carga	Harness pesado	Harness mínimo
System prompt	miles de tokens, cada turno	~150 palabras que el modelo ya sabía
MCP servers	13k a 18k tokens cada uno, antes de que escribas	ninguno; herramientas de CLI con help legible
Output de herramientas	volcado crudo, 2k a 25k tokens por llamada	filtrado en el origen, 60 a 90% más chico
Turnos viejos	el mismo archivo leído cinco veces	compactados cada tanto, solo el delta

Cuando la ventana igual se llena, la compactación es tu válvula de escape. pi la corre automáticamente cuando la ventana se acerca a su límite, y te da /compact para generar a pedido un resumen de los turnos más viejos, dejando intactos los recientes. El historial completo queda en disco como JSONL, así que no se pierde nada, solo se achica el conjunto de trabajo. Esa es la diferencia entre compactación y amnesia.

Eje dos: menos herramientas, más afiladas

El instinto de agregar herramientas es el instinto que arruina los harnesses. Cada herramienta que registras cuesta tokens por su definición en cada turno, y diluye la elección del modelo con una opción más para equivocarse. La pregunta nunca es “qué herramienta podría agregar”. Es “qué herramienta tiene que existir porque el shell de verdad no puede hacerlo”.

La respuesta de pi es tajante y casi siempre correcta: read, write, edit y bash alcanzan para un agente de código efectivo. Bash es la llave maestra. No es una herramienta. Es cada herramienta de línea de comandos que alguna vez instalaste, envuelta en documentación que el modelo lee cuando la necesita. Eso es progressive disclosure bien hecho. El modelo no carga mil schemas de herramientas en la ventana. Corre --help cuando necesita uno.

Esto no significa que MCP esté mal. Significa que MCP es un costo, y los costos se tienen que justificar. Si un server es clave en tu trabajo diario, déjalo. Si está cargado “por si acaso”, es un impuesto que pagas en cada turno por una capacidad que casi no usas. Mejorar el harness aquí es sobre todo restar: audita tus herramientas, quédate con las que bash no puede reemplazar y corta el resto.

¿Esta herramienta pertenece al harness?

• ✗Anti-pattern:
  ¿Bash más una CLI instalada ya hacen esto?Entonces la herramienta sobra. Bórrala y deja que el modelo use el shell. El help de la CLI es su schema, cargado a pedido.
• ✓Obligatorio:
  ¿Uso esta capacidad en la mayoría de las sesiones?Si la respuesta es sí, una herramienta dedicada o un MCP server se gana su costo en tokens. Si no, es un impuesto por si acaso en cada turno.
• ✓Obligatorio:
  ¿La descripción de la herramienta es corta y sin ambigüedad?Una herramienta que el modelo malinterpreta es peor que ninguna. Nombres precisos y descripciones de una línea le ganan a schemas enormes.
• ✓Obligatorio:
  Cuando corre, ¿puedo ver exactamente qué hizo?Una herramienta cuyos efectos no puedes inspeccionar es un callejón sin salida al depurar. Prefiere lo explícito y visible a lo mágico y oculto.

Cuando de verdad necesitas extender pi, lo haces de forma transparente: un archivo de extensión que registra una herramienta que puedes leer, o invocando al propio pi desde bash como subagent explícito, para verlo trabajar en vez de confiar en el resumen de uno oculto. Por ese camino agregué el único control que extrañaba de OpenCode: ruteo de modelo por fase. Un paquete chico que escribí lee un modelo y un nivel de razonamiento de cada skill y cambia a ellos en cuanto la skill se carga, así que explorar corre en un modelo barato y construir en uno preciso. Es lo que OpenCode llama modes, agregado como un paquete que puedo leer en vez de una feature que me toca esperar. La guía de pi tiene el setup. La regla de Zechner se me quedó grabada: recurrir a un subagent a mitad de sesión para ir a buscar contexto suele ser señal de que no planeaste el contexto de antemano.

Eje tres: dale memoria al agente

Este es el eje que separa una demo de un sistema. El modelo no tiene estado. Olvida todo en el instante en que termina la sesión. Anthropic tiene la analogía que lo vuelve concreto.

Imagina un proyecto de software atendido por ingenieros que trabajan por turnos, donde cada nuevo ingeniero llega sin ningún recuerdo de lo que pasó en el turno anterior.

Ese es tu agente en cada tarea larga. La solución no es un context window más grande ni un producto de memoria más sofisticado. Son archivos deliberados, aburridos y durables que el siguiente turno lee primero. El sistema de archivos, como dice LangChain, es la primitiva más fundamental de un harness, y la memoria es solo el harness usándolo a propósito.

Cuatro artefactos sostienen la carga:

• Un archivo de instrucciones que el harness carga en cada sesión. pi lee automáticamente el AGENTS.md del proyecto y de sus directorios padre. Mantenlo liviano: qué es el proyecto, las convenciones que no son obvias y referencias a todo lo demás. Si quitar una línea no provoca errores, córtala.
• Un plan que vive en disco, no en la cabeza del modelo. pi deliberadamente no tiene un modo de planificación oculto. La planificación va en un PLAN.md o TODO.md que sobrevive a la sesión, queda visible y sigue siendo editable por ti. Un plan que el modelo no puede perder es un plan en el que puedes confiar.
• Un log de progreso que el agente actualiza antes de que termine la sesión y lee cuando empieza. La receta de Anthropic para agentes de larga duración es exactamente eso: leer las notas de progreso y el git log, correr los tests end-to-end y después tomar la siguiente pieza sin terminar. Aburrido. Confiable.
• Commits como memoria. Un commit limpio por feature no es higiene. Es estado. Le da al siguiente turno un historial legible y a ti un rollback cuando un turno sale mal.

El stack que uso

Los principios son baratos. Este es el sistema que uso para volverlos reales: tres capas, cada una elimina un tipo distinto de desperdicio de tokens, mapeadas directo a los tres ejes.

Tres capas, tres tipos de desperdicio

1. L1

   RTK, la capa de herramientas

   Un proxy de CLI que comprime el output de los comandos antes de que llegue al modelo. Es la capa en producción, la que sostiene todo, y la uso todos los días. Es el arreglo del eje uno en la frontera de las herramientas: menos output inútil, entre 60 y 90 por ciento menos en los comandos del día a día.

   git status  → un puñado de tokens
   corrida de tests → las fallas que importan

   +
2. L2

   Compresión, la capa de la conversación

   Entre turnos, colapsar lo que no cambió: el mismo archivo leído cinco veces, el mismo error impreso tres veces, el plan repetido en cada paso. El modelo ve el delta, no toda la transcripción otra vez. Eje uno, un nivel por encima de las herramientas.

   Deduplica lecturas. Reduce los éxitos a una línea.
   Quédate solo con lo que cambió.

   +
3. L3

   Memoria, la capa de conocimiento

   Contexto persistente del proyecto cargado al inicio de la sesión, para que nunca vuelvas a explicar el stack, las convenciones, las decisiones. Es el eje tres conectado al harness en vez de a tus dedos: el agente empieza sabiendo, no preguntando.

   Carga decisiones y convenciones automáticamente.
   La siguiente sesión empieza donde terminó la anterior.

RTK es real y lo uso hoy. Las capas de compresión y memoria son las que estoy construyendo en un único proxy local-first que se ubica entre cualquier agente y el modelo, para que todo el stack viaje conmigo en pi, Claude Code o cualquier cosa que hable con un endpoint compatible con OpenAI. La arquitectura completa y las cuentas de tokens están en el análisis a fondo del costo en tokens. Por ahora el punto es más chico y difícil de discutir: las mayores ganancias en un harness no son ingeniosas, son plomería. Pon el filtro donde se fugan los tokens y cada sesión se abarata de una vez.

El loop es el último tramo

Contexto, herramientas y memoria equipan una sola corrida del agente. El loop del agente es lo que convierte esas corridas en trabajo terminado. Mantenlo simple y haz que verifique.

Un loop de harness que de verdad termina

Entrada

Una feature por construir, planteada como un comportamiento que el sistema debe exhibir

↓

1. READCargar la memoria

   La sesión arranca leyendo el archivo de instrucciones, el plan, el log de progreso y el historial de git. El nuevo turno se entera de lo que hizo el anterior antes de tocar nada.

   ↓
2. LOOPLlamar, actuar, devolver

   El modelo llama herramientas, el harness las ejecuta y devuelve resultados filtrados, y se repite hasta que el modelo deja de pedir. Sin tope arbitrario de pasos. El trabajo terminado es la condición de parada.

   ↓
3. VERIFYProbarlo de punta a punta

   No confíes en lo que el agente reporta de sí mismo. Corre los tests. Anthropic encontró que los agentes verifican features de forma confiable cuando se les pide explícitamente correr pruebas end-to-end reales, incluida la automatización del navegador, en vez de mirar el diff por encima.

   ↓
4. PERSISTCommitear y registrar

   Un commit limpio para la feature, el log de progreso actualizado, el plan avanzado. Ahora la ventana puede reiniciarse sin perder nada, porque el estado vive en disco, no en el contexto.

↓

Salida

Una sesión que termina dejándole a la siguiente todo lo que necesita para continuar

La trampa en esta etapa es dejar que el loop se declare ganador por su propia palabra. Un harness que le pregunta al modelo “¿funcionó?” recibe la respuesta que el modelo quiere dar. Un harness que corre la suite de tests y lee el exit code recibe la verdad. La verificación no es un extra que se agrega al final. Es el mecanismo de control que hace seguro dejar el loop corriendo sin supervisión.

AWS llegó a la misma conclusión a la escala de un ciclo de desarrollo completo. En AI-DLC 2, quien decide qué corre después es un motor determinístico, no el modelo, y una Unit de trabajo solo cuenta como verificada mediante un comando de chequeo que una persona aprobó y un recibo que escribe la propia herramienta. La palabra del modelo no es evidencia. Desarmé ese diseño en AI-DLC 2: qué cambió.

El veredicto: gana lo mínimo

Pon las dos filosofías lado a lado y califícalas por lo que de verdad importa cuando eres quien opera el agente, no quien lo vende.

Harness pesado vs harness mínimo

Harness pesado vs harness mínimo. Winner: Harness mínimo with a weighted score of 53. Scale 1-5 (5 = best).

Criterio (peso)	Harness todo en uno	Harness mínimo
Transparencia (3)	2	5
Costo en tokens (3)	2	5
Control (2)	2	5
Verificabilidad (2)	3	4
Portabilidad (1)	2	5
Puntuación ponderada	24	53

Scale 1-5 (5 = best). Highlighted column: winner by weighted score.

El harness todo en uno no está hecho para mejorarse. Está hecho para impresionar en la primera corrida y para que no mires demasiado de cerca después. El harness mínimo es lo opuesto. Asume que vas a querer cambiarlo, así que te muestra todo y casi no cuesta nada entenderlo. De eso se trata.

Haz esto con tu harness esta semana

No necesitas reconstruir nada. Elige las fugas y tápalas en orden de retorno.

Puesta a punto del harness, mayor retorno primero

• ✓Obligatorio:
  Pon un filtro de compresión en el output de las herramientasLa mayor ganancia individual. El output crudo de los comandos es donde la ventana muere en silencio. Fíltralo en el shell antes de que llegue al modelo y recupera entre 60 y 90 por ciento en los comandos del día a día.
• ✓Obligatorio:
  Lee tu system prompt y corta cada línea que el modelo ya obedeceLo pagas en cada turno. Si borrar una línea no empeora al agente, era ruido.
• ✓Obligatorio:
  Audita tus MCP servers y quita los que están por si acasoQuédate solo con lo que usas en la mayoría de las sesiones. Todo lo demás es un impuesto por turno para un beneficio raro. Reemplázalo con una CLI que el modelo corre desde bash.
• ✓Obligatorio:
  Escribe los cuatro artefactos de memoriaUn archivo de instrucciones, un plan en disco, un log de progreso y un commit por feature. Esto es lo que permite que el agente sobreviva a un reinicio de contexto sin perder el hilo.
• ✓Obligatorio:
  Haz que el loop verifique con tests reales, no con autoevaluacionesConecta el loop para que corra la suite y lea el exit code. Un harness que revisa su propio trabajo es el que puedes dejar corriendo.
• •Opcional:
  Cámbiate a un harness que puedas leer de punta a puntaNo es obligatorio, pero todo lo anterior es más fácil en un harness transparente y agnóstico de proveedor como pi. No puedes ajustar lo que no te dejan ver.

El modelo es un commodity. El harness es tu ventaja.

Todos los laboratorios van a lanzar un modelo más inteligente el próximo trimestre, y cada uno de tus competidores recibe la misma mejora el mismo día. Tu ventaja no está ahí. Nunca estuvo.

Tu ventaja es el harness. Es la única parte del sistema que es completamente tuya, la única que se acumula con tu criterio en vez de reiniciarse con el calendario de lanzamientos de otro. Un modelo modesto en un harness afilado, transparente y bien alimentado va a entregar más que un modelo de frontera en uno inflado, siempre, porque el cuello de botella nunca fue la inteligencia. Fue todo lo que pusiste a su alrededor.

Deja de cambiar el modelo y cruzar los dedos. Abre el harness y arréglalo.

Harness engineering, respuestas rápidas

¿Qué es harness engineering?+

Harness engineering es la práctica de diseñar todo lo que rodea a un modelo de IA y no es el modelo en sí: el loop del agente, las herramientas, la gestión de contexto y la lógica de control y verificación.

Está por encima del prompt engineering, que optimiza un mensaje, y del context engineering, que cura una ventana. Harness engineering diseña el sistema completo que reinicia el contexto, persiste el estado entre sesiones y verifica el resultado.

¿Harness engineering es lo mismo que context engineering?+

No. Context engineering trata de lo que el modelo ve dentro de un solo context window. Harness engineering es la capa por encima.

La gestión de contexto es una de las cuatro partes de un harness, junto con el loop del agente, la interfaz de herramientas y los mecanismos de control. Así que context engineering es un componente de harness engineering, no un sinónimo.

¿Cómo mejoro en la práctica el harness de mi agente de IA de código?+

Trabaja los tres ejes que controlas. Defiende el context window recortando el system prompt y filtrando el output de las herramientas. Mantén pocas herramientas y afiladas, apoyándote en bash en vez de una pared de MCP servers. Dale al agente memoria durable con un archivo de instrucciones, un plan, un log de progreso y commits limpios.

Después haz que el loop verifique su propio trabajo con tests reales. Nada de esto requiere un modelo mejor.

¿Necesito MCP servers para construir un buen agente?+

No. Un MCP server popular puede costar entre 13k y 18k tokens de contexto antes de que escribas nada, y lo pagas lo use el modelo o no. Para la mayor parte del trabajo de código, dejar que el modelo corra desde bash las herramientas de CLI que ya tienes es más barato y más transparente.

Quédate con los MCP servers que usas en la mayoría de las sesiones. Quita los que están por si acaso.

¿Qué es pi y por qué usarlo como ejemplo?+

pi es un agente de código open source y agnóstico de proveedor, de earendil-works. Trae cuatro herramientas, un system prompt de unas 150 palabras y un loop del agente que puedes leer en una página.

Es el ejemplo aquí porque un harness mínimo y transparente es el que de verdad puedes estudiar y mejorar. Cuando algo sale mal, ves qué pieza lo causó, algo imposible en un harness que esconde su contexto.

¿Un harness mínimo rinde menos que uno lleno de features?+

No en los ejes que importan. pi se defiende bien en Terminal-Bench 2.0 con cuatro herramientas y un prompt diminuto, lo que sugiere que el andamiaje verboso entrega menos de lo que cobra.

Un harness mínimo gana en transparencia, costo en tokens, control y verificabilidad. Son justamente las propiedades que te permiten seguir mejorándolo, y las que un harness opaco y lleno de features te quita.