Hay un momento bastante fácil de reconocer en un equipo que ha adoptado agentes de IA: alguien pregunta «¿quién está haciendo esto ahora?» y la respuesta tarda demasiado.
No porque falten herramientas, sino porque sobran. Un agente clasifica tickets, otro redacta respuestas, otro actualiza el CRM y un cuarto resume lo ocurrido. Cada uno funciona razonablemente bien por separado. El problema aparece en las costuras: dos sistemas tocan el mismo dato, una excepción no tiene dueño o una respuesta automática contradice la decisión que tomó otro flujo diez minutos antes.
A eso llamamos aquí fatiga de agentes. No es un diagnóstico técnico ni una categoría formal. Es una forma útil de describir un problema operativo: automatizaste tareas, pero aumentaste la cantidad de cosas que alguien debe vigilar.
El costo oculto no es la licencia: son las excepciones
Automatizar una tarea repetitiva suele ser sencillo mientras todo ocurre como estaba previsto. El verdadero costo aparece cuando algo sale del camino feliz.
Imagina un agente de soporte que puede devolver dinero hasta cierto monto. Funciona bien la mayor parte del tiempo. El resto incluye pagos duplicados, clientes con dos cuentas, promociones vencidas, solicitudes sospechosas y casos que requieren consultar a finanzas. Esos casos necesitan reglas, registros y una persona que pueda intervenir.
Ahora suma tres agentes más. No estás multiplicando solamente automatizaciones; también estás multiplicando fronteras entre sistemas. Y esas fronteras son donde suelen nacer las preguntas difíciles: cuál dato manda, qué agente tiene prioridad, quién puede deshacer una acción y qué pasa cuando dos herramientas llegan a conclusiones distintas.
Una señal más útil que contar agentes
No existe un número mágico a partir del cual un equipo tenga «demasiados agentes». Cinco pueden ser perfectamente manejables y dos pueden ser un desastre.
La señal que sí sirve es esta: ¿puedes dibujar en una sola página qué hace cada agente, qué datos toca, qué puede ejecutar sin permiso y quién responde cuando algo sale mal?
Si no puedes, el problema no se arregla comprando un panel más sofisticado. Primero hay que recuperar la trazabilidad.
| Pregunta | Lo que conviene poder responder |
|---|---|
| ¿Qué flujo toca? | Una tarea concreta, no «marketing» u «operaciones». |
| ¿Qué puede hacer sin aprobación? | Leer, escribir, enviar, borrar, aprobar, comprar o modificar registros. |
| ¿Qué sistemas o datos consulta? | CRM, correo, Drive, ERP, base de clientes, etc. |
| ¿Cómo se detiene? | Un mecanismo conocido por más de una persona. |
| ¿Quién es responsable? | Una persona o rol operativo claramente identificable. |
| ¿Cómo sabemos que sigue funcionando bien? | Muestras revisadas, excepciones, errores y cambios recientes. |
El caso típico: diez decisiones razonables que juntas crean un problema
La fragmentación rara vez comienza con una mala compra. Marketing encuentra una herramienta que redacta bien. Soporte prueba otra que clasifica tickets. Finanzas automatiza facturas. Operaciones conecta un agente al calendario. Cada decisión tiene sentido en su contexto.
Meses después, nadie diseñó deliberadamente el sistema que ahora existe. Simplemente apareció por acumulación.
Ese detalle importa porque muchas empresas intentan resolver el desorden evaluando otra herramienta: un orquestador, un panel de observabilidad o un agente «supervisor». A veces hace falta. Pero si el problema original es que nadie definió propiedad y límites, añadir otra capa solo vuelve más difícil saber dónde empezó el error.
Qué consolidar primero
Yo empezaría por las zonas donde dos automatizaciones pueden actuar sobre el mismo objeto: el mismo cliente, el mismo documento, la misma factura o la misma oportunidad comercial.
- Busca solapamientos. Si dos agentes pueden modificar el mismo registro, define cuál manda y en qué condiciones.
- Separa lectura de acción. Un agente que resume información no tiene el mismo riesgo que uno que envía, aprueba o borra.
- Cuenta excepciones, no demos exitosas. El flujo se debe diseñar alrededor de lo que pasa cuando el modelo no sabe qué hacer.
- Retira lo que nadie echaría de menos. Si una herramienta lleva semanas activa y nadie puede explicar qué proceso se rompería al apagarla, merece una prueba de retiro.
Un ejercicio de 30 minutos
Pon en una hoja todos los agentes y automatizaciones que hoy pueden actuar por su cuenta. No los que compraron alguna vez: los que de verdad están conectados a algo.
Al lado escribe cuatro cosas: entrada, acción, salida y responsable. Si una fila necesita tres párrafos para explicarse, ahí ya encontraste una señal. Si dos filas tienen casi la misma entrada y la misma salida, encontraste otra.
Después escoge un flujo real —por ejemplo, «entra una solicitud de reembolso»— y síguelo de principio a fin. ¿Cuántos sistemas intervienen? ¿Dónde cambia de dueño? ¿Qué ocurre si uno falla? ¿Se puede reconstruir después quién hizo qué?
Este ejercicio suele producir más claridad que una comparación de veinte plataformas, porque obliga a mirar el sistema que ya existe en lugar del sistema ideal que aparece en las demos.
La automatización buena debería reducir la vigilancia
Hay una prueba que me parece especialmente útil: después de tres meses, ¿el equipo necesita mirar menos cosas para que el proceso funcione?
Si la respuesta es sí, probablemente la automatización está absorbiendo complejidad. Si la respuesta es no —si ahora hay más paneles, más alertas, más revisiones manuales y más dudas sobre qué sistema tomó una decisión—, puede estar desplazando el trabajo en vez de eliminarlo.
Eso conecta con un problema más amplio que ya hemos discutido en la trampa del AI-Ready: una tecnología puede ser impresionante y aun así empeorar un flujo concreto.
Los agentes tienen sentido cuando se quedan con trabajo repetitivo y dejan al humano las excepciones que realmente merecen juicio. Cuando el humano termina convertido en supervisor permanente de cinco sistemas autónomos, el diseño se dio la vuelta.
