Supervisor de agentes de IA: quién vigila a los agentes cuando ya son varios

Qué es un supervisor de agentes

No es una persona. Es una capa de decisión que se sienta por encima de los agentes y ordena qué pasa cuando hay más de uno.

Puede ser código simple: unas reglas de prioridad y un bloqueo para que dos agentes no toquen el mismo registro a la vez. Puede ser un agente él mismo, que recibe la tarea y decide a quién se la pasa.

Lo que no puede ser es nada. Y «nada» es lo que hay en la mayoría de empresas que llegaron al tercer agente sin darse cuenta de que habían cruzado un umbral.

Conviene distinguirlo de la orquestación de agentes, que es cómo se coordinan varios agentes para completar una tarea. El supervisor no coordina una tarea: gobierna la convivencia de tareas distintas.

Hay una tercera forma que aparece sola y conviene reconocerla: el supervisor de facto. Es la persona del equipo que, sin que nadie lo decida, se ha convertido en quien sabe qué agente hace qué.

Funciona hasta que esa persona se va de vacaciones. Y funciona peor cuanto mejor lo hace, porque cuanto más resuelve menos evidente es que el sistema depende de ella.

Convertir a esa persona en el diseñador del supervisor explícito suele ser el camino más corto, porque ya tiene el mapa mental completo. Lo único que falta es sacarlo de su cabeza y ponerlo en reglas.

A partir de cuándo hace falta

La respuesta corta es: cuando dos agentes pueden tocar el mismo dato. No cuando hay muchos.

Una empresa puede tener seis agentes en seis áreas que no se cruzan nunca y no necesitar supervisor. Otra puede tener dos que comparten el CRM y necesitarlo desde el primer día.

Las tres condiciones que lo disparan:

• Comparten un sistema de escritura. Dos agentes que escriben en el mismo CRM, la misma bandeja o la misma base.
• Comparten un canal con el cliente. Si el cliente puede recibir dos mensajes de dos agentes distintos, ya hay un problema de coherencia.
• Comparten un presupuesto de consumo. Si el gasto de API es una bolsa común, uno puede vaciarla y dejar a los otros sin servicio.

Con una sola de las tres, conviene. Con dos, es urgente. Es el mismo umbral que describe cómo escalar agentes de IA en una empresa al pasar de uno a dos.

Hay una cuarta señal que no está en la lista porque no es técnica, y es la que suele llegar primero: alguien empieza a revisar todo a mano otra vez.

Cuando el equipo pierde confianza en que los agentes se comporten de forma coherente entre ellos, la reacción natural es volver a comprobar cada salida. Ahí la empresa está pagando los agentes y el trabajo manual a la vez.

Es el síntoma más caro y el más fácil de leer, porque se ve en la carga del equipo antes que en ningún registro.

Qué hace exactamente

Cuatro funciones, y ninguna es glamorosa. Todas son las que evitan el incidente del que nadie quiere hablar en el comité.

La cuarta es la que más se agradece meses después. Cuando un cliente reclama por algo que pasó hace tres semanas, o hay una traza única o hay tres registros que nadie sabe cruzar.

Hay una quinta función que aparece cuando los agentes son de proveedores distintos: traducir.

Cada proveedor nombra las cosas a su manera. Lo que en uno es un caso, en otro es una conversación y en el tercero un ticket. Sin una capa que unifique el vocabulario, cruzar lo que hicieron dos agentes exige que alguien conozca los tres paneles.

No es un problema de tecnología sino de que nadie decidió cuál es el nombre oficial de cada cosa dentro de la empresa. El supervisor es un buen sitio para tomar esa decisión, porque es el único que ve a todos.

Qué se rompe cuando no existe

Los cuatro fallos siguientes los he visto repetirse con exactitud incómoda, siempre en empresas que llegaron al tercer o cuarto agente sin plan.

• Respuestas contradictorias al mismo cliente. Dos agentes con contexto parcial responden distinto a la misma consulta, con horas de diferencia.
• Sobreescritura silenciosa. Uno actualiza un campo, otro lo pisa segundos después y la versión que queda es la del que llegó último, no la correcta.
• Bucles entre agentes. El agente A crea una tarea que dispara al agente B, que crea una entrada que vuelve a disparar al A. Se descubre por la factura.
• Nadie escala nada. Cada agente cree que el caso raro es de otro, y el caso raro se queda sin resolver hasta que el cliente insiste.

Un caso anonimizado del segundo fallo, porque es el que menos se ve venir. Empresa de servicios, dos agentes en el mismo CRM.

