Cómo escalar agentes de IA en una empresa: de uno a varios

El día que el segundo agente empezó a pisarle la respuesta al primero

La escena se repite con variaciones menores en cada empresa que ya superó el primer agente. Tienen uno que clasifica los tickets de soporte y funciona hace meses sin drama. Deciden sumar un segundo que redacta la respuesta automática para los casos simples, y a la primera semana el cliente recibe dos correos distintos sobre el mismo reclamo: uno le dice que el caso está resuelto y el otro le pide más información para resolverlo. Nadie programó ese conflicto a propósito. Simplemente nadie definió qué pasaba cuando el agente de clasificación y el de redacción tocaban el mismo ticket casi al mismo tiempo, cada uno con información parcial.

El equipo técnico revisa el incidente y descubre algo incómodo: no fue un bug de código, fue un vacío de diseño. Cada agente hacía exactamente lo que se le pidió, sin saber que el otro existía. El segundo agente no había duplicado el trabajo del primero, había creado un problema que el primero jamás enfrentó solo: la duplicación de una acción sobre el mismo caso, y la ausencia de una regla que dijera cuál de los dos manda cuando sus conclusiones no coinciden. Esa es la diferencia real entre operar un agente y escalar agentes de IA en una empresa. Uno es un proyecto de automatización. El otro es un proyecto de gobierno.

Antes de preguntarse cuántos agentes hacen falta, conviene resolver esta fricción con el segundo, porque cada agente adicional que se suma sin esa regla clara multiplica el mismo conflicto en vez de multiplicar la capacidad. La pregunta de cuántos agentes de IA necesita una empresa importa menos, al inicio, que la pregunta de qué se rompe cuando el número deja de ser uno.

Qué se rompe exactamente al sumar el segundo agente

Sumar un segundo agente rompe tres cosas a la vez, y las tres suelen descubrirse por accidente en vez de por diseño. La primera es el conflicto entre agentes: dos sistemas autónomos que llegan a conclusiones distintas sobre el mismo caso porque cada uno ve una porción distinta de la información o interpreta la misma información con un criterio distinto. La segunda es la duplicación de acciones: dos agentes que ejecutan la misma tarea (enviar el mismo correo, generar la misma orden, tocar el mismo registro) porque ninguno sabe que el otro ya actuó. La tercera, la más difícil de resolver en una reunión, es la pregunta de quién manda: cuando el agente A dice una cosa y el agente B dice otra sobre el mismo cliente, ¿cuál se ejecuta?

Ninguno de estos tres problemas se arregla escribiéndole un mejor prompt a cada agente por separado, porque el problema no vive dentro de ningún agente individual: vive en el espacio que hay entre ellos. Un agente bien diseñado, evaluado y ajustado puede seguir fallando en producción si nadie definió el protocolo de quién actúa primero, qué pasa si dos coinciden y cómo se revierte una acción duplicada. La fiabilidad de un sistema con varios agentes depende tanto de los límites que se le ponen a cada uno como de la lógica que coordina el conjunto, no solo de la calidad individual de cada modelo por separado.

Datos y memoria compartidos: el terreno donde ocurre el conflicto

Casi todo conflicto entre agentes nace en el mismo lugar: los datos y la memoria que ambos comparten sin saberlo. Si el agente de clasificación escribe un estado en el ticket y el agente de redacción lo lee cinco segundos después, ambos están operando sobre el mismo registro, en el mismo instante, sin ningún acuerdo sobre quién escribe primero ni sobre qué hacer si el otro escribió algo distinto mientras tanto. Cuantos más agentes tocan la misma base de datos, el mismo CRM o la misma bandeja, más veces se repite esa carrera silenciosa entre dos procesos que no se ven entre sí.

La memoria agrava el problema porque no es solo un dato puntual, es contexto acumulado. Si cada agente arrastra su propia memoria de agente de IA sin compartirla con el resto, terminas con dos versiones distintas de la verdad sobre el mismo cliente: una que solo conoce el agente A y otra que solo conoce el agente B. Y si en cambio comparten una memoria única sin control de acceso ni versión, cualquiera de los dos puede sobreescribir lo que el otro acaba de aprender, y nadie se entera hasta que el cliente se queja de una contradicción.

