Por qué falla un sistema multiagente en producción

Cada agente pasó la prueba por separado. Juntos, en producción, el proceso empezó a fallar, y cuando alguien preguntó cuál de los tres se había roto, la respuesta fue que ninguno.

Carlos Andrés Ramírez · 2026-09-09

Un equipo montó tres agentes para tramitar reclamos de seguros: uno lee el documento y saca los datos, el segundo los cruza contra la póliza, el tercero aprueba o rechaza. Cada uno pasó semanas de pruebas por separado, y los tres salieron con nota alta. En producción, el conjunto empezó a aprobar reclamos que no debía aprobar. Cuando alguien preguntó cuál de los tres agentes se había roto, la respuesta fue que ninguno.

Esa respuesta suena a excusa y no lo es. Cada agente, probado por su cuenta, seguía haciendo exactamente lo que tenía que hacer. El que extrae datos seguía extrayendo bien la mayoría de las veces. El que cruza la póliza seguía cruzando bien lo que recibía. El que decide seguía decidiendo bien con la información que le llegaba. El sistema fallaba en un lugar que ninguna de esas tres pruebas miraba: el momento en que un agente le entrega su resultado al siguiente, y el siguiente lo da por bueno sin volver a mirarlo.

El equipo de datos había hecho su trabajo. Cada agente tenía su ficha de rendimiento, su conjunto de prueba, su aprobación firmada. Nadie había mentido en ningún informe. Y sin embargo el proceso completo, el que de verdad le importa a quien recibe la respuesta a su reclamo, fallaba con una regularidad que ninguna de esas fichas anticipaba, porque ninguna medía lo que pasaba entre un agente y el siguiente.

Esto no es un problema de modelos peores. Es un problema de dónde se pone la lupa. Se prueba cada agente como una caja separada porque así se construye: un equipo por agente, un cronograma por agente, un responsable por agente. Nadie construye, ni prueba, ni es dueño del hilo que los conecta.

El síntoma

¿Por qué fallan los sistemas multiagente en producción aunque cada agente funcione bien por separado?

Porque la fiabilidad de un agente se mide con los datos que él ve en la prueba, y en producción no ve esos datos: ve lo que el agente anterior decidió entregarle. Un error que ese primer agente comete una vez cada tanto, raro y sin importancia visto solo, deja de ser raro cuando se repite en cada caso que pasa por su salida. Y como nadie diseñó al segundo agente para dudar de lo que recibe, ese error entra al proceso con la misma autoridad que un dato correcto.

• El agente que decide trata el resultado del agente anterior como si fuera el dato original, no como una interpretación que también se puede equivocar.
• Cada agente se aprueba con su propio conjunto de prueba, y nadie corre la cadena completa con casos reales antes de ponerla a decidir de verdad.
• Cada agente tiene un dueño en el organigrama. El proceso que forman los tres juntos no tiene ninguno.
• El error de un agente, raro visto de forma aislada, se repite en cada caso que pasa por él, así que se acumula con el volumen en vez de diluirse.
• Cuando el proceso falla, el comité pregunta qué agente se rompió. La pregunta que de verdad importa, dónde se rompió el traspaso entre dos, no se hace.

El problema detrás

Un sistema multiagente no hereda la fiabilidad de sus partes.

Sumar agentes que funcionan bien por separado no da, de forma automática, un proceso que funciona bien junto. Cada traspaso es una oportunidad nueva de que algo se pierda, y con tres agentes hay dos traspasos, no uno. Nadie los cuenta como riesgo porque no aparecen en ninguna ficha de rendimiento: la ficha mide al agente, no la costura entre agentes. Y lo que no se mide, nadie lo vigila hasta que el cliente equivocado recibe la aprobación equivocada.

Un sistema multiagente no falla donde cada agente decide. Falla donde uno le entrega el caso al siguiente, y ahí no está vigilando nadie.

BECOME

El marco

¿Cómo se blinda el traspaso entre agentes antes de que falle el conjunto?

Estas cinco piezas se diseñan antes de sumar el segundo agente a un proceso, no después de la primera aprobación que no debió salir.

Verificación en el traspaso

El agente que recibe un resultado revisa al menos una parte contra la fuente original, no da por buena la palabra del agente anterior sin ningún control propio.

Métrica de cadena

Se mide la tasa de acierto del proceso completo, de principio a fin, no la de cada agente aislado. Un proceso puede tener tres agentes con nota alta y una cadena que falla igual.

Un dueño del proceso

Una persona responde por el resultado del conjunto, no por cada pieza. Sin ese nombre, cuando el proceso falla cada equipo señala a los otros dos y nadie corrige nada.

Ensayo con datos reales

La cadena completa se corre con casos de producción antes de dejarla decidir sola, no solo cada agente en su propio conjunto de prueba.

Corte para intervención humana

Se define en qué traspaso concreto se detiene el proceso y pasa a una persona si la confianza cae, no solo al final de toda la cadena.

Ninguna de las cinco exige un modelo mejor ni un agente más inteligente. Exige tratar el sistema completo como el producto, y a cada agente como una pieza de él, no al revés.

Antes de sumar el próximo agente a un proceso que ya tiene otros, pregunta quién audita lo que ese agente recibe del anterior, no solo lo que produce por su cuenta. Si nadie tiene esa respuesta, el sistema tiene tantos puntos ciegos como traspasos entre agentes.

Blindemos el traspaso entre tus agentes