Cada equipo quiere su propio agente, y es la misma conversación que la industria ya tuvo hace años, con otro nombre. Entonces era la nube: cada quien quería la suya para no depender del proveedor del vecino, y la promesa era la misma que ahora. Independencia. Que nadie te bloquee. Avanzar sin esperar a nadie. El agente propio se vende como el fin de la fila: tu equipo deja de depender del backlog del equipo de plataforma y se mueve a su ritmo. Suena a libertad, y por eso cuesta ver que es exactamente la decisión que convirtió a la multinube en la peor práctica.
La tesis es esta: darle un agente autónomo a cada equipo o a cada tarea no es gratis solo porque construir el agente ahora sea barato. El costo no desapareció, se mudó. Antes el costo estaba en fabricar el agente; ahora está en hacer que todos esos agentes se pongan de acuerdo. Y ese segundo costo no crece con la cantidad de agentes: crece mucho más rápido. La palanca del arquitecto dejó de ser cuántos agentes tiene y pasó a ser sobre qué se coordinan.
La flota de drones que reemplaza al avión de carga
Gregor Hohpe cuenta en The Mighty Metaphor el ejemplo de reemplazar un avión de carga grande por una flota de drones autónomos. La imagen es seductora: en vez de una máquina cara, central y con un único punto de fallo, tienes muchas unidades baratas, resilientes y que se compran de a una. Si cae un dron, caen cien kilos de paquetes, no el envío entero. Puedes escalar comprando más. Cada dron, por separado, es más simple que el avión.
Pero Hohpe usa ese mismo ejemplo para marcar dónde se esconde el costo, y es justo lo que importa aquí. El avión traía incluido un montón de trabajo que no veíamos porque venía resuelto de fábrica: un piloto que coordina, un plan de vuelo único, una bodega que acepta cajas de cualquier tamaño. Cuando lo partes en cien drones, ese trabajo no desaparece: se vuelve tuyo y se multiplica. Ahora necesitas control de tráfico aéreo para que los drones no choquen, necesitas repartir cada envío en paquetes del tamaño que un dron puede cargar, y necesitas un sistema que sepa dónde está cada uno. El avión era caro de comprar; la flota es cara de coordinar.
La metáfora aguanta la prueba que el propio Hohpe exige, que no basta con que la imagen se parezca sino que las dinámicas coincidan. Y coinciden en lo que decide: agregar una unidad es barato, pero cada unidad nueva encarece la coordinación de todas las demás. Un dron más son unos cientos de dólares; un dron más también es una trayectoria más que el control de tráfico tiene que vigilar contra todas las otras. Con los agentes pasa igual. Lanzar un agente nuevo hoy es cuestión de horas; hacer que ese agente comparta contexto, identidad y resultados con los que ya existen es el trabajo que crece sin que nadie lo esté mirando.
¿Por qué el costo se dispara si solo agregué un agente más?
Porque la coordinación no se paga por agente, se paga por par de agentes que tienen que entenderse. Y los pares crecen mucho más rápido que los agentes.
Hagamos la cuenta, con los supuestos a la vista para que la rehagas con los tuyos. Supón que cada agente, para hacer su trabajo, necesita hablar con cada uno de los demás: pasarle contexto, pedirle un resultado, enterarse de lo que ya hizo. Si cada par necesita su propio canal de integración, el número de canales es , no .
- Con 2 agentes, 1 canal. Trivial.
- Con 4 agentes, 6 canales.
- Con 10 agentes, 45 canales.
- Con 20 agentes, 190 canales.
Duplicaste los agentes de 10 a 20 y los canales se cuadruplicaron. Esa es la trampa: la gráfica de agentes es una línea y la de canales es una curva, y al principio van casi juntas, así que con tres o cuatro agentes nadie siente el problema. Es un costo distinto del que ya conté en El código es inventario, no un activo: ahí el agente barato llenaba el almacén de código; aquí llena el mapa de integraciones que hay que coordinar. Dos facturas del mismo abaratamiento. El problema llega cuando cada equipo, razonablemente, lanzó el suyo, y de pronto hay dieciocho agentes y ciento cincuenta y tres integraciones que nadie diseñó, que nadie documentó y que se rompen de a una.
Ahora cambia el supuesto. En vez de que cada agente hable con cada agente, haz que cada agente hable con un sustrato compartido: un lugar donde dejar y leer el contexto, una identidad común, un bus por donde pasan los resultados. Entonces cada agente tiene un solo canal, el que lo conecta al sustrato, y el total es . Con 20 agentes son 20 cables en vez de 190.
Todos contra todos, los canales son y explotan; contra un sustrato compartido, son y crecen en línea recta.
No es que el sustrato haga desaparecer la complejidad. La concentra en un sitio donde se diseña una vez y se mantiene una vez, en lugar de repartirla en ciento noventa integraciones que se mantienen ciento noventa veces. Es la misma lección del mínimo común denominador: la multinube no fallaba porque tener dos proveedores fuera malo, fallaba porque te obligaba a coordinar todo al nivel de lo que los dos tenían en común, y ese trabajo de coordinación se comía la ventaja de cada proveedor. Un agente por equipo te lleva al mismo lugar: terminas coordinando a mano, al nivel más bajo, lo que cada agente podría hacer bien por su cuenta.
Sé lo que vas a decir
Ya lo sé: cada equipo quiere su propio agente para no esperar al de al lado. Si todos dependemos de una plataforma central, volvimos al cuello de botella que veníamos a eliminar.
Es la objeción correcta, y tiene una parte de razón: una plataforma compartida mal hecha es un cuello de botella, igual que un control de tráfico aéreo saturado deja a todos los drones en tierra. Pero fíjate en lo que estás comparando. El sustrato compartido no es un equipo central que aprueba cada acción; es un conjunto de primitivas sobre las que cada agente se mueve solo. El control de tráfico aéreo no pilotea los drones: les da un espacio común, reglas de precedencia y una forma de saber dónde está cada quien, y después cada dron vuela. La autonomía no se toca; lo que se comparte es el terreno sobre el que se ejerce.
Y hay una asimetría que la prisa esconde. Saltarte el sustrato acelera hoy: tu equipo lanza su agente esta semana sin pedirle nada a nadie. Pero el canal que no diseñaste no desaparece, lo hereda quien venga después a hacer que tu agente hable con el suyo, y lo paga con intereses. Es la misma dinámica de la autonomía como firma en blanco: la libertad se concede barata y se recupera cara. Un agente suelto se lanza en una tarde; desenredar dieciocho agentes que se integraron de a pares, cada uno a su manera, es un proyecto de un trimestre.
Y antes de que lo pienses: no, la respuesta no es prohibir que los equipos tengan agentes y centralizarlo todo en uno solo. Eso es volver al avión de carga, con su único punto de fallo y su cola de espera. La flota de drones es buena idea; lo que decide si funciona es que exista el control de tráfico aéreo antes de que haya cien drones en el aire, no después del primer choque.
El dilema es falso: la pregunta no es cuántos agentes, sino sobre qué se coordinan.
¿Y esto es un patrón de la industria o una creencia mía?
Es un patrón, y la mejor evidencia es que la propia industria ya está construyendo el sustrato antes de que la mayoría note que lo necesita. Amazon Bedrock AgentCore no vende «un agente»: vende las primitivas sobre las que corren muchos: una identidad común para que todos los agentes se autentiquen igual, una memoria y un contexto que se comparten en vez de reconstruirse en cada agente, y una puerta de enlace por la que entran las herramientas. Es, literalmente, control de tráfico aéreo para flotas de drones. El producto no es el dron; es el espacio aéreo.
Lo mismo se ve desde el otro extremo con Kiro y su desarrollo dirigido por especificaciones: la spec es el terreno común que varios agentes leen para no contradecirse, el documento sobre el que se coordinan sin tener que hablar entre ellos. En los dos casos el valor dejó de estar en el agente individual y se mudó al sustrato que comparten.
Y hay una razón más vieja que todo esto por la que el problema aparece aun si nadie lo diseñó. Si cada equipo construye su propio agente, el sistema de agentes termina copiando el organigrama: tantos agentes como equipos, integrados tan mal como se hablen los equipos entre ellos. Es la ley de Conway, que Melvin Conway formuló en 1968: un sistema termina con la forma de la estructura de comunicación de quien lo construye. Un agente por equipo no es una decisión de arquitectura, es el organigrama filtrándose dentro del software. Y el organigrama nunca fue un buen diagrama de arquitectura.
Un agente por equipo no te da libertad: te da el impuesto de coordinación de la multinube, repartido en integraciones que nadie firmó.
Mi sugerencia
El lunes, lleva una sola pregunta a tu próxima revisión de arquitectura: antes de aprobar el próximo agente, ¿sobre qué sustrato compartido se va a coordinar con los que ya tenemos? Si la respuesta es «se integra directo con el agente del equipo de datos», acabas de autorizar un canal más de la curva, no un cable al bus. No es que el agente nuevo esté mal; es que lo estás colgando del lugar equivocado.
Y si quieres algo más concreto todavía, haz el ejercicio con números en la próxima reunión: cuenta cuántos agentes hay hoy en producción, cuenta cuántas integraciones punto a punto los conectan, y proyecta las dos curvas a seis meses con el ritmo al que los equipos están lanzando agentes. Si la curva de integraciones ya va más empinada que la de agentes, no tienes un problema de velocidad: tienes un almacén de canales, y el sustrato compartido es la decisión que lo aplana. Decídelo antes del dron número cien, no después del primer choque. ;)