La solución no es elegir entre memoria compartida o memoria separada como si fuera una sola decisión de arquitectura. Es más aburrido que eso: definir, por cada dato relevante (el estado del ticket, el historial del cliente, el resultado de la última acción), quién tiene permiso de escribir y quién solo de leer, y en qué momento se sincroniza esa lectura. Sin esa regla explícita, agregar un segundo agente no suma dos fuentes de valor: suma dos fuentes de error compitiendo por la misma verdad.

Qué agente decide cuando dos coinciden en el mismo caso

Cuando dos agentes llegan a conclusiones distintas sobre el mismo caso, alguien tiene que haber decidido de antemano cuál gana, porque decidirlo en el momento (o peor, dejar que gane el que ejecutó último) es la forma más rápida de perder la confianza del cliente y del equipo que supervisa el sistema. Hay tres formas de resolver esta arbitración que veo funcionar en la práctica, y ninguna es la mejor de forma absoluta: depende de cuánto daño hace un error en ese proceso específico.

• Jerarquía fija: un agente tiene autoridad declarada sobre un tipo de decisión y el resto solo puede sugerir, no ejecutar. Funciona bien cuando el dominio está claro, por ejemplo el agente de cobranza manda sobre el estado de una cuenta y el de atención solo consulta ese estado.
• Prioridad por confianza del dato: gana la conclusión que se basa en la información más reciente o más completa, no la que llegó primero. Exige que cada agente reporte no solo su conclusión sino con qué certeza y sobre qué datos la construyó.
• Escalamiento a una persona: cuando los dos agentes coinciden en que hay desacuerdo (o el sistema detecta que sus conclusiones difieren) el caso se congela y pasa a un humano en vez de ejecutarse solo. Es la opción más lenta y la más segura para decisiones de alto costo si se equivocan.

Lo que no funciona, aunque sea la opción por defecto de la mayoría de integraciones mal planeadas, es no elegir ninguna de las tres a propósito. Cuando nadie define la arbitración, el sistema termina con una regla implícita y peligrosa: gana el agente que se ejecutó último, sin importar si su conclusión era la correcta. Esa regla nunca aparece en ningún documento, y por eso es la más difícil de detectar y corregir cuando empieza a fallar.

El registro común de acciones: sin esto no hay forma de auditar nada

Ningún mecanismo de arbitración sirve si no existe, además, un registro común donde cada agente anota qué hizo, cuándo y con qué justificación, visible para los demás agentes y para el equipo que supervisa el sistema. Sin ese registro, el segundo agente no tiene forma de saber que el primero ya envió una respuesta al mismo ticket hace treinta segundos, y la duplicación de acciones deja de ser un riesgo teórico para volverse un patrón semanal.

Un registro común útil no es una tabla de logs técnicos pensada para depurar código. Es más simple y más operativo que eso: por cada acción de cualquier agente sobre cualquier caso, tiene que quedar quién actuó, sobre qué dato, con qué resultado y en qué momento exacto. Con esos cuatro campos, el segundo agente puede consultar antes de actuar (¿ya hizo algo el otro sobre este caso?) y el equipo humano puede reconstruir qué pasó cuando algo sale mal, sin depender de la memoria de nadie.

La falta de este registro es, en la práctica, la razón número uno por la que monitorear un agente de IA en producción se vuelve imposible apenas hay más de uno operando: no se puede monitorear lo que no queda escrito en ningún lado que sea común a todos los agentes involucrados. Cuando el registro existe desde el segundo agente, escalar al tercero y al cuarto es una extensión del mismo patrón. Cuando no existe, cada agente nuevo agrega una zona ciega distinta.

Cuándo hace falta una capa de orquestación y cuándo es sobreingeniería

La palabra orquestación asusta más de lo que debería, y por eso mismo se usa mal en las dos direcciones: hay empresas que instalan una plataforma de orquestación completa para coordinar dos agentes que apenas se rozan, y empresas que siguen coordinando ocho agentes a mano, por convención verbal entre el equipo, cuando ya hace tiempo que necesitan una capa formal. Ninguno de los dos extremos es gratis.

El criterio que uso para decidir no es el número de agentes, es la frecuencia con la que coinciden sobre el mismo caso y el costo de que esa coincidencia salga mal. Dos agentes que casi nunca tocan el mismo registro (uno lee correos, el otro genera reportes de ventas) pueden coordinarse con una regla simple y el registro común del punto anterior, sin ninguna capa adicional. Dos o tres agentes que compiten todo el día por el mismo ticket, el mismo cliente o la misma cuenta, con una arbitración que cambia según el caso, ya están pidiendo un orquestador: un componente cuyo único trabajo es decidir a quién le toca actuar y en qué orden, antes de que cada agente ejecute algo por su cuenta.

