Cuántos agentes de IA necesita una empresa

Diez agentes después, nadie recuerda para qué se creó cada uno

Vi este patrón en una empresa mediana de servicios financieros. El primer agente resolvía algo puntual y doloroso: clasificar reclamos entrantes para que el equipo de atención no perdiera media mañana leyendo correos para decidir a quién derivar cada caso. Funcionó, y funcionó rápido. El error no fue construir ese agente: fue lo que pasó después. En menos de un año, cada gerencia pidió el suyo porque había visto la demora que el primero le ahorró al área vecina. Marketing tenía un agente para redactar publicaciones, ventas tenía uno para resumir llamadas, finanzas tenía uno para conciliar facturas, y nadie preguntó si esos procesos merecían un agente propio o si convenía juntarlos de otra forma.

El síntoma no es sutil. Cuando alguien nuevo entra al equipo, nadie puede explicarle en una frase qué hace cada agente ni por qué existe. Dos agentes terminan haciendo tareas parecidas porque ningún catálogo central impide la duplicación. El área de sistemas empieza a recibir tickets de soporte de herramientas que ni siquiera sabía que estaban en producción. Y cuando llega el momento de medir el retorno de todo ese esfuerzo, no hay una sola respuesta: hay siete respuestas parciales, ninguna con el mismo criterio de éxito. El error no ocurrió con el décimo agente. Ocurrió con el segundo, el día que nadie preguntó si ese proceso en particular necesitaba uno.

La pregunta correcta no es cuántos, es cuántos procesos lo piden

Cuando una empresa pregunta cuántos agentes necesita, en realidad está pidiendo un número que la tranquilice: tres si es pequeña, quince si es grande, algo que quepa en un presupuesto anual. Ese número no existe, y perseguirlo es la forma más rápida de terminar con una flota de agentes que nadie diseñó, solo acumuló. La pregunta útil no habla de agentes: habla de procesos. Un proceso es una secuencia de pasos que alguien repite, con una entrada, una salida y una forma de medir si salió bien. Un agente tiene sentido cuando existe un proceso así, con volumen suficiente para justificar el trabajo de automatizarlo y con un criterio claro de qué es un resultado correcto.

Esa reformulación cambia la conversación completa. En vez de reunir a los gerentes para repartir agentes por área (uno para marketing, uno para ventas, uno para soporte) el ejercicio correcto es listar los procesos que ya existen, con su volumen y su costo de error, y preguntar caso por caso si ese proceso puntual merece un agente dedicado. Casi siempre la lista de procesos que de verdad lo justifican es más corta que la lista de departamentos. Y casi siempre alguno de esos procesos, mal delimitado, necesita dos agentes en vez de uno, porque mezclaba dos tareas que no debían compartir la misma lógica.

Por qué el agente va por proceso y no por área

Un área es una etiqueta organizacional, no una unidad de trabajo. “Marketing” incluye redactar publicaciones, programar campañas, responder comentarios, armar reportes de desempeño y coordinar con agencias externas: son procesos distintos, con volúmenes distintos y con distinto costo cuando algo sale mal. Diseñar “un agente de marketing” obliga a ese agente a cargar con la lógica de cinco tareas que no tienen nada en común entre sí, y el resultado casi siempre es un agente mediocre en las cinco, porque su alcance nunca quedó bien definido desde el diseño.

Un proceso, en cambio, tiene bordes claros: empieza con una entrada reconocible (un correo, un formulario, un archivo), sigue una lógica que se puede describir en pasos y termina en un resultado que se puede calificar de correcto o incorrecto. Esa es la unidad que un sistema multiagente puede sostener con criterio: cada agente responde por un proceso, no por un área completa, y cuando dos procesos se relacionan, se conectan entre agentes en vez de mezclarse dentro de uno solo. Pensar por área es cómodo para el organigrama. Pensar por proceso es lo único que funciona cuando hay que mantener y medir lo que se construyó.

Las señales de que a la empresa le faltan agentes, no que le faltan más personas

