Por qué los agentes capaces siguen fallando
Dale a un modelo de primera una tarea real y se descarrila igual. El problema no es la inteligencia. Es que la inteligencia sin un sistema alrededor no tiene dónde apoyarse.
Un piloto de élite pierde igual la carrera si nadie cambia los neumáticos, lee la telemetría o decide la estrategia. El coche es rápido, pero una carrera es un sistema. Un modelo capaz es el piloto. El harness es el equipo de boxes, la telemetría y las reglas que convierten la velocidad bruta en una vuelta terminada.
La brecha de capacidad no es una brecha de inteligencia
Los benchmarks miden a un modelo respondiendo una pregunta acotada de una sola vez. El trabajo real es lo contrario: es abierto, dura horas, toca decenas de archivos y depende de un runtime que el modelo no ve. Un modelo que arrasa en el benchmark puede aun así dejarte el build roto, porque el benchmark nunca le pidió mantener cien piezas coherentes durante una sesión larga.
Así que la pregunta interesante no es «qué modelo es más listo» sino «qué sistema hace fiable a este modelo en este código». Ese sistema es el harness.
flowchart LR M["Modelo capaz"] --> T["Tarea real, horas, muchos archivos"] T --> Fail["Se descarrila, contexto perdido, falso done"] M2["El mismo modelo"] --> H["Dentro de un harness"] H --> Win["Resultado fiable y verificado"] linkStyle 1 stroke:#e0493f,stroke-width:2.5px,color:#e0493f linkStyle 3 stroke:#2ea043,stroke-width:2.5px,color:#2ea043
Los fallos se repiten
Entre equipos y herramientas aparecen una y otra vez los mismos fallos:
- Contexto perdido, el agente vuelve a deducir o contradice decisiones ya tomadas cuando la conversación se reinicia.
- Victoria prematura, «¡Listo!» con el build en rojo y media tarea sin tocar.
- Extralimitación, le pides un arreglo y reescribe tres módulos en un diff irrevisable.
- Ceguera de runtime, sin logs ni terminal en vivo, adivina por qué el programa se comporta como lo hace.
- Sin durabilidad, el portátil se duerme, el proceso muere y las tareas largas nunca tienen sus horas.
Ninguno se resuelve con un modelo más grande. Se resuelven con estructura alrededor del modelo.
Por dónde empieza Agentum
Agentum es un control plane en Rust que convierte el harness en infraestructura. Tus agentes son CLIs corrientes, Claude, Codex, Gemini, Opencode, lanzados en paneles tmux en un host que controlas, así que cerrar la tapa no mata el trabajo. Un watchdog por sesión vigila cada panel, y el Harness Engine avanza una función a la vez detrás de una puerta de verificación que decide el «hecho», no el modelo.
El resto de estas lecciones toma los fallos de arriba uno a uno y muestra la solución estructural, y cómo Agentum implementa cada una en concreto.
Puntos clave
- Un mejor modelo sube el techo; no elimina los fallos, esos son estructurales.
- La unidad útil de fiabilidad es el sistema alrededor del modelo, no el modelo solo.
- Los fallos recurrentes (contexto perdido, falso «listo», extralimitación, ceguera, sin durabilidad) tienen cada uno una solución concreta.
- Agentum hace real el harness: sustrato tmux, acceso por túnel seguro, bucle con verificación.
Ejercicios
- Identifica el fallo. Toma tu última sesión que salió mal y etiquétala con uno de los cinco fallos de arriba. ¿Qué hueco estructural lo permitió?
- Nombra el sistema que faltaba. Para ese fallo, escribe una frase con la pieza del harness que lo habría atrapado.