El agente no es el modelo

Durante un año, cada vez que un agente no rendía, la respuesta fue la misma: cambia el modelo o reescribe el prompt. Las dos cosas importan. Ninguna explica lo que pasó en 2026.

OpenAI construyó un producto interno de un millón de líneas sin que una persona escribiera el código. LangChain subió a su propio agente del puesto 30 al top 5 en Terminal Bench sin cambiar el modelo. Anthropic mostró el mismo modelo dentro de un envoltorio que se veía bien y no funcionaba, y dentro de otro que sí funcionaba. Los tres apostaron por lo mismo: el sistema que rodea al modelo.

A eso se le empezó a llamar harness engineering. En julio quedó por escrito, con código detrás. En octubre ya no es una opinión.

La fórmula

Un agente es un modelo más un harness. El modelo genera texto. El harness es todo lo demás: el ciclo que vuelve a llamar al modelo, las herramientas que ejecuta, el contexto que le arma, la memoria que persiste lo que el modelo no puede recordar, los límites que le pone, la superficie por donde se extiende. Sin ese runtime, el modelo es solo texto que sale rápido.

La fórmula es corta, y alcanza para ordenar una decisión de compra. Si dos productos usan el mismo modelo y uno entrega y el otro no, la diferencia no está en la marca del modelo. Está en el puesto de trabajo que lo rodea.

El paper que le dio nombre

En julio de 2026, cuatro investigadores de Wavestone AI Lab publicaron Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents (arXiv:2609.00006). El paper no rankea agentes. Lee el código fuente de once sistemas de producción — Claude Code, Codex CLI, Gemini CLI, Mistral Vibe, OpenHands, Aider, Mini-SWE-Agent, Hermes, Pi, OpenCode, OpenClaw — más Omnigent, el primer meta-harness de Databricks, como punto de contraste. Cuatro millones de líneas de Python, TypeScript y Rust diseccionadas.

El resultado: siete subsistemas canónicos, trece observaciones transversales y un catálogo de veintinueve patrones de diseño recurrentes. Dos ausencias sobreviven a la expansión del corpus: ningún runtime importa un framework agéntico de propósito general (LangChain, LangGraph, AutoGen), y ninguno recupera código con embeddings vectoriales. El campo corre sobre loops async escritos a mano y recuperación determinista: ripgrep, tree-sitter, glob, archivos Markdown autodescubiertos.

Un benchmark envejece con el modelo de la temporada. Una anatomía envejece cuando la arquitectura cambia, y eso tarda más.

Los siete subsistemas

Todo harness, desde las 100 líneas de Mini-SWE-Agent hasta el millón de líneas de Codex CLI, toma posición sobre los mismos siete subsistemas. A veces esa posición es ausencia deliberada.

1. Agent loop. El ciclo central que alterna inferencia del modelo con ejecución de acciones. Mini-SWE-Agent usa un while lineal sobre una sola herramienta bash. OpenHands usa una conversación event-sourced sobre un log persistente, con acciones en paralelo. El loop es la columna vertebral. Lo demás se monta sobre él.

2. LLM integration. Habla los protocolos del proveedor, ensambla el prompt, gestiona caché, thinking y routing. Mini-SWE-Agent tiene una llamada LiteLLM con una plantilla Jinja. Hermes tiene cinco transports propios, 29 perfiles de proveedor y un catálogo server-delivered. La integración decide qué ve el modelo antes de cada paso.

3. Tools & actions. Define qué puede hacer el agente. La edición de archivos es la herramienta rey. Mini-SWE-Agent tiene bash y nada más. Claude Code tiene 43 herramientas tipadas con carga diferida: el agente no carga el schema de todas al inicio, sino que busca la que necesita en el momento. Codex ejecuta tool calls como código V8. La superficie de herramientas absorbe la mayor parte del esfuerzo de ingeniería en todo harness maduro.

