Si no sos el modelo, sos el harness. Agent = Model + Harness.
Qué es un harness
Un modelo solo lee y escribe texto. Un agente es un modelo que también actúa: busca, edita, llama APIs, decide el siguiente paso. El harness es todo el software alrededor del modelo que hace eso posible y seguro: el loop, las tools, el sandbox, la memoria, los permisos y la observabilidad.
Pensá el modelo como el piloto y el harness como el avión, la torre de control y las reglas del aeropuerto. El piloto decide; sin lo demás, nadie vuela con seguridad.
Por qué importa
A medida que los modelos convergen en capacidad cruda, el harness define el rendimiento real. El mismo modelo, con distinto harness, puede subir o bajar fuerte en benchmarks y en producción.
- Para ingeniería: loop confiable, tools bien cableadas, context management y verificación.
- Para la empresa: guardrails, audit trail, aprobaciones humanas y un harness compartido — no agents sueltos sin gobernanza.
Anatomía de un harness
La mayoría de los harnesses de producción se arman con estos bloques:
- System prompt — instrucciones permanentes: rol, reglas, límites.
- Tools — APIs, código, búsqueda, filesystem; el modelo decide, el harness ejecuta.
- Sandbox — entorno aislado para correr código sin romper el entorno real.
- Filesystem + git — estado durable entre sesiones; superficie de colaboración.
- Memory & context — qué queda en ventana, qué se compacta, qué se recupera.
- Feedback loops — tests, linters, QA, auto-verificación antes de declarar “listo”.
- Guardrails — permisos, allowlists, human-in-the-loop en acciones irreversibles.
- Observability — traces, logs y evaluación continua de corridas.
El loop: Reason → Act → Observe
El núcleo de casi todo agente es un ciclo: el modelo razona, el harness ejecuta la acción, observa el resultado y lo reinyecta al contexto. Se repite hasta completar la tarea — con límites duros de turns, tokens y tiempo.
Patrones que sí importan
1. Agent loop con límites
Un while loop sin presupuesto de turns/tokens puede correr para siempre. Cada pasada: armar request → llamar al modelo → correr tools → chequear stop conditions.
2. Chain of responsibility / proxy en tools
Cada tool call pasa por una cadena: allowlist, path guard, escaneo de secretos, aprobación humana. Las reglas de la organización van primero y fallan cerradas (deny si algo falla).
3. Planner → Generator → Evaluator
Separar quien planea, quien construye y quien evalúa evita el sesgo de “auto-aprobación”. El evaluador (con criterios concretos y, idealmente, browser/tools de verificación) empuja calidad en tareas largas.
4. Guides + sensors (feedforward / feedback)
Guías anticipan el comportamiento (AGENTS.md, skills, specs). Sensores corrigen después (linters, tests estructurales, review). Sin ambos, el agente repite errores o nunca sabe si acertó.
5. Compaction vs context reset
Compactar resume historia in-place. Un reset limpia la ventana y pasa estado vía artefactos estructurados. Según el modelo, uno u otro (o ambos) sostienen tareas multi-hora.
Fallos típicos en producción
- Context rot — la calidad cae a medida que se llena la ventana.
- Tool overload — demasiadas tools al inicio degradan las decisiones.
- Verificación débil — el agente declara éxito sobre trabajo incompleto.
- Sin guardrails — acciones irreversibles sin aprobación.
- Agent sprawl — docenas de agents sin harness compartido ni evaluación.
Cómo lo conectamos en Nodops
Spec Driven Development es feedforward: claridad antes de codear. Tests, review y CI son feedback. Harness engineering es cómo eso escala cuando quien escribe código es un agente — con criterio senior en cada hito.
Cuando el modelo mejora, simplificamos el harness: quitamos andamiaje que ya no aporta. Cuando la tarea supera lo que el modelo hace solo, agregamos planner, evaluator o contratos de sprint. La IA acelera; el harness decide si eso llega a producción con calidad.