El reflejo típico cuando un proceso se atrasa es pedir una persona más. A veces es la respuesta correcta. Otras veces el proceso ya tiene el volumen y la repetición suficientes para que un agente lo sostenga, y seguir sumando personas solo reparte el mismo problema entre más manos. Estas son las señales que reviso antes de recomendar sumar un agente nuevo:

• El volumen crece más rápido que el equipo. Cada trimestre entran más casos del mismo tipo y contratar a ese ritmo deja de ser sostenible, aunque el presupuesto lo permita.
• El trabajo es repetitivo y la variación entre casos es baja. La misma decisión, con las mismas reglas, sobre datos parecidos. Cuando la variación es alta, el proceso todavía necesita criterio humano caso por caso.
• Alguien del equipo hace de “puente” entre sistemas que no se hablan. Copia datos de un sistema a otro, revisa manualmente lo que ya está en una base y solo reescribe información sin agregar juicio propio.
• El tiempo de respuesta ya no cumple lo que el negocio necesita. El cliente o el área interna espera más de lo razonable porque el volumen superó la capacidad de revisión manual.
• El proceso ya está documentado y estable. No está en construcción ni cambia de criterio cada semana: eso es justo lo que un agente necesita para operar con confianza.

Cuando dos o tres de estas señales coinciden en el mismo proceso, ese proceso está listo para un agente. Es también el momento de revisar cómo escalar de un agente a varios sin repetir el error de sumarlos por entusiasmo de área en vez de por necesidad real de proceso.

Las señales de que ya sobran agentes en la empresa

El exceso es menos visible que la falta, porque nadie nota que algo sobra hasta que alguien pregunta cuánto cuesta mantener todo eso. Estas son las señales que encuentro cuando audito una flota que creció sin criterio:

• Dos agentes hacen prácticamente lo mismo porque dos áreas distintas construyeron su versión sin saber que la otra ya existía.
• Nadie puede nombrar quién es dueño de cada agente ni quién decide si se apaga, se actualiza o sigue vivo por inercia.
• El uso real cayó y nadie lo revisó. El agente se construyó para un proceso que cambió o desapareció, y sigue corriendo porque apagarlo da pereza o miedo.
• El costo de mantenimiento supera el valor que entrega. Cada actualización de un sistema conectado obliga a tocar el agente, y ese esfuerzo ya no se justifica con lo que ahorra.
• Nadie audita las respuestas que da. Un agente sin revisión periódica puede llevar meses tomando decisiones sobre un criterio que ya quedó viejo, sin que nadie lo note.

El costo de un agente no termina el día que se construye: sigue corriendo mientras existe, y alguien tiene que responder por él. Esa es exactamente la razón por la que un servicio gestionado de agentes de IA existe como categoría: no para sumar más agentes, sino para que alguien sea responsable de apagar los que ya no aportan y de mantener sano el resto.

El punto donde la flota deja de ser una lista y necesita orquestación

Mientras cada agente resuelve su proceso de forma aislada, alcanza con una lista: qué agente existe, qué proceso cubre, quién lo mantiene. El problema aparece cuando la salida de un agente empieza a ser la entrada de otro. El agente que clasifica un reclamo tiene que pasarle el caso al agente que redacta la respuesta, que a su vez depende de que el agente que consulta el historial del cliente le entregue el contexto correcto. En ese momento ya no hay una lista de agentes independientes: hay un flujo, y un flujo necesita alguien o algo que decida el orden, que resuelva qué pasa si un paso falla y que evite que dos agentes actúen sobre el mismo caso al mismo tiempo.

Esa capa se llama orquestación de agentes, y la señal más clara de que ya la necesitas no es el número de agentes que tienes, es que empezaste a resolver a mano, por chat interno o por hoja de cálculo, la coordinación entre ellos. Si alguien del equipo tiene que avisarle manualmente a un agente que otro ya terminó su parte, la empresa ya está haciendo orquestación, solo que la está haciendo una persona en vez de un sistema diseñado para eso. Meter orquestación antes de tener ese problema es complejidad de más. Meterla después de tenerlo y seguir resolviéndolo a mano es el error contrario.

El costo real de multiplicar agentes sin criterio