4. Memory & context. Raciona la ventana de contexto y persiste conocimiento entre turnos y sesiones. Mini-SWE-Agent usa historial lineal sin límite. Codex mantiene un pipeline de memoria cross-session escrito por el propio agente. Gemini CLI destila contexto con un grafo. Este subsistema decide qué recuerda el agente y qué olvida, y esa decisión pesa más que la mayoría de los cambios de modelo.

5. Safety & permissions. Decide qué corre, qué pregunta y qué está prohibido. Mini-SWE-Agent tiene límites de costo y pasos. Codex tiene cuatro capas: reglas Starlark declarativas, hooks de lifecycle, un LLM guardian que aprueba acciones ambiguas, y un sandbox de OS nativo (bubblewrap en Linux, sandbox-exec en macOS, AppContainer en Windows). Defensa en profundidad: cada capa falla independientemente.

6. Orchestration. Coordinación de sub-agentes. Aider no tiene orquestación por diseño: es single-agent. Claude Code usa composición recursiva. Omnigent orquesta once harnesses de vendor detrás de una API, sin implementar su propio loop de edición — es evidencia sobre harnesses, no un harness.

7. Extensibility. Config, hooks, skills, plugins, MCP. Mini-SWE-Agent usa structural typing en Python. Pi hace que todo sea una extensión. Codex distribuye plugins vía marketplace. Skills (9/11 sistemas) lidera sobre MCP (8/11) en adopción: un skill enseña al agente qué puede hacer sin inflar el contexto activo, porque se carga completo solo cuando el agente lo necesita.

La evidencia que no se puede ignorar

Los tres episodios del inicio no son anécdotas. Tienen números detrás.

OpenAI: un millón de líneas, cero código manual. Un equipo de tres ingenieros (que creció a siete) construyó un producto interno de Electron con ~1M líneas de código en cinco meses. Todo — lógica, tests, CI, documentación, tooling — fue escrito por Codex. ~1.500 PRs mergeados a 3.5 PRs por ingeniero por día. OpenAI estima que tomaron un décimo del tiempo manual. Los ingenieros pasaron de escribir código a diseñar entornos, especificar intent y construir feedback loops. Después de GPT-5.2, el humano se volvió el cuello de botella: cada ingeniero manejaba 5-10 PRs al día y estaba exhausto. Así nació Symphony, un orquestador en Elixir — lenguaje que eligió el modelo, no el equipo — que automatiza el ciclo completo: crear worktree, escribir código, pasar CI, rebasear, y poner en cola de merge. El humano solo aprueba o rechaza al final. Symphony se publicó como spec, no como paquete: un Ghost Library que cualquier agente puede reconstruir localmente.

LangChain: +13.7 puntos sin tocar el modelo. deepagents-cli arrancó con 52.8% en Terminal Bench 2.0 usando GPT-5.2-Codex con un prompt genérico y herramientas estándar. El equipo iteró solo tres variables: system prompt, herramientas y middleware. Un prompt estructurado alrededor de un loop plan→build→verify→fix llevó el score a 63.6%. Un "reasoning sandwich" (xhigh para planning y verification, high para implementation) lo empujó a 66.5%. Del puesto 30 al top 5. La mayor ganancia vino de hacer que el agente verificara su propio trabajo contra la especificación, no contra su propio código. Sin ese cambio de comportamiento en el harness, el modelo habría seguido confirmando que "se ve bien" sin probar nada.

Mismo modelo, harness distinto, resultado distinto. En agosto de 2026, Sydney Lewis publicó Same Model, Different Harness: Different Coding-Agent Results (arXiv:2608.26218). Mismo modelo, misma tarea, misma ventana de contexto. Solo cambió cómo el harness compacta resultados de herramientas viejas y detecta trabajo estancado. Con ventana ajustada (20K tokens), la fracción fail-to-pass subió del 28% al 49% y las soluciones completas de 43 a 72. Un solo cambio de gestión de contexto. El modelo no se tocó.