Uno actualizaba el estado del lead cuando llegaba una respuesta por correo. El otro lo actualizaba cuando había actividad en el chat de la web. Los dos funcionaban bien por separado.

El problema apareció con los leads que hacían las dos cosas en la misma hora: el estado final quedaba en el del último que escribió, que no era el más avanzado. Nadie lo notó durante seis semanas porque el CRM no muestra el historial de cambios por defecto.

Lo que lo destapó no fue un registro técnico. Fue un vendedor que dijo que había leads que se le desaparecían de la lista de seguimiento.

Cómo se construye el primero, sin sobredimensionar

La tentación es montar una plataforma de orquestación desde el día uno. Casi nunca hace falta y casi siempre retrasa el proyecto.

El supervisor mínimo que resuelve el 80 % de los casos son tres reglas escritas en código simple:

• Una tabla de prioridad. Si dos agentes pueden atender lo mismo, cuál manda.
• Un bloqueo por registro. Mientras un agente trabaja sobre un cliente, ningún otro lo toca.
• Una lista de casos que se escalan siempre. Reclamos, montos por encima de un umbral, clientes marcados.

Con esas tres, la mayoría de las contradicciones desaparecen. La complejidad se suma después, cuando el volumen demuestre que hace falta, que es el mismo criterio que Anthropic aplica al diseño de agentes.

Sobre el bloqueo por registro, que es la regla que más gente se salta por parecer excesiva: no hace falta un sistema de bloqueos sofisticado.

Basta con una marca de tiempo y un identificador de agente en el propio registro, y con que cada agente compruebe esa marca antes de escribir. Si otro agente la puso hace menos de un minuto, espera o escala.

Es media hora de trabajo y evita el fallo más silencioso de todos. La complejidad se suma después, cuando el volumen demuestre que la espera simple no basta.

Dónde entra la persona

El supervisor decide qué se escala, pero no decide qué hacer con lo escalado. Eso sigue siendo trabajo de alguien.

Y aquí hay una trampa frecuente: si el supervisor escala demasiado, la cola de casos humanos crece hasta que nadie la mira, y el sistema vuelve a estar sin supervisión real aunque técnicamente todo esté configurado.

El equilibrio se ajusta con dato: se mira cuántos casos escalados se resuelven en menos de un día. Si ese número baja, o el criterio de escalado es demasiado ancho o falta gente.

El principio de fondo es el de human in the loop: la persona no revisa todo, revisa donde el error cuesta caro.

Quién es dueño del supervisor

Es la pregunta que decide si esto sobrevive al primer trimestre.

El supervisor no pertenece a ninguno de los agentes, así que no pertenece a ninguna de las áreas que los operan. Si se deja en manos del área que puso el primer agente, las reglas van a favorecer a ese agente sin que nadie lo decida.

Lo que funciona es que el dueño sea quien responde por la operación completa, no por un proceso. En empresas medianas suele ser la misma persona descrita en quién mantiene los agentes de IA en producción.

Con qué se mide si el supervisor sirve

Tres números, y ninguno es técnico.

• Contradicciones detectadas por mes. Debería tender a cero. Si nunca fue distinto de cero, probablemente no se están detectando.
• Casos escalados que se resuelven en menos de 24 horas. Mide si el escalado es real o es una papelera.
• Tiempo para reconstruir un incidente. De horas a minutos. Es el retorno directo de la función de registro.

El tercero se prueba de una forma incómoda y útil: se elige un caso al azar de la semana pasada y se pide la reconstrucción completa. Lo que tarde es el número.

Hay un cuarto número que conviene mirar aunque no sea del supervisor: cuántas veces al mes alguien pregunta qué pasó con un caso concreto.

Si esa pregunta se hace seguido y la respuesta tarda, el problema de trazabilidad sigue abierto por mucho que el registro exista. Un registro que nadie sabe consultar es equivalente a no tenerlo.

Cuándo NO montarlo

Añadir una capa siempre tiene costo, así que conviene saber cuándo no toca.

• Con un solo agente. No hay nada que coordinar y la capa solo suma un punto de fallo.
• Con agentes que no comparten nada. Si operan en sistemas distintos y no se cruzan, no hay conflicto que resolver.
• Cuando el problema real es un agente mal configurado. Un supervisor no arregla un agente que responde mal: lo tapa.
• Cuando nadie va a mirar los casos escalados. Sin la persona al otro lado, el escalado es un cajón.

Ese tercer punto es el más frecuente. Cuando una empresa pide supervisión suele tener un agente que se equivoca, no un problema de convivencia, y lo que necesita está en qué pasa si un agente de IA se equivoca.