El error de sobreingeniería más común es instalar esa capa de orquestación antes de tener el segundo agente en producción real, basándose en cuántos agentes se planea tener algún día. Una capa de orquestación diseñada sobre supuestos, sin conflictos reales que resolver todavía, termina siendo una arquitectura elegante que nadie sabe si funciona, porque nunca enfrentó el problema para el que fue construida. Conviene entender primero qué es un sistema multiagente y qué problema resuelve exactamente antes de comprarlo o construirlo, y sumar la capa de coordinación cuando el conflicto ya ocurrió al menos una vez en producción, no antes.

Parte de esa capa de orquestación, en la práctica, es más aburrida que sofisticada: estandarizar cómo cada agente se conecta con los sistemas externos y con los demás agentes, en lugar de escribir una integración distinta cada vez que se suma uno nuevo. Cuando esa conexión está estandarizada, sumar el tercer agente es repetir un patrón conocido. Cuando cada agente tiene su propio cableado a medida, cada agente nuevo es un proyecto de integración desde cero, y ahí la sobreingeniería deja de ser el riesgo principal: el riesgo pasa a ser la fragilidad.

El orden de escalado que funciona: primero el segundo, después el resto

El orden que veo funcionar no arranca contando cuántos agentes necesita la empresa a futuro, arranca resolviendo el problema del segundo agente hasta el final antes de pensar en el tercero. Esa disciplina, aburrida y poco vistosa, es la que separa a las empresas que escalan de las que acumulan agentes sueltos que se estorban entre sí.

• Cierra la arbitración del segundo agente primero. Define quién manda cuando los dos coinciden y pruébalo con casos reales, no hipotéticos, durante semanas, antes de sumar un tercero.
• Ordena los datos y la memoria compartida. Deja explícito quién escribe y quién lee cada dato relevante, y verifica que ningún agente sobreescriba silenciosamente lo que el otro acaba de registrar.
• Instala el registro común de acciones antes del tercer agente, no después. Cada agente nuevo que se suma sin ese registro agrega una zona ciega que después cuesta mucho más resolver con tres o cuatro agentes activos que con dos.
• Recién ahí evalúa si hace falta una capa de orquestación formal. Si el conflicto entre el segundo y el tercer agente ya es frecuente y costoso, es momento de invertir en coordinación explícita. Si no, la coordinación manual bien documentada todavía alcanza.
• Suma un agente a la vez, no un lote. Cada agente nuevo introduce combinaciones de conflicto con todos los que ya existen, y esas combinaciones crecen más rápido que el número de agentes: sumar de a uno es la única forma de detectar cuál conflicto nuevo trajo cuál agente.

Este orden es una versión, a nivel de agentes individuales, del mismo principio que aplica cuando se trata de escalar un piloto de IA exitoso a toda la empresa: lo que funcionó en un caso aislado no se replica multiplicando el número, se replica resolviendo primero la fricción que aparece exactamente al pasar de uno a dos, porque esa fricción es la misma que se repetirá, agravada, al pasar de dos a diez.

Mi criterio sobre por qué la mayoría se salta este paso

Escalar no es sumar agentes, es sumar acuerdos antes que agentes

El segundo agente de IA no falla porque el modelo sea peor ni porque la tarea sea más difícil. Falla porque la empresa trató una decisión de gobierno (quién manda, quién escribe qué dato, qué queda registrado) como si fuera un detalle técnico que se resuelve solo con más cómputo. Cada agente adicional que se suma sin haber cerrado esos acuerdos no multiplica la capacidad de la empresa: multiplica la cantidad de conflictos sin resolver que ya tenía con uno solo.

Esto es, en el fondo, el mismo criterio que sostiene a cualquier despliegue serio de agentes de IA empresariales dentro del framework Arquitectura IA: la tecnología rara vez es el cuello de botella, el cuello de botella es la claridad sobre quién decide qué, escrita antes de que el sistema tenga que decidirlo solo. La empresa que resuelve esto con el segundo agente, aunque sea con una regla simple y aburrida, escala al tercero, al cuarto y al décimo sin sorpresas nuevas. La que lo salta, vuelve a pelear la misma guerra cada vez que suma uno, y cada vez con más agentes enredados entre sí.