# Harness Engineering: por qué la arquitectura del agente importa más que el modelo Canonical URL: https://luisalejandro.org/blog/posts/harness-engineering-por-que-la-arquitectura-del-agente-importa-mas-que-el-modelo Published: 2026-08-04 Categories: Desarrollo de Software e Inteligencia Artificial Estoy hasta la coronilla de ver el mismo ciclo repetirse en Twitter, LinkedIn y los foros de desarrollo. Sale un nuevo modelo de lenguaje al mercado, la gente corre a probarlo con tres refactorizaciones de juguete, y de inmediato empiezan las proclamas triunfalistas: *"¡Este modelo va a reemplazar a los ingenieros senior!"*. Dos semanas después, cuando intentan meter ese mismo modelo a resolver problemas reales en repositorios con miles de archivos y código legacy, el agente entra en un bucle infinito de ejecuciones fallidas, borra lo que no debe o simplemente colapsa. Y la culpa, según el desarrollador promedio, siempre es del "modelo que alucina". Seamos sinceros: el problema fundamental no está en el LLM. Durante mis años trabajando como desarrollador remoto desde Venezuela para startups internacionales, aprendí a golpes que mi capacidad para entregar resultados no dependía únicamente de mi intelecto, sino de la estabilidad de la infraestructura de luz e internet que me rodeaba. Esa restricción operativa me obligó a especializarme en automatización, contenedores Docker y tuberías de CI/CD para garantizar confiabilidad a toda costa. Del mismo modo, en el desarrollo autónomo, la verdadera diferencia entre un prototipo frágil y un sistema de producción no es la potencia del modelo, sino el **harness engineering** y la **infraestructura de agentes ia** que sostienen la ejecución. Es esa arquitectura la que determina si el agente navega un proyecto complejo o perece en el primer SyntaxError, tal como se aprecia en la estructura envolvente del sistema. ## El mito del modelo omnipotente: ¿Por qué cambiar de LLM no resolverá tus agentes rotos? Existe una fascinación casi infantil con la idea de que la solución a cualquier fallo de un agente es "esperar a la siguiente versión del modelo". Pensamos que si cambiamos entre Claude y DeepSeek, por arte de magia el **rendimiento de agentes llm** se duplicará y los bugs desaparecerán. Es un autoengaño cómodo porque nos exime de hacer nuestro trabajo como arquitectos de software. La prueba no está en sus papeles, está en sus acciones. Cuando analizamos [los datos del benchmark SWE-bench](https://arxiv.org/abs/2310.06770) —que mide la capacidad real de resolver *issues* verdaderos en repositorios de GitHub— descubrimos un patrón revelador: configuraciones con modelos numéricamente "inferiores" pero respaldadas por una sólida **infraestructura de agentes ia** superan con frecuencia a modelos mucho más grandes empaquetados en *scripts* lineales y primitivos. ¿Y por qué sucede esto? Porque un modelo por sí solo no sabe cómo aislar un proceso, no entiende cuándo un *linter* le está advirtiendo sobre una variable no definida y no tiene idea de cómo recuperar un estado limpio si un comando en la consola falló. Como señalan [investigaciones recientes de NVIDIA](https://developer.nvidia.com/blog/six-agent-harness-capabilities-for-higher-model-performance/), la forma en que el sistema renderiza el contexto, gestiona el estado persistente y ejecuta las herramientas influye radicalmente en la efectividad y en la factura final de API del proyecto, independientemente del motor de inferencia que elijas. ## Anatomía de un harness: La diferencia entre Prompt, Context y Harness Engineering Para construir sistemas que no colapsen al primer tropezón, la gente necesita entender las capas de abstracción con las que estamos jugando. Aún veo a desarrolladores experimentados confundir estos términos, metiendo todo en la misma bolsa del "prompting": 1. **Prompt Engineering:** La capa más superficial. Consiste en redactar instrucciones, asignar un rol (*"Eres un desarrollador experto en Python..."*) y ajustar el tono del texto. Es importante, sí, pero es solo el guion. 2. **Context Engineering:** La gestión estratégica de la ventana de contexto. Implica decidir qué fragmentos de código, documentación y logs de error entran en la ventana de contexto en cada iteración para evitar el ruido y el desperdicio de tokens. 3. **Harness Engineering:** El arnés o armazón de software. Es la **Agent Architecture** real. Es el código que toma la intención del modelo, valida los parámetros, ejecuta las herramientas en un entorno aislado, captura las salidas del sistema, gestiona los reintentos y mantiene la durabilidad del proceso. Para comprender cómo se relacionan estas disciplinas, resulta útil visualizar la separación de responsabilidades en capas superpuestas. Aquí es donde la magia ocurre. Un *harness* robusto no le pide al modelo que "recuerde" cómo interactuar con el sistema operativo; le proporciona un canal estandarizado. La adopción de especificaciones abiertas como el *Model Context Protocol* (MCP) ha sido un paso gigante en esta dirección, permitiendo que cualquier agente se conecte a servidores de contexto y herramientas sin necesidad de reimplementar la rueda cada vez. Si ya has experimentado la diferencia entre escribir *prompts* a mano y [configurar correctamente tu entorno en Cursor](https://luisalejandro.org/blog/posts/programar-con-ia-sin-volverte-tonto-mi-guia-completa-para-instalar-y-usar-el-cursor-ide), sabrás que la experiencia de usuario cambia por completo cuando la herramienta maneja el contexto por ti. El *harness engineering* lleva ese mismo principio al código del backend que orquesta tus propios agentes. ## La columna vertebral: Estado persistente, checkpoints y durabilidad de ejecución El Talón de Aquiles de la mayoría de los agentes caseros es la amnesia. Un flujo lineal tradicional ejecuta una llamada al LLM, recibe una función a ejecutar, la procesa y reinyecta la respuesta en un arreglo de mensajes en memoria. Si el script se interrumpe por un tiempo de espera en la red, un límite de tasa de la API o un error imprevisto, todo el progreso de la sesión se destruye. Para manejar proyectos complejos, necesitamos hablar de **estado persistente en agentes**, **checkpoints en flujos de agente** y **durabilidad de ejecucion agentes**. El agente debe ser capaz de modificar un archivo, ejecutar las pruebas unitarias, detectar que tres pruebas fallaron, guardar un punto de control (checkpoint) de su árbol de razonamiento en una base de datos y continuar desde allí sin reevaluar todo desde cero. La diferencia entre una orquestación lineal efímera en memoria y un flujo directed con persistencia estriba en la resiliencia ante fallos. Mientras que un bucle ingenuo pierde todo el progreso de la sesión si la API se cae o se agotan los tokens en medio del proceso, una arquitectura basada en grafos con estado persistente guarda puntos de control inmutables de cada paso. De esta manera, si la ejecución colapsa en la octava iteración, el sistema puede reanudar el trabajo exactamente desde el último nodo válido, como demuestra el flujo de persistencia gráfica. Frameworks como [orquestadores con estado como LangGraph](https://www.langchain.com/langgraph) permiten definir grafos cíclicos donde cada nodo representa una etapa del razonamiento y donde el estado se persiste automáticamente. Esto no solo garantiza que el agente pueda recuperarse de fallos de red; también permite la intervención humana (*human-in-the-loop*) para aprobar cambios críticos antes de que el agente envíe sus cambios al repositorio. ## Autorrecuperación y patrones de orquestación: AutoGen e infraestructura de agentes ¿Qué hace un programador humano cuando un comando falla en la consola? Lee el rastreo de pila (*stacktrace*), comprende el error, revisa la sintaxis y modifica la línea de código afectada. ¿Qué hace un agente mal diseñado? Envía el mismo código defectuoso tres veces seguidas al modelo hasta que se agota el límite de reintentos. Para alcanzar una verdadera autorrecuperación, la **autogen infraestructura agentes** debe integrar bucles de retroalimentación activa y patrones de validación antes de devolver el control al usuario. Los [patrones de orquestación documentados por Anthropic](https://www.anthropic.com/research/building-effective-agents) demuestran que separar las responsabilidades mediante esquemas como *evaluador-optimizador* o *orquestador-trabajador* incrementa dramáticamente la confiabilidad de los resultados. En lugar de depender de un único agente monolítico que intenta hacer la planificación, la edición y el control de calidad al mismo tiempo, delegamos la verificación a componentes especializados: * **El Trabajador (Worker):** Genera el código o la modificación propuesta en una rama aislada. * **El Entorno (Sandbox):** Un contenedor ejecutable donde se corren *linters*, analizadores estáticos y pruebas unitarias. * **El Evaluador (Evaluator):** Examina los logs de error del contenedor. Si detecta fallos de sintaxis, no culpa al modelo principal: le devuelve únicamente el fragmento de código relevante junto con la línea exacta del error para que corrija la hipótesis. Las [investigaciones sobre arquitecturas multiagente como AutoGen](https://arxiv.org/abs/2308.08155) respaldan este enfoque conversacional y especializado. Cuando varios agentes con roles delimitados colaboran sobre una infraestructura de herramientas compartida, la tasa de alucinación cae drásticamente. Y lo más importante: reduces drásticamente los [costos ocultos de los asistentes de código](https://luisalejandro.org/blog/posts/hablemos-claro-desarrolladores-senior-vs-ia-y-el-costo-oculto-de-github-copilot), evitando que tu factura de API se dispare por bucles inútiles de reintentos sobre código roto. ## Construyendo un harness modular y agnóstico al modelo Uno de los mayores errores tácticos al construir infraestructura para IA es acoplar la lógica de tu negocio a las librerías propietarias o SDKs de un único proveedor. La industria se mueve a una velocidad frenética; el modelo que hoy domina el mercado puede ser superado mañana por una opción de código abierto más rápida y económica. Un *harness* bien diseñado actúa como una interfaz desacoplada. Utiliza patrones tradicionales de arquitectura de software, como el patrón *Adapter*, para aislar la orquestación del proveedor subyacente. Si deseas cambiar de motor de inferencia para optimizar tu [análisis de costos entre API y suscripciones](https://luisalejandro.org/blog/posts/pagar-api-claude-vs-suscripcion-la-verdad-de-claude-code-costos-y-codex-cli-precios), tu infraestructura de ejecución, tus herramientas de manipulación de archivos y tus sistemas de persistencia no deberían cambiar en una sola línea de código. Al final del día, la inteligencia del agente no está encerrada en las variables de entorno de la API de turno; reside en cómo tu sistema valida las entradas, estructura la memoria y gestiona el ciclo de vida del desarrollo. Si nos tomamos en serio la automatización del software, debemos dejar de lado la narrativa simplista del "prompting mágico" y empezar a construir con rigor de ingeniería. Te invito a explorar más análisis sobre arquitectura de software aplicada en nuestra [categoría de inteligencia artificial y tecnología](https://luisalejandro.org/blog/category/inteligencia-artificial-y-tecnologia). ¿Y ustedes, gente, siguen cambiando de modelo cada vez que un agente falla, o ya están construyendo el *harness* que sus proyectos realmente necesitan? ¡Los leo en los comentarios!