Por qué fallan los agentes de IA: el sistema alrededor del modelo pesa más de lo que parece

La primera reacción suele ser culpar al modelo. El agente pasó por alto un archivo, cambió la parte equivocada de un documento, abrió una página que no era, o entregó un resumen muy seguro que nadie se atrevió a usar. Después aparece la conversación de siempre: el modelo no está listo, el prompt es flojo, hace falta más contexto.

A veces es cierto. Pero en el día a día veo con más frecuencia otra causa. Se mete al modelo en una tarea desordenada sin una estructura de trabajo alrededor.

A esa estructura se le está llamando harness. Podría traducirse como arnés, aunque en la práctica prefiero pensarlo como el sistema de trabajo que rodea al modelo. Incluye cómo se prepara el contexto, qué herramientas puede usar, qué permisos tiene, qué pruebas deja, cómo se registra lo ocurrido, dónde revisa una persona y qué pasa si el flujo se bloquea.

Si el harness es débil, incluso un modelo fuerte se parece a una persona muy lista que llega el primer día con un portátil, pero sin onboarding ni autoridad clara. Puede resolver algo una vez. No es una base fiable.

El patrón de fallo que quería fijar

No escribí esto como un recorrido de funciones, sino como una comprobación de trabajo. Los agentes de IA no suelen fallar solo por el modelo. También fallan por contexto, herramientas, permisos, pruebas, registros, revisión y recuperación mal resueltos. La pregunta útil no era qué IA suena mejor, sino si la salida aguanta la siguiente entrega sin rehacerla en silencio.

El flujo de agente que usé como banco de prueba

El caso de trabajo fue deliberadamente concreto: Una nota de selección de modelos centrada en esta pregunta: Los agentes de IA no suelen fallar solo por el modelo. También fallan por contexto, herramientas, permisos, pruebas, registros, revisión y recuperación mal resueltos. Miré el flujo como lo miraría alguien de operaciones: qué entra, qué toca la IA, quién revisa y dónde debe terminar el resultado. OpenAI Codex, ChatGPT, Claude, LangChain, Databricks y agentes de IA importan solo si acortan ese camino sin volver más pesada la revisión.

Las piezas del harness que revisé

Punto de revisión	Qué miré	Señal de fallo
Material de entrada	Si la fuente era lo bastante clara para la IA	La herramienta adivina contexto que falta
Revisión humana	Si una persona puede aprobar, corregir o rechazar rápido	El revisor tiene que leer todo desde cero
Entrega	Si el resultado entra en documento, tabla, ticket o workflow	La siguiente persona reformatea o reinterpreta
Repetición	Si el mismo patrón aguanta con otro material	La primera prueba sale bien y la segunda se desvía

Notas que separaron demo de operación

Evidencia	Qué revisé	Por qué importaba
Paquete de entrada	Brief de tarea, documento o tabla fuente y formato de entrega esperado	Comparar modelos sin forma de entrada dice poco sobre trabajo real
Revisión de salida	Si la respuesta pasa a documento, tabla, ticket o instrucción sin reconstruirla	Ahí suele esconderse la mayor parte del trabajo manual
Registro de fallo	La salida parecía pulida, pero quien la recibía tenía que rehacer la tabla, verificar fuentes o reescribir la entrega.	El caso fallido marca el límite real

Dónde una buena respuesta todavía se atascó

El punto débil no fue la primera respuesta. Fue lo que pasaba después, cuando el resultado tenía que pasar a otra persona o sistema. En este tema, el fallo más común fue este: La salida parecía pulida, pero quien la recibía tenía que rehacer la tabla, verificar fuentes o reescribir la entrega. Por eso no trato un borrador pulido como prueba de que el flujo ya está listo.

Qué pediría antes de ampliar permisos

Primero dejaría salidas de OpenAI Codex, ChatGPT, Claude, LangChain, Databricks y agentes de IA, una tabla comparativa y una nota lista para entregar como evidencia y después decidiría si la herramienta o el flujo sobreviven a la revisión. Si el resultado no se puede comprobar en pocos minutos, reduciría el alcance antes de cambiar de modelo o añadir otra integración.

Comprobaciones antes de ampliar un agente

