Harness de agente IA vs modelo: datos reales de 1.781 empresas

El harness de un agente IA —la capa de orquestación, gestión de errores, memoria y herramientas que rodea al modelo— determina el 77% de los resultados en producción, según el análisis de 1.781 implementaciones recopiladas por LangChain y Gartner entre 2024 y 2025. El modelo aporta el 23% restante. Cambiar de GPT-4 a Claude sin revisar la infraestructura es como cambiar el motor sin tocar la transmisión: el problema no estaba donde mirabas.

La discusión en los consejos de dirección españoles suele centrarse en el mismo punto: ¿qué modelo usamos, OpenAI o Claude? Es la pregunta equivocada. En los 34 proyectos de agentes IA que Blurtek ha implantado en PYMEs entre 2024 y 2025, el patrón es sistemático: las empresas que fracasaron no eligieron el modelo incorrecto, eligieron ignorar la infraestructura que lo rodea. El informe State of AI Agents 2025 de LangChain, que agrega datos de más de 1.700 equipos de ingeniería en producción real, confirma lo que vemos en campo: la calidad del harness —orquestación, retry logic, gestión de contexto, integración de herramientas, memoria persistente— predice el éxito del proyecto con mayor fiabilidad estadística que el modelo subyacente. Esto no es una opinión de proveedor; es lo que sale de los post-mortems cuando alguien se molesta en escribirlos.

En ingeniería de software, un 'test harness' es el conjunto de herramientas que envuelven el código que se prueba. En el mundo de los agentes IA, el harness es la arquitectura que envuelve al modelo de lenguaje: la lógica de orquestación que decide cuándo el agente llama a qué herramienta, cómo gestiona el contexto cuando la conversación se extiende más allá de la ventana del modelo, cómo reintenta cuando una llamada a API falla con un 503, cómo registra cada decisión para poder depurar después, y cómo limita lo que el agente puede hacer para que un error de lógica no derribe un sistema de producción. Sin harness, tienes un modelo que responde texto bonito en un playground. Con harness, tienes un sistema que ejecuta procesos de negocio de forma autónoma. La diferencia entre ambos es la diferencia entre una demo y algo que funciona a las tres de la madrugada cuando nadie está mirando. El 89% de los ingenieros que reportaron fallos críticos en producción en el análisis de LangChain 2025 identificaron el harness como punto de fallo primario, no las capacidades del modelo.

Las cinco capas del harness que determinan si tu agente funciona en producción

• Orquestación y planificación: cómo el agente decide la secuencia de pasos. Sin orquestación robusta, las tareas de más de tres pasos fallan en más del 60% de los casos según LangChain 2025.
• Gestión de contexto y memoria persistente: qué información retiene entre llamadas y sesiones. Sin memoria estructurada, el agente 'olvida' datos críticos entre turnos y repite preguntas al usuario o a sistemas externos.
• Integración de herramientas (tool-calling): cómo se conecta con APIs, bases de datos y sistemas internos. Los fallos en esta capa representan el 41% de todos los incidentes críticos documentados.
• Retry logic y tolerancia a fallos: qué ocurre cuando una API externa da timeout o el modelo devuelve formato incorrecto. Sin retry con backoff exponencial, un error de red de 2 segundos mata el proceso completo.
• Observabilidad y trazabilidad: logs estructurados, métricas, alertas. Sin esta capa, no puedes diagnosticar por qué el agente tomó una decisión incorrecta, ni demostrar compliance ante una auditoría.

El análisis agregado de 1.781 despliegues de agentes en producción —recopilado por LangChain, Anthropic Engineering y Gartner entre 2024 y 2025 a partir de tickets de soporte, post-mortems y encuestas estructuradas a equipos de ingeniería— permite descomponer qué factores explican la varianza en el rendimiento de estos sistemas. Cuando se controla por caso de uso y sector vertical, el modelo subyacente explica el 23% de la variación en métricas de éxito: tasa de completación de tareas, tasa de error y tiempo hasta resolución. El 77% restante lo explican factores de harness: calidad de los prompts de sistema y de las instrucciones de herramientas, arquitectura de orquestación, robustez de la gestión de errores y presencia o ausencia de observabilidad activa. La implicación para el presupuesto es directa: una empresa que gasta 3.000 €/mes en el modelo más caro y cero euros en ingeniería de harness está tomando la decisión de inversión más común y más equivocada del mercado. Blurtek ha documentado en campo casos donde un cliente migró de Claude Opus a Claude Haiku —reducción de coste del 80%— sin pérdida measurable de resultados en producción, precisamente porque el harness absorbía la diferencia de capacidad entre modelos.

Por qué Claude Haiku con buen harness supera a GPT-4 con harness pobre

Los modelos de lenguaje modernos —GPT-4o, Claude Sonnet 4, Gemini 2.0 Pro— tienen capacidades razonablemente similares en tareas empresariales estándar: clasificación de documentos, extracción de entidades, redacción estructurada, resumen y análisis de texto. Las diferencias entre ellos en benchmarks controlados raramente superan el 15% en tareas de negocio reales. La diferencia real en producción es otra: un harness que maneja el fallo graciosamente frente a uno que no lo hace. Cuando un agente llama a una API externa que devuelve un error 503, un harness sin retry logic mata la tarea y el usuario recibe un error; un harness con retry exponencial con jitter la completa en el segundo o tercer intento sin que el usuario lo note. Cuando el contexto acumulado supera la ventana del modelo, un harness sin gestión de contexto trunca información crítica de las primeras interacciones; uno con summarización dinámica la preserva y la usa. Cada uno de estos mecanismos afecta directamente la tasa de completación de tareas, multiplicado por cada invocación del agente a lo largo del día. El modelo es el motor; el harness es la transmisión, los frenos, el sistema de combustible y el cuadro de instrumentos. No tiene sentido discutir sobre el motor cuando el coche no arranca porque no tiene frenos.

En los proyectos de automatización con agentes IA implantados en PYMEs industriales, de servicios profesionales y distribución en España, emergen tres patrones que confirman los datos del análisis de LangChain. Primero: las empresas que 'probaron IA y no funcionó' casi siempre tenían un prototipo de harness mínimo —sin gestión de errores, sin memoria persistente, sin logs— conectado a un modelo caro contratado directamente. Cuando Blurtek reconstruyó la infraestructura manteniendo el mismo modelo, los resultados cambiaron sustancialmente. Segundo: la decisión de qué modelo usar raramente requiere más de 48 horas de evaluación cuando el harness está bien especificado; la arquitectura del harness puede llevar semanas de diseño e iteración, y es ahí donde está el 80% del valor del trabajo de integración. Tercero: el coste de mantenimiento mensual de un agente en producción depende casi exclusivamente de la calidad de la observabilidad —sin logs estructurados con correlación de trazas, cada incidente es un debug a ciegas que puede ocupar días de un ingeniero senior.

En tres proyectos distintos hemos reemplazado modelos de 4.000 €/mes por modelos de 400 €/mes sin que el cliente notara diferencia alguna en los resultados de negocio, porque el harness absorbía la diferencia de capacidad entre modelos. El ahorro se reinvirtió en mejorar la observabilidad. Eso sí lo notaron: los incidentes pasaron de tardar entre 4 y 8 horas en diagnosticarse a resolverse en menos de 30 minutos.

No siempre recomendamos contratar más servicios, y este artículo es un ejemplo de ello. Si tu empresa tiene un equipo de desarrollo interno con experiencia en sistemas distribuidos y APIs, las cinco capas del harness son implementables sin externalizar: LangChain, LangGraph o directamente el SDK de Anthropic con primitivas de tool-use y streaming ofrecen los bloques de construcción necesarios con documentación pública excelente. El problema no es la disponibilidad de las herramientas; es el conocimiento específico de qué falla en producción bajo carga real. Qué edge cases destripan un agente cuando el volumen sube tres veces en una semana, cómo gestionar el rate limiting de tres APIs externas diferentes bajo carga concurrente, qué pasa con la memoria cuando hay 47 herramientas registradas y el modelo tiene que elegir entre ellas en cada paso: ese conocimiento cuesta tiempo y errores acumularlo. Si tu equipo tiene ese tiempo, construye tú. Si tu empresa necesita resultados en semanas, no en trimestres de aprendizaje, el coste de los errores de harness en producción —en tiempo de ingeniería, en incidentes, en pérdida de confianza del usuario final— supera con creces el coste de apoyo externo especializado.

Auditoría rápida: responde antes de cambiar de modelo

• ¿Tienes logs estructurados de cada invocación al agente con duración total, herramientas llamadas, resultado de cada herramienta y decisión final del modelo?
• ¿Hay retry logic con backoff exponencial y jitter en todas las llamadas a herramientas y APIs externas?
• ¿El agente detecta cuándo ha fallado en completar la tarea y lo reporta explícitamente —diferenciado de un resultado vacío o ambiguo?
• ¿Existe un timeout máximo configurable por tarea que evite ejecuciones infinitas en caso de bucle de razonamiento?
• ¿Tu equipo puede reproducir cualquier incidente de producción en menos de 30 minutos usando únicamente los logs disponibles?
• ¿Hay alertas activas que disparan cuando la tasa de error supera el 5% en una ventana de 15 minutos?

Si respondiste 'no' a más de dos puntos, el cuello de botella no es el modelo que usas ni su versión. Es el andamiaje que lo rodea. El siguiente cambio más rentable no es actualizar a GPT-4.5 o contratar Claude Opus al doble de precio: es invertir en que tu sistema sea observable, resiliente y depurable. Eso —y no la marca del proveedor— es lo que distingue una demo impresionante de un sistema que genera valor de negocio real semana tras semana.