Sistemas multiagente: evitar traspasos con errores

El segundo agente hereda más que una tarea

Un sistema multiagente suena atractivo porque reparte el trabajo: un agente lee la solicitud, otro consulta documentos, otro prepara una respuesta, otro actualiza el CRM o abre una tarea. En una demo, esa cadena parece ordenada. En operación, cada traspaso puede arrastrar una suposición que nadie volvió a revisar.

El riesgo no aparece solo cuando un agente inventa algo. También aparece cuando el primer agente entendió mal la intención, el segundo confió en esa interpretación y el tercero ejecutó una acción con la misma seguridad. El error viaja limpio, bien formateado y con apariencia de proceso.

Por eso los agentes de IA aplicados a empresas no deberían diseñarse como una fila de asistentes obedientes. Necesitan un estado compartido, límites por tarea y puntos donde el sistema confirme qué sabe, qué no sabe y qué está autorizado a pasar al siguiente paso.

El traspaso debe conservar contexto, no resumirlo todo

Muchos errores nacen de un resumen demasiado cómodo. Un agente recibe una conversación larga y le entrega al siguiente una frase breve: "cliente solicita cambio de plan". Esa frase puede ocultar condiciones, dudas, fechas, reclamos previos, promesas comerciales o una identidad todavía no confirmada.

Un buen traspaso no tiene que copiar toda la conversación, pero sí debe conservar la parte que cambia la decisión. Qué pidió la persona. Qué dato fue confirmado. Qué fuente se usó. Qué quedó pendiente. Qué acción está bloqueada. Qué parte requiere revisión humana. Si esa información se pierde, el siguiente agente trabaja con una versión elegante y pobre del caso.

Aquí la automatización de procesos ayuda cuando obliga a separar el flujo en estados claros. No es lo mismo clasificar una solicitud que aprobar un cambio, preparar un borrador o ejecutar una actualización. Cada estado debería tener entradas mínimas y salidas verificables.

Una suposición no debería convertirse en dato oficial

En sistemas multiagente, una suposición puede subir de categoría sin que nadie lo note. El primer agente infiere que el cliente pertenece a cierta empresa. El segundo consulta información de esa empresa. El tercero redacta una respuesta como si la identidad estuviera confirmada. La cadena parece eficiente, pero mezcló inferencia con verdad operativa.

La forma práctica de evitarlo es etiquetar el estado de cada dato. Confirmado, inferido, pendiente, contradictorio, vencido, sensible o no autorizado. Esa etiqueta debe viajar con el caso. Si desaparece, el siguiente agente no sabe si está mirando evidencia o una apuesta razonable.

Esto importa en ventas, soporte, compras, admisiones, reservas, legal, salud y cualquier operación donde una frase mal asumida puede cambiar el trato al cliente. Un sistema multiagente maduro no se luce por pasar trabajo rápido. Se nota porque no convierte dudas en hechos.

Cada agente necesita permisos distintos

Un error común es dar a todos los agentes acceso parecido porque pertenecen al mismo flujo. Parece más simple, pero rompe la lógica de control. El agente que clasifica correos no necesita cambiar oportunidades en el CRM. El que consulta políticas no necesita enviar mensajes externos. El que prepara una minuta no debería crear tareas sin revisión si la fecha o el responsable son ambiguos.

Los permisos deben seguir la consecuencia de la acción, no el entusiasmo del proyecto. Leer, resumir, recomendar, redactar, actualizar y notificar son trabajos distintos. Cada uno merece permisos, evidencias y condiciones de pausa distintas.

La seguridad y gobernanza de IA entra justo en ese punto. No se trata de frenar toda colaboración entre agentes, sino de impedir que una capacidad útil termine actuando fuera de su carril. Si un agente necesita más permiso, el sistema debe justificar por qué, bajo qué condición y con qué reversa.

El estado compartido debe mostrar quién cambió qué

Cuando varios agentes trabajan sobre el mismo caso, el estado del caso se vuelve el lugar más importante del sistema. Ahí debería verse qué cambió, quién lo cambió, con qué fuente y en qué momento. Sin ese registro, nadie sabe si una respuesta salió de la conversación original, de una fuente aprobada, de una inferencia o de una actualización hecha por otro agente minutos antes.

No hace falta construir una plataforma pesada para empezar. Puede bastar con un registro estructurado por caso: identidad, intención, fuentes consultadas, decisiones tomadas, pendientes, bloqueos y próxima acción permitida. Lo importante es que el siguiente agente no dependa de leer una transcripción completa ni de confiar en un resumen sin rastro.

En empresas que ya conectan IA con CRM, soporte o portales internos, esta disciplina evita discusiones costosas. Si el resultado salió mal, el equipo puede reconstruir dónde se torció el caso. Si salió bien, también puede entender qué parte del flujo merece repetirse.

La revisión humana debe mirar la cadena completa

Revisar solo la respuesta final es insuficiente. Una respuesta puede estar bien escrita y aun así venir de un traspaso defectuoso. La persona revisora necesita ver el camino: entrada original, clasificación, fuente, cambios de estado, permisos usados y acción propuesta.

Esto cambia el diseño de la bandeja de revisión. El revisor no debería recibir un texto aislado para aprobar o rechazar. Debería recibir una ficha del caso con las razones del sistema, las dudas abiertas y las acciones que siguen bloqueadas. Así puede corregir la causa, no solo editar la última frase.

Para una operación con soporte mensual, clientes activos o procesos críticos, esta diferencia pesa. La revisión deja de ser un filtro de estilo y se convierte en control operativo. Ahí también se conectan los servicios de operación y soporte digital: seguimiento, incidentes, trazabilidad y continuidad cuando el flujo automático necesita intervención.

El piloto debe probar traspasos incómodos

Un piloto multiagente no se valida con casos perfectos. Hay que probar cambios de intención, información contradictoria, identidad dudosa, documentos vencidos, solicitudes parcialmente autorizadas y casos donde un agente debe negarse a continuar. Si el piloto solo mide velocidad, va a premiar justamente lo que puede fallar después.

Conviene escoger pocos recorridos, pero completos. Por ejemplo: solicitud recibida, clasificación, consulta de fuente, preparación de respuesta, revisión humana, actualización de CRM y notificación final. En cada paso se revisa si el estado viajó bien, si los permisos fueron correctos y si el siguiente agente recibió lo necesario para actuar sin inventar.

El resultado del piloto no debería ser "los agentes colaboran". Eso es apenas la demostración técnica. La pregunta útil es más concreta: cuando el caso cambia, ¿el sistema conserva contexto, detecta el límite y evita que el error siga avanzando?

Coordinar agentes también es diseñar responsabilidad

Los sistemas multiagente pueden ser muy útiles cuando el trabajo ya está dividido en tareas claras. Ayudan a leer, ordenar, consultar, preparar y escalar sin exigir que una sola pieza haga todo. Pero esa utilidad depende de una idea simple: alguien debe ser responsable del recorrido completo.

Si cada agente cumple su tarea y nadie gobierna el caso, la empresa termina con una cadena eficiente de pequeñas irresponsabilidades. Un agente clasificó. Otro resumió. Otro redactó. Otro ejecutó. Cuando aparece el problema, todos hicieron "lo suyo" y nadie puede explicar el resultado completo.

La coordinación real exige un dueño del proceso, reglas de estado, permisos por acción, evidencia y revisión de la cadena. Con eso, un sistema multiagente deja de ser una coreografía bonita y se convierte en una forma seria de automatizar trabajo empresarial sin perder control.