En junio de 2026, Vats y Golev encontraron que el mismo modelo consumía hasta 41 veces más tokens en OpenCode que en Goose, con solo 0-8 puntos porcentuales de diferencia en pass rate. Y los modos de falla eran específicos del harness, no del modelo: Goose falla razonando en círculos (REASON), OpenHands falla sobre-verificando (VERIFY + MAX_TURNS), OpenCode falla idleando (TIME + no-action turns). Mismo modelo, distintas patologías.

Arena.ai testeó 21 pares modelo-harness y encontró que Claude Fable 5 resuelve 97.8% en Claude Code, 96.7% en Codex y 96.7% en Pi — pero Claude Code cuesta el doble que Pi. El "provider-native" no garantiza el mejor emparejamiento: en 9 de 12 comparaciones, un harness alternativo logró la mejor tasa de éxito.

Lo que un harness no es

El paper traza tres fronteras que vale la pena conocer.

No es un framework. Un framework (LangChain, AutoGen, CrewAI) es una librería que importas para construir un agente. Un harness es un runtime dentro del cual trabajas. La distinción era limpia en 2025. En 2026 se está disolviendo desde ambos lados: los harnesses shippean SDKs importables, y los frameworks shippean harnesses. Pero la diferencia inicial de ownership persiste: en un framework, el loop, la recuperación de errores, la gestión de contexto y el límite de permisos son tuyos. En un harness, los heredas del vendor. Ese trade — flexibilidad cedida a cambio de un runtime que funciona hoy — es el contenido real de la distinción.

No es un evaluador. El "harness" de SWE-bench envuelve un agente para correrlo contra tareas. Un agent harness envuelve un modelo para que actúe. Misma palabra, dirección de wrapping opuesta.

No es un orquestador. Un orquestador coordina harnesses desde arriba sin implementar su propio loop de edición. Omnigent orquesta eleven harnesses de vendor — cinco de ellos en el paper — y no tiene loop propio. Es evidencia sobre harnesses, no uno de ellos.

El giro de plataforma

La tesis central del paper: en el primer semestre de 2026, el harness completó un giro de herramienta a plataforma. Tres señales lo documentan.

Harnesses como SDKs. Claude Agent SDK, openai-codex SDK, OpenHands Agent SDK, Pi packages, OpenCode SDK — nueve sistemas shippearon interfaces de programación. El harness dejó de ser algo que usas y se convirtió en algo que otro programa puede llamar.

Frameworks que shippean harnesses. Deep Agents (LangChain), Pydantic AI Harness, Strands harness-sdk (AWS) — los frameworks reconocieron que el valor está en el runtime, no en la librería, y empezaron a distribuir runtimes completos.

Meta-harness. Omnigent orquesta harnesses de vendor como backends intercambiables detrás de una API, reimplementando las partes caras y arbitrajando las propietarias. ACP (Agent Communication Protocol) shippea en seis sistemas con un nuevo rol: harness hosting. OpenHands puede correr Claude Code, Codex o Gemini CLI como backends intercambiables.

El análisis longitudinal del paper — los mismos ocho sistemas diffados entre abril y julio — muestra convergencia volviéndose imitación: Codex adoptó el vocabulario de hooks de Claude Code de forma verbatim y shippeó un importer para sus sesiones. OpenHands adoptó el formato de plugin de Claude Code. La política de comportamiento migró de prosa en prompts a configuración declarativa.

De la anatomía al corte

El modelo piensa. El runtime ejecuta, recuerda lo que el modelo no puede recordar y frena cuando hay que frenar. La pantalla donde se conversa no es el agente. Si la puerta tiene sus propias herramientas, hay dos cerebros. Uno sobra.

Esto no es una metáfora. Es arquitectura. El modelo genera una proposición. El harness la verifica, la ejecuta, guarda el estado, y decide si puede seguir o si necesita parar. Sin ese ciclo, el modelo es solo texto que sale rápido.

El while-loop es pequeño. Lo difícil es qué entra en contexto, cómo se filtran las acciones, cómo se exponen las herramientas, cómo se resumen las fallas, cómo se reanudan las sesiones, y cómo los sub-agentes se mantienen contenidos.