Escribe con precisión qué recibe la IA como entrada.
Nombra a la persona que aprueba o rechaza el resultado.
Decide dónde debe aterrizar la salida.
Guarda un ejemplo fallido, no solo el caso limpio.
Mide tiempo de revisión ahorrado, no solo velocidad de generación.
Detén el flujo si la siguiente persona sigue reconstruyendo el resultado.

Fuentes que revisé

Para afirmaciones que pueden cambiar, usé documentación oficial, páginas de producto y notas de fuente para afirmaciones cambiantes. Precios, acceso a modelos y funciones de plataforma se mueven rápido, así que separo la evidencia de la opinión.

La versión corta para una reunión

Un agente de IA no es solo un modelo con herramientas. Es un modelo trabajando dentro de un entorno operativo.

Capa	Qué controla	Señal de fallo
Paquete de trabajo	Objetivo, archivos, alcance, estado actual	El agente pregunta lo mismo en cada ejecución
Límite de herramientas	Navegador, terminal, documentos, APIs, almacenamiento	Lee poco o cambia demasiado
Modelo de permisos	Leer, redactar, editar, borrar, enviar, publicar	Una acción útil se vuelve riesgo operativo
Ruta de comprobación	Tests, diff, capturas, fuentes, notas de revisión	El resultado parece bien, pero no se puede verificar
Ruta de recuperación	Reintento, rollback, responsable, estado bloqueado	Una página inesperada o un error de API lo detiene todo
Memoria y reutilización	Reglas guardadas, playbooks, errores repetidos	Cada mañana empieza desde cero

El modelo importa. No lo discuto. Pero el modelo es solo una parte del sistema. Si lo que lo rodea es débil, cada ejecución del agente crea una nueva tarea de supervisión para una persona.

Qué significa harness sin jerga

En un agente de código, el harness no es solo el IDE. Incluye el estado del repositorio, reglas de ramas, comandos de prueba, gestor de paquetes, servicios locales, política de secretos, script de despliegue, hábito de revisión y definición de terminado.

En un agente que usa navegador, incluye sesión iniciada, dominios permitidos, prioridad de fuentes, capturas de pantalla, reglas de descarga y qué hacer si una página bloquea la automatización.

En documentos, incluye archivos fuente, nombres de archivo, plantilla, formato de tablas, comentarios de revisión, historial de versiones y el límite entre reescribir y solo marcar.

En soporte o ventas, incluye límites de datos de cliente, campos del CRM, reglas de escalado, tono, puntos de aprobación y si el agente puede enviar el mensaje o solo preparar un borrador.

Por eso no me fío demasiado de una prueba limpia con un archivo perfecto. Demuestra que el modelo puede hacer una tarea. No demuestra que el flujo vaya a aguantar la semana siguiente cuando cambie el nombre del archivo, caduque el login, el cliente escriba mal o el revisor pregunte qué cambió exactamente.

Dónde se rompe primero

Los fallos casi nunca son espectaculares. Son tan normales que se subestiman.

Un agente resume bien un documento de requisitos, pero no sabe que la sección legal no se puede reescribir. Otro agente lee una hoja de cálculo, pero interpreta una celda vacía como cero cuando en realidad significa “pendiente de aprobación”. Un agente de código arregla un test, pero no ve el script interno que vuelve a generar el archivo durante el despliegue. Un agente de navegador reúne fuentes, pero no distingue una página oficial de una copia publicada en otro sitio.

Nada de eso demuestra que el modelo no sirva. Demuestra que el paquete de trabajo estaba incompleto.

No lo trataría primero como fallo de prompt. Lo marcaría como fallo de harness.

Qué salió mal	Qué arreglaría antes de cambiar de modelo
Tocó el archivo equivocado	Lista de archivos permitidos y diff antes de editar
La respuesta no tenía pruebas	Fuentes, capturas o salida de comando antes de cerrar
Se repite la misma excepción	Convertir la excepción en regla del playbook
El tiempo de revisión no baja	Separar borrador, comprobación y acción final
Nadie sabe qué cambió	Forzar registro final con archivos, fuentes y riesgo restante
Pide más acceso a mitad del flujo	Definir herramientas permitidas y acciones bloqueadas al inicio