El costo visible de un agente es el que aparece en la factura del proveedor o en las horas de quien lo construyó. Ese no es el costo que rompe el proyecto. El costo real aparece después: en el tiempo que alguien del equipo pasa decidiendo cuál de los tres agentes parecidos usar hoy, en el soporte que consume un agente que nadie recuerda haber pedido, en el riesgo de que un agente con acceso a datos sensibles siga activo después de que la persona que lo mantenía dejó la empresa. Cada agente adicional no es solo una herramienta más: es una superficie más que alguien tiene que vigilar, actualizar y, eventualmente, justificar frente a quien pregunta para qué sirve.

Esto conecta directo con algo que discuto seguido con equipos que arman agentes de IA empresariales: la gobernanza no es un capítulo aparte que se agrega al final, es parte del costo real de cada agente desde el día en que se aprueba construirlo. Una empresa que multiplica agentes sin un dueño, sin un criterio de cuándo apagarlos y sin un registro central de qué existe, no está acelerando su adopción de IA: está acumulando deuda técnica con apariencia de innovación. El entusiasmo inicial no distingue entre sumar valor y sumar superficie de riesgo, y esa distinción es exactamente el trabajo que alguien tiene que hacer antes de aprobar el siguiente agente.

El orden en que conviene sumar agentes, uno a la vez

El orden que funciona no es por área ni por quién pidió primero. Es por dolor medible: se empieza por el proceso con más volumen, más repetición y más costo cuando se hace mal o tarde. Ese primer agente se termina, se mide contra el desempeño anterior del proceso (no contra una promesa) y solo entonces se decide el segundo. El error más común es al revés: aprobar cinco agentes a la vez porque “ya que estamos automatizando, hagámoslo todo junto”, sin que ninguno llegue a medirse de verdad antes de que empiece el siguiente.

• Primero, el diagnóstico de procesos, no de tecnología: qué se repite, cuánto cuesta el error, qué tan bien documentado está el criterio actual.
• Segundo, el proceso de mayor dolor con menor complejidad, para conseguir una victoria medible rápido y con bajo riesgo.
• Tercero, medir contra el desempeño anterior, con el mismo criterio con el que se medía antes de tener el agente, no con una expectativa nueva inventada para la ocasión.
• Cuarto, recién ahí el siguiente proceso, eligiendo si conviene un agente nuevo, ampliar el alcance del existente o esperar a que haya orquestación para conectarlos.

Ese orden también determina si conviene construir cada agente puertas adentro o contratarlo como servicio. La decisión de agentes de IA como servicio o desarrollo propio no se toma una sola vez para toda la empresa: se toma proceso por proceso, según cuánto control necesita ese caso puntual y cuánto tiempo interno hay disponible para mantenerlo.

Cuántos agentes necesita tu empresa, en criterio y no en entusiasmo

No hay un número que responda esta pregunta para toda empresa, y cualquiera que lo ofrezca sin conocer tus procesos está vendiendo una plantilla, no un diagnóstico. El número correcto sale de contar procesos, no departamentos: cuántos son repetitivos, medibles y dolorosos hoy, y de esos, cuántos ya están lo bastante documentados como para confiarle el criterio a un agente. Para la mayoría de empresas medianas ese número inicial es más bajo de lo que el entusiasmo del equipo sugiere: dos o tres procesos bien elegidos, no diez agentes repartidos por cortesía entre todas las áreas.

Lo que sí es universal es el criterio para decidir el siguiente agente: que exista un proceso real detrás, que alguien sea su dueño, que haya forma de medir si funcionó y que sumarlo no rompa la posibilidad de coordinar lo que ya existe. Una empresa que aplica ese filtro cada vez que alguien pide “un agente más” termina con una flota pequeña que puede explicar y sostener. La que no lo aplica termina, tarde o temprano, con la misma escena del principio: varios agentes sueltos, ningún dueño claro y la pregunta de cuántos hacen falta llegando demasiado tarde, cuando ya tocaría preguntarse cuántos sobran. Ese es el trabajo de fondo de una empresa AI Native: no acumular herramientas, sino tener el criterio para saber cuáles de verdad ganaron su lugar.