Verificación externa

"Listo" es una hipótesis. La evidencia es el entregable, el criterio de bien hecho escrito antes de empezar, y la persona que firma lo consecuente. Los harnesses maduros ya no aceptan el cierre del modelo como prueba. Nosotros tampoco.

Un modelo que dice "tarea completada" no completó nada. Completó la oración. La diferencia importa cuando lo que está en juego es un deploy en producción o un documento que alguien va a firmar.

El loop plan→build→verify→fix que LangChain descubrió no es un hallazgo de prompt. Es una restricción de harness: el agente debe verificar contra la especificación original, no contra su propia impresión de que el código "se ve bien". Sin esa restricción codificada en el runtime, el modelo vuelve a su default: cerrar temprano.

Soberanía: dónde vive el runtime

La soberanía no es un adjetivo del modelo. Es dónde vive el runtime, dónde vive el expediente y quién puede apagar una acción. Un agente detrás de un endpoint ajeno es cómodo. No es un puesto de trabajo que la empresa pueda auditar.

Cuando el expediente de tu cliente vive en un servidor que no controlas, y el agente que lo procesa corre en una infraestructura que no puedes apagar, tienes un servicio. No tienes soberanía.

La distinción harness vs framework tiene una lectura soberana: si el harness es de un vendor, la soberanía sobre el loop, la memoria, los permisos y las extensiones la tiene el vendor. Si el framework lo construyes tú, la tienes tú — pero la estás manteniendo. Los harnesses open-source minimalistas (Pi: "There are many agent harnesses, but this one is yours") abren una tercera vía: adoptas un runtime maduro y lo owns como código propio.

Cómo lo leemos en Athanor Tech

AT-Nexus parte de esa evidencia y no de un chatbot. Es una plataforma soberana para roles expertos: el mismo método para muchos clientes, expediente aislado, despliegue bajo control de quien confía el dato. La inteligencia artificial propone. El humano decide.

De la anatomía nos quedamos con el corte, no con el oficio del programador. El harness es lo que transforma un modelo conversacional en un agente de trabajo. Sin harness, hay chat. Con harness, hay agente.

La diferencia la pagamos todos los días: cada skill que AT-Nexus carga es un SKILL.md que el agente lee solo cuando lo necesita (deferred loading, el patrón que 9/11 sistemas adoptan). Cada expediente vive en Neo4j bajo nuestro control (memory, subsistema D4). Cada verificación corre antes de cerrar (verify-on-stop, el guard que mplementa en el loop). Cada permiso es deny-first con escalación humana (safety, subsistema D5). Las siete decisiones del paper son las siete decisiones que tomamos al construir la plataforma.

El 90-line scaffold

El paper cierra con un scaffold de 90 líneas que implementa los siete subsistemas en su forma mínima y realiza diez de las dieciocho recomendaciones de diseño. Es el esqueleto que nunca desaparece: el centro invariante de los once sistemas analizados.

Production harnesses agregan profundidad de safety, gestión de ventana de contexto, orquestación y superficies de extensión sobre ese esqueleto. El esqueleto no se reemplaza. Se rellena.

Lecturas

• Barbaste, Darrigol, Vu, Wiltberger. Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents.arXiv:2609.00006. Julio 2026.

• Lewis. Same Model, Different Harness: Different Coding-Agent Results. arXiv:2608.26218. Agosto 2026.

• Vats, Golev. The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable. KDD 2026.

• OpenAI. Harness Engineering: Leveraging Codex in an Agent-First World. Febrero 2026.

• LangChain. Improving Deep Agents with Harness Engineering. Febrero 2026.

• Arena.ai. HarnessTax: How Much Does the Harness Matter for Coding Agents? 2026.

• Meng et al. Agent Systems with Harness Engineering: A Systematic Survey. 2026.

• From Model Scaling to System Scaling: Scaling the Harness in Agentic AI. 2026.