Cohere propone que los agentes de IA duplicados compitan por su puesto en la empresa

El 15 de octubre de 2026, Cohere publicó en su blog corporativo un artículo sobre lo que ocurre cuando los empleados empiezan a crear agentes de IA por su cuenta y no existe un equipo central que los controle. El autor, el arquitecto sénior de soluciones Kasim Patel, describe un escenario habitual: hay cada vez más agentes, nadie conoce la lista completa, los equipos no encuentran lo que ya está hecho y resulta cada vez más difícil controlar el acceso a los datos y sistemas corporativos. Patel llama a este estado agent sprawl. La receta de la compañía: no intentar suprimir los duplicados, sino hacer que compitan entre sí.

El artículo sirve además de escaparate para North 2, la plataforma agéntica segura de Cohere, que funciona junto a los datos del cliente. El texto no aporta cifras que respalden sus tesis, como el porcentaje de agentes duplicados o el ahorro obtenido. Es más un marco de reflexión que un estudio.

El aumento del número de agentes todavía no es un problema

Patel disipa de entrada el principal temor. Las plataformas que provocan el sprawl abaratan la experimentación. Los empleados no tienen que acudir cada vez al equipo central de IA o de desarrollo: quienes están más cerca del proceso ven mejor qué se puede automatizar en él. Un agente que funciona bien en un equipo puede servir a otro, y entonces la expansión de agentes indica que las personas buscan activamente aplicaciones.

El texto aborda por separado la cuestión de los costes. Un agente que nadie utiliza no consume tokens por el mero hecho de existir. Que haya más agentes no implica necesariamente una factura de inferencia mayor. La carga aparece cuando los procesos de gestión no siguen el ritmo del número de agentes. Es entonces cuando la proliferación se convierte en sprawl.

Tres modelos y un registro

Hoy las empresas eligen sobre todo entre tres esquemas:

• centralizado: un equipo central construye los agentes y responde de ellos. El control es más estricto, pero el ritmo de innovación es menor;
• federado: las unidades de negocio son dueñas del desarrollo y la operación, mientras que el centro aporta la infraestructura, los estándares y las plantillas de gobernanza;
• híbrido: la responsabilidad se reparte entre el centro y el negocio bajo estándares comunes.

En los tres casos aparece cada vez con más frecuencia un registro de agentes. Este recoge el propietario, el uso y los permisos de acceso, y ayuda a los empleados a encontrar lo que ya se ha construido. La lógica es clara: primero reutiliza, luego crea. Hay menos opciones solapadas entre las que elegir y menos agentes que monitorizar y auditar.

Pero el principio de «ningún duplicado» tiene un coste. Si la mera existencia de un agente que funciona cierra el paso a las alternativas, la organización no llegará a saber qué se podría hacer de forma más barata, más fiable o más precisa para una tarea concreta.

Aspirante frente a agente en funciones

Cohere propone considerar la duplicación como algo temporal. Si un equipo tiene motivos convincentes para creer que puede mejorar al agente «en funciones», se le permite construir un «aspirante». Pero este solo sigue en producción si demuestra una ventaja medible. Para ello hace falta una comparación basada en datos y limitada en el tiempo. El conjunto de métricas depende del caso de uso, y como ejemplos se citan:

• fiabilidad;
• consumo de tokens;
• latencia de respuesta.

En el fragmento del texto al que se tiene acceso, la lista se interrumpe, así que aquí no se detallan ni el listado completo de criterios ni los pormenores del procedimiento.

Cómo aplicarlo en la práctica

La idea se puede poner a prueba sin comprar ninguna plataforma. Primero, cree un registro con el propietario, los permisos de acceso y las estadísticas de uso de cada agente. Sin él no hay nada que comparar. Segundo, defina de antemano qué se considera una ventaja: por ejemplo, menos tokens por tarea con la misma fiabilidad. Tercero, fije un plazo: un piloto sin fecha límite se convierte enseguida en otro agente permanente. Cuarto, decida qué ocurre con el perdedor: se desactiva, se archiva o se fusiona con el ganador.

Queda una cuestión que el artículo no aborda: quién paga por el funcionamiento en paralelo de dos agentes durante la prueba y cómo compararlos con datos reales, y no con datos convenientes. Estos detalles determinarán si el modelo se convierte en una herramienta de selección o en una capa más de burocracia.