Cuando un agente falla, el reflejo es culpar al modelo. Casi siempre el culpable es otro: el harness.
El harness es todo el andamiaje que rodea al modelo: el código que arma el contexto, expone las herramientas, ejecuta el bucle, aplica los permisos y sostiene el estado entre vueltas. El modelo decide; el harness es todo lo demás. La palabra viene del arnés de un caballo: no es el que corre, pero determina hacia dónde puede correr.
La ecuación incómoda
Un agente en producción es la suma de dos cosas, y solo una la eliges cada semana:
El mismo modelo, con dos harness distintos, rinde de forma radicalmente distinta. Y a la inversa: un harness sólido hace que un modelo más barato sea suficiente para la tarea. Por eso, cuando un agente se comporta mal, el diagnóstico honesto empieza por el harness —es la parte que tú escribiste.
Las cinco piezas
1 · Ensamblaje del contexto. Qué se le entrega al modelo en cada vuelta: instrucciones, historial, resultados, documentos. Es ingeniería de contexto hecha código, y decide más que cualquier prompt.
2 · Herramientas. No solo qué puede hacer el agente, sino cómo se le describe y qué recibe de vuelta. Una herramienta que devuelve 30.000 tokens de JSON crudo es una herramienta mal diseñada, aunque funcione perfecto.
3 · El bucle. Vueltas, presupuesto, detección de estancamiento, reintentos. Es la lección anterior, y vive aquí.
4 · Permisos. Qué puede tocar el agente sin preguntar, qué requiere aprobación y qué está prohibido. Esta pieza no es de producto: es de seguridad, y es la que impide que un agente útil se convierta en un incidente.
5 · Estado y observabilidad. Dónde vive lo que el agente ya hizo cuando se sale de la ventana de contexto —archivos, base de datos, notas— y cómo miras hacia atrás cuando algo falla. Sin trazas no hay depuración posible: solo anécdotas.
La prueba del harness
Hay una prueba muy simple para saber si tu harness sirve: úsalo tú, a mano.
Si tú, con las herramientas que le diste y la información que le entregas en cada vuelta, no logras resolver la tarea, entonces el agente tampoco va a poder. No es un problema de modelo: le estás pidiendo adivinar algo que no está ahí.
Es asombroso cuántos fallos "del modelo" se explican así: una herramienta que devuelve un error genérico en vez del mensaje real, un listado truncado sin avisar, una descripción ambigua entre dos funciones parecidas.
Un harness mínimo
Un harness es una clase aburrida, y eso es una virtud. Toda la inteligencia está en el modelo; aquí solo hay decisiones explícitas:
class Harness:
"""Todo lo que rodea al modelo, en un solo lugar y a la vista."""
def __init__(self, herramientas, permisos, presupuesto=25):
self.herramientas = herramientas # pocas, distintas, bien descritas
self.permisos = permisos # qué se ejecuta sin preguntar
self.presupuesto = presupuesto # tope de vueltas
self.estado = Estado() # memoria fuera de la ventana
self.traza = [] # observabilidad: sin esto no hay depuración
def ejecutar(self, tarea):
for vuelta in range(self.presupuesto):
contexto = self.armar_contexto(tarea) # pieza 1
decision = modelo.responder(contexto, self.herramientas)
self.traza.append((vuelta, decision))
if decision.terminado:
return decision.respuesta
if not self.permisos.autoriza(decision): # pieza 4
if not pedir_aprobacion(decision):
self.estado.anotar("acción rechazada", decision)
continue
resultado = self.invocar(decision) # pieza 2
self.estado.anotar(decision, resultado) # pieza 5
return self.estado.resumen()
Ninguna línea es lista. Todas son decisiones que alguien tiene que tomar, y si no las tomas tú las toma el azar.
Por qué esto importa ahora
Cuando aparece un modelo más capaz, la tentación es reescribir todo alrededor. Suele ser al revés: un buen harness sobrevive al cambio de modelo. Las piezas —contexto, herramientas, bucle, permisos, estado— no dependen de qué modelo esté detrás, y son las que acumulan el trabajo real de tu equipo.
Ese es el argumento de fondo de estas tres lecciones: el prompt es la punta visible, pero el sistema es lo que entrega valor.
Para llevar
El harness es todo el andamiaje que rodea al modelo: ensamblaje del contexto, herramientas, bucle, permisos y estado con observabilidad. Un agente es
modelo + harness, y el harness es la mitad que tú escribes —y la que suele explicar los fallos. La prueba es directa: si tú no puedes resolver la tarea con lo que le entregas al agente, el agente tampoco. Un buen harness sobrevive al cambio de modelo; un prompt ingenioso, no.