¿Alguna vez te has encontrado en esta situación?
El mismo Claude, el mismo GPT-4o: una persona lo usa para escribir 1 millón de líneas de código en 5 meses, mientras que otra ni siquiera logra que funcione de forma estable durante dos horas.
Los modelos son idénticos, pero los resultados son abismalmente diferentes.
¿Dónde está el problema?
Recientemente leí varios artículos de OpenAI, Anthropic, Martin Fowler y Phil Schmid, y descubrí que todos hablan de lo mismo.
Lo llaman Ingeniería de Arneses (Harness Engineering).
En pocas palabras, se trata de construir un "sistema operativo" para tu Agente.
Primero, entiende qué es un Arnés
Phil Schmid hizo una gran analogía en un blog de HuggingFace.
Piensa en un sistema de Agente como una computadora.
El modelo es la CPU, que proporciona potencia de cálculo bruta. La ventana de contexto es la RAM, que almacena cosas temporalmente. El Agente es la aplicación que se ejecuta encima.
Entonces, ¿qué es el sistema operativo?
El Arnés es el sistema operativo.
Sin un SO, incluso la CPU más potente es solo un chip. No puedes escribir en un chip.
Del mismo modo, sin un Arnés, incluso el modelo más inteligente es solo una caja de chat. Si le pides que realice una tarea compleja durante una hora, ¿qué pasa si olvida el contexto? ¿Quién lo detiene para que no escriba código basura? ¿Qué pasa si comete un error y ni siquiera se da cuenta?
Estos no son problemas que se resuelvan "cambiando a un modelo más inteligente".
Martin Fowler dijo algo que me quedó grabado: los Arneses podrían convertirse en "plantillas de servicio" en el futuro. Así como hoy inicias un nuevo proyecto con una plantilla de servicio, iniciarás un nuevo Agente con una plantilla de Arnés.
Creo que esta predicción es muy probable que se cumpla.
¿Por qué está explotando de repente en 2026?
Porque los modelos ya son lo suficientemente potentes.
En 2024, todos competían por ver qué modelo era más inteligente. Para 2026, la brecha entre los modelos de primer nivel se ha vuelto muy pequeña. Si le das el mismo problema a Claude y GPT, sus puntuaciones solo difieren en unos pocos puntos.
Pero si los dejas trabajar durante 8 horas seguidas, la brecha aparece.
Esa brecha no está en el modelo en sí; está en el "arnés" que lo rodea.
El equipo de Codex de OpenAI tiene una estadística impactante. Usaron Codex para construir un producto completo: 5 meses, 1 millón de líneas de código, cero líneas escritas a mano. Durante todo el proceso, descubrieron que el cuello de botella ya no era "si el modelo puede escribir código".
El cuello de botella era si los humanos podían revisar el código lo suficientemente rápido.
La velocidad de salida del modelo ha superado la velocidad de revisión humana. En este punto, ¿de qué sirve optimizar el modelo? Debes optimizar el proceso de revisión, el control de calidad y las restricciones arquitectónicas.
Eso es lo que hace el Arnés.
Los Tres Pilares
Entonces, ¿qué contiene realmente un Arnés?
Después de leer estos artículos, descubrí que, aunque los términos varían, hay tres pilares fundamentales.
1. Bucle Cerrado de Evaluación
Esto es lo que Anthropic enfatiza más.
La idea central es simple: Un Agente no puede calificarse a sí mismo.
Piénsalo: si un becario termina un informe y le preguntas cómo lo hizo, te dirá "está bien". Necesitas una persona independiente que lo evalúe.
Anthropic llama a esto "Desarrollo Impulsado por la Evaluación". Primero define cómo se ve "hacerlo bien", luego deja que el Agente lo haga y, finalmente, un evaluador independiente lo puntúa.
El Desarrollo Impulsado por la Evaluación es la versión para Agentes de TDD. Escribe las pruebas primero, luego el código. Excepto que aquí, las "pruebas" son para el Agente.
El evaluador no solo mira el código. En realidad, opera el producto: usa Playwright para hacer clic en botones, llenar formularios y ejecutar pruebas, y luego juzga según criterios claros.
Hay un caso fascinante aquí.
Opus 4.5 de Anthropic encontró una laguna en una política de reservas durante una prueba de reserva de vuelos, encontrando una solución mejor que la respuesta estándar.
Pero el evaluador la marcó como "fallo".
¿Por qué? Porque el evaluador no esperaba una solución tan creativa. Solo había una respuesta estándar, y como el Agente encontró una mejor, fue penalizado.
Esta historia muestra dos cosas: primero, los Agentes son lo suficientemente inteligentes como para encontrar soluciones que los humanos no han pensado. Segundo, el bucle de evaluación no solo verifica al Agente; también verifica la evaluación en sí misma. Si tu evaluador es demasiado rígido, se convierte en el cuello de botella.
Otro dato: Opus 4.5 inicialmente obtuvo un 42% en CORE-Bench. Después de corregir errores de puntuación y relajar las restricciones del andamiaje, la puntuación saltó al 95%.
A menudo, no es que el modelo no sea lo suficientemente bueno; es que tu Arnés tiene problemas.
Usando este método, Anthropic hizo que un Agente construyera un juego completo en 6 horas por $200.
2. Restricciones Arquitectónicas
Esta es la especialidad del equipo de Codex de OpenAI.
Le dices a un becario "el código debe estar en capas", él asiente y luego escribe inmediatamente la lógica de la interfaz de usuario en la capa de la base de datos.
Hablar es inútil.
El enfoque de OpenAI es imponerlo mecánicamente mediante linters y CI. El código que viola las reglas arquitectónicas se rechaza de inmediato, sin siquiera pasar a revisión.
Sus capas de código se ven así: Tipos → Config → Servicio → UI. Cada capa solo puede depender de la capa superior, nunca al revés. Esta regla no solo está escrita en un documento; está escrita en un linter para su verificación automática.
Aún mejor, estos linters son generados por el propio Codex.
El Agente escribe sus propias reglas y luego las sigue.
Martin Fowler dijo después de leer el artículo de OpenAI:
"Aumentar la confianza y la confiabilidad requiere restringir el espacio de soluciones. Esto significa renunciar a parte de la flexibilidad para 'generar cualquier cosa'."
Cuantas más restricciones, más confiable.
Suena contradictorio, pero los datos hablan. LangChain hizo un experimento: sin cambiar el modelo, solo cambiaron el Arnés, y la tasa de aprobación en Terminal Bench 2.0 saltó del 52.8% al 66.5%. Vercel fue más allá, eliminando el 80% de las herramientas del Agente, lo que resultó en menos pasos, mayor velocidad y mejores resultados.
Menos herramientas a menudo conducen a un mejor rendimiento: esta conclusión se ha verificado repetidamente en el campo de los Agentes.
3. Gestión de la Memoria
Este pilar se discute menos, pero creo que es el más importante a largo plazo.
PrismerCloud ha trabajado profundamente en esta dirección.
El problema es: cuando varios Agentes comparten una base de conocimiento, el Agente A escribe una experiencia y el Agente B la lee como verdad. ¿Pero qué pasa si el Agente A se equivocó?
La alucinación de un Agente puede contaminar a todos los Agentes a través de la base de conocimiento compartida.
El enfoque de PrismerCloud es construir un "Motor de Evolución". Cada experiencia del Agente se registra primero como una "señal". Una vez verificada, las señales se destilan en "genes", que se optimizan continuamente en función de los resultados reales.
En pocas palabras, los genes son conocimiento verificado y efectivo. Si no está verificado, no cuenta.
Hay una estadística interesante: 3 líneas de prompt más un sistema de memoria funcionan aproximadamente tan bien como 200 líneas de prompts expertos cuidadosamente elaborados. Además, el primero evoluciona, mientras que el segundo es estático.
Esto significa que si tu sistema de memoria es bueno, no necesitas prompts complejos. El Agente mejorará naturalmente con el tiempo.
Bonus: Resistencia a la Entropía
Esto no es un pilar independiente, pero vale la pena mencionarlo.
Los sistemas de Agentes se degradan naturalmente con el tiempo. Los documentos caducan, las arquitecturas se eluden y las bases de conocimiento se llenan de información obsoleta.
El enfoque de OpenAI es ejecutar periódicamente un "Agente de Refactorización" para escanear inconsistencias en los documentos y violaciones arquitectónicas. Lo dijeron mejor:
"Cuando un Agente tiene dificultades, lo tratamos como una señal: averiguar qué falta, retroalimentarlo en la base de código y siempre dejar que Codex escriba la solución."
Cuando un Agente tiene problemas, no solo arregles al Agente: arregla el Arnés. Esta mentalidad es clave.
¿Quién está haciendo esto?
El campo se divide en dos caminos: proyectos de código abierto que puedes usar hoy y prácticas internas de empresas comerciales de las que solo puedes aprender la metodología.
Proyectos de Código Abierto: Listos para Usar
LangChain DeepAgents: Probablemente el proyecto de código abierto más cercano a un "Claude Code universal". Planificación, operaciones de archivos, delegación de subagentes, compresión automática de contexto: listo para usar. 115k estrellas en GitHub.
DeerFlow 2.0: De ByteDance. Código abierto en marzo, alcanzó 39k estrellas en un mes. Se autodenomina un "SuperAgent Harness". Es una reescritura completa de v1 con ejecución en entorno aislado, memoria persistente y sistemas de habilidades basados en LangGraph.
OpenHands: Especializado en Agentes de codificación. Alcanzó un 77.6% en SWE-bench Verified. Es independiente del modelo y usa Laminar para la observabilidad, rastreando cada acción del Agente.
SWE-agent: De Princeton y Stanford. Se centra en perfeccionar el desarrollo "impulsado por la evaluación".
Goose: Código abierto por Block (Square/Cash App). Un Agente general en la máquina que puede instalar dependencias, ejecutar pruebas y gestionar archivos.
PrismerCloud: Se centra en la gestión de la memoria y el motor de evolución. Es la solución más madura para prevenir la contaminación por alucinaciones en sistemas multiagente.
Cognee: Un motor de memoria impulsado por grafos de conocimiento para Agentes que ayuda a establecer conexiones semánticas entre datos.
Prácticas Comerciales: Aprende la Metodología
Claude Code + Agent SDK: El punto de referencia de Anthropic para un Arnés general. No es solo para codificar; lo usan para investigación, creación de videos y toma de notas.
OpenAI Codex: La práctica definitiva en restricciones arquitectónicas. 1 millón de líneas de código sin escritura manual, basándose en linters autogenerados y revisiones por pares de Agentes.
Una Lección que Me Quedó Grabada
Rich Sutton escribió un artículo clásico llamado "The Bitter Lesson". La esencia es que los métodos generales que aprovechan la computación siempre superan a los métodos específicos diseñados por humanos a largo plazo.
Esta lección se está demostrando nuevamente en el campo de los Agentes.
Manus refactorizó su Arnés 5 veces en 6 meses. LangChain reestructuró su arquitectura 3 veces en un año. Vercel eliminó el 80% de sus herramientas.
Construye para Eliminar.
La "lógica inteligente" que escribes hoy podría quedar obsoleta mañana cuando el modelo se actualice. Tu arquitectura debe ser modular y estar lista para ser desechada.
Phil Schmid dijo algo que vale la pena recordar:
"La ventaja competitiva ya no es el prompt; son las trayectorias capturadas por tu Arnés. Cada éxito y fracaso son datos para entrenar a la próxima generación."
Cuanto más tiempo funcione tu Arnés y más trayectorias acumule, más fuerte se volverá tu Agente. No puedes ponerte al día solo cambiando de modelo.
Las Tres Etapas
Piensa en el lugar del Arnés en la ingeniería de IA de esta manera.
Ingeniería de Prompts resuelve "qué decir". Una interacción única.
Ingeniería de Contexto resuelve "qué saber". Proporciona referencias e historial.
Ingeniería de Arneses resuelve "cómo trabajar de forma continua, estable y a escala". Los bucles de evaluación garantizan la calidad, las restricciones arquitectónicas garantizan las reglas y la gestión de la memoria garantiza la acumulación de experiencia.
Sin un Arnés, un Agente puede recordar cosas pero no tiene supervisión, lo que lleva al caos. Cuando las tres capas están en su lugar, tienes un personaje que puede trabajar verdaderamente a largo plazo.
OpenAI, Anthropic y LangChain ya están haciendo esto.
Fuentes: OpenAI Harness Engineering, Anthropic Demystifying Evals, Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026, Martin Fowler Harness Engineering, LangChain Agent Frameworks.