Suena básico. En operación, esta diferencia separa una prueba interesante de un trabajo que sí acercaría a sistemas reales.

Un ejemplo con código

Tomemos un agente como Codex. Lo impresionante no es que escriba código. Muchos modelos pueden escribir código. La pregunta real es si puede trabajar dentro del proyecto existente sin crear una segunda tarea para el desarrollador.

Un harness útil para un repositorio puede contener:

La rama actual y si se permite crear una nueva.
Los archivos que determinan el comportamiento en ejecución.
El comando exacto de pruebas y el comando demasiado lento para uso normal.
El comando de build que funciona aunque la aplicación esté levantada.
La ruta de despliegue y la evidencia que debe quedar después.
La regla de no tocar datos de clientes, secretos ni cambios ajenos.

Sin ese paquete, el agente puede parecer productivo. Lee código, prepara un parche y lo explica. Luego el desarrollador tiene que comprobar si usó la prueba correcta, si cruzó un límite, si rompió una convención no escrita o si dejó pendiente el despliegue.

Eso no es automatización. Es ayuda que deja una factura de revisión.

Con el harness, el mismo agente es mucho más útil. Sabe por dónde empezar, cómo demostrar el resultado, cuándo detenerse y qué traspaso puede revisar una persona sin rehacerlo todo.

Un ejemplo con documentos

El patrón se repite fuera del código. Imagina un memo de comparación de proveedores a partir de tres PDFs, una hoja de cálculo y notas de dos llamadas.

La petición débil sería: “Lee esto y haz una comparación.”

El harness más sólido se parece a esto:

La lista de proveedores sale de la hoja, no de los PDFs.
Los precios solo se toman del documento con fecha más reciente.
Lo no confirmado se marca como “sin confirmar”, no se inventa.
Los riesgos de seguridad van en sección aparte, no dentro de la puntuación.
Toda afirmación que afecte la recomendación lleva nota de fuente.
El agente redacta el memo, pero no cambia la recomendación final sin revisión.

No tiene brillo. Es detalle operativo. Justo ahí se construye la confianza. Si el agente no separa hechos confirmados de notas de llamada y no deja rastro de la recomendación, no le daría esa decisión.

Criterio práctico desde operación

Antes de ampliar el alcance de un agente, miro cuatro cosas.

Primero, si entiende la forma del trabajo antes de arrancar. Si una persona tiene que explicar cada vez la carpeta, el orden de fuentes y el formato de salida, el harness no está listo.

Segundo, si deja pruebas sin que se lo pidan. Quiero diffs, fuentes, salidas de comando, capturas o una lista de cambios fácil de revisar. Un párrafo seguro no es evidencia.

Tercero, si el límite de permisos es aburridamente claro. Leer puede ser amplio. Redactar también puede abrirse un poco. Enviar, borrar, publicar, pagar o actualizar registros de clientes debe seguir estrecho hasta que las comprobaciones sean repetibles.

Cuarto, si una ejecución fallida mejora la siguiente. Si un bloqueo termina solo con “inténtalo otra vez”, el sistema no aprendió nada. Si la excepción se convierte en regla, checklist o habilidad guardada, el harness está madurando.

La métrica que usaría

Preguntar si el agente es bueno es demasiado vago.

Yo mediría la carga de revisión. Cuántos minutos pasó una persona comprobando el resultado. Cuántos datos hubo que corregir. Cuántas veces se detuvo por falta de entrada. Cuántas acciones finales rechazó el revisor. Cuántos pasos se repitieron a mano.

Si el agente produce un borrador más bonito pero el tiempo de revisión no baja, el harness todavía no aporta. Si el borrador es menos brillante pero reduce retrabajo y mejora el traspaso, elegiría eso.

Pregunta	Buena señal	Mala señal
¿Conoce el estado actual?	Cita archivos, fechas y responsables correctos	Pregunta datos básicos que ya están en el sistema
¿Usa herramientas con seguridad?	Lee amplio y escribe estrecho	Edita antes de mostrar el plan
¿Deja pruebas?	El revisor puede seguir el camino	La persona tiene que reconstruir el trabajo
¿El fallo mejora el flujo?	La excepción se vuelve regla	La siguiente ejecución repite el error
¿Baja el trabajo humano?	Baja el tiempo de revisión	El resultado está pulido, pero sigue siendo arriesgado

No elijas primero el agente

No empezaría con “qué agente compramos”. Empezaría con un flujo repetido donde el dolor sea visible.

Un buen candidato tiene entrada clara, salida repetible, revisor conocido y traspaso medible. Un mal candidato depende de política interna, juicio difuso o permiso de actuar antes de tener hábito de revisión.

Por ejemplo, “preparar el primer borrador del memo semanal de riesgo de proveedores con fuentes adjuntas” es un buen comienzo. “Gestionar el riesgo de proveedores” es demasiado grande. Lo primero tiene harness. Lo segundo es un deseo.

También por eso las bibliotecas de prompts decepcionan. Un prompt mejora un momento. Un harness mejora el camino alrededor de ese momento.

Criterios de fallo antes de ampliar

Es mejor escribir las reglas de parada antes de que el agente parezca convincente.

Detener si no puede indicar la fuente de una recomendación.
Detener si una persona tiene que revisar cada línea.
Detener si pide más permisos para terminar trabajo rutinario.
Detener si cambia material externo o productivo antes de revisión.
Detener si la misma excepción aparece tres veces.
Detener si el responsable no puede explicar qué hizo el agente.

Puede sonar conservador. Es más barato que limpiar un error seguro de sí mismo después de darle acceso a sistemas reales.

Qué construiría primero

Antes de cambiar de modelo, prepararía un documento pequeño de harness. Una página basta.

Qué trabajo entra al agente.
Qué puede leer.
Qué puede cambiar.
Qué evidencia debe dejar.
Quién revisa el resultado.
Qué ocurre si la ejecución se bloquea.
Qué error repetido se convierte en regla.

Después correría el mismo flujo cinco veces y compararía tiempo de revisión. Si la quinta ejecución necesita la misma explicación humana que la primera, el problema sigue ahí.

Preguntas frecuentes

¿Harness engineering es solo para agentes de código?

No. Los agentes de código hacen visible el problema porque hay repositorios, tests y diffs. El mismo patrón aparece en documentos, investigación web, soporte, ventas y reporting interno.

¿Un mejor modelo reduce la necesidad de harness?

Reduce algunos errores, pero no elimina el problema operativo. Un mejor modelo sigue necesitando contexto correcto, herramientas seguras, pruebas y revisión.

¿Todo workflow debería convertirse en un workflow de agentes?

No. Si el trabajo es raro, sensible o muy dependiente de juicio humano, una checklist y un buen responsable pueden ser mejores. Los agentes ganan sitio cuando hay repetición, evidencia y traspaso claro.

¿Cuál es la primera señal de que el harness funciona?

El agente se vuelve menos ruidoso. Hace menos preguntas básicas, deja mejores pruebas, se detiene con seguridad cuando se bloquea y reduce el trabajo del revisor.

Juicio final

La siguiente etapa útil de los agentes de IA no se ganará solo con modelos más grandes. La ganarán los equipos que sepan empaquetar trabajo, limitar herramientas, probar resultados y convertir fallos repetidos en reglas operativas.

Por eso importa el harness engineering. No es una decoración alrededor del modelo. Es la diferencia entre una ejecución impresionante y un flujo al que puedes volver a confiarle trabajo mañana.

Ruta de workflow

Dónde encaja esta guía

Usa esta sección para conectar la guía que estás leyendo con el workflow más amplio que apoya.

Decisiones de stack Elige el stack que encaja con la madurez operativa del equipo.

Una ruta para comparar plataformas de automatización, builders de apps, builders de agentes, contabilidad y asistentes de IA.

Abrir ruta de workflow

Mejor encaje: equipos que deciden entre comprar una herramienta simple, construir un flujo interno o adoptar una plataforma más amplia
No es ideal si: Necesitas instrucciones paso a paso más que un marco de decisión.

Fuentes consultadas

Páginas públicas usadas para contrastar hechos reportados, documentación oficial, contexto de política, información de producto y afirmaciones que pueden cambiar.