Cinco agentes de IA no hacen el trabajo cinco veces más rápido: la ley de Brooks aplicada a la automatización

Una empresa mediana recibe entre mil quinientas y tres mil facturas de proveedores al mes. Alguien tiene que abrir cada una, encontrar la orden de compra que le corresponde, comparar cantidades y precios, y apartar las que no cuadran para que las revise una persona. En la mayoría de las empresas ese trabajo lo hacen dos o tres personas de cuentas por pagar, y les come la primera semana de cada mes.

Cuando se automatiza con un agente de inteligencia artificial y funciona, aparece de inmediato la misma idea en todas las juntas: si uno funcionó, pongamos diez. Uno que lea, otro que busque la orden, otro que compare, otro que revise al que comparó, un coordinador que reparta el trabajo. La intuición dice que diez agentes harán el trabajo diez veces más rápido, o diez veces mejor.

Esa intuición lleva cincuenta años siendo falsa, y hay un nombre para el error.

Lo que pasó en IBM en 1975

Fred Brooks dirigió el desarrollo del sistema operativo OS/360 en IBM, uno de los proyectos de software más grandes que se habían intentado hasta entonces. Iba retrasado. La decisión fue meterle más programadores, cientos. El proyecto se retrasó todavía más.

Brooks escribió después The Mythical Man-Month, donde formuló lo que hoy se conoce como ley de Brooks: agregar personal a un proyecto de software retrasado lo retrasa más. Y explicó por qué, con tres razones que no tienen que ver con la calidad de la gente que se contrata.

La primera: al que llega hay que ponerlo al día, y eso lo hacen los que ya estaban. Mientras enseñan, no producen. La segunda: hay trabajos que no se parten en pedazos. Brooks lo dijo con una frase que se quedó: nueve mujeres no hacen un bebé en un mes. La tercera es la que más pesa: cada persona nueva multiplica los canales de comunicación que hay que mantener.

Esa tercera se puede calcular. Los canales entre miembros de un equipo son n por n menos uno, entre dos. Con cinco personas son diez canales. Con diez personas son cuarenta y cinco. Con veinte son ciento noventa. El equipo crece en línea recta y la conversación crece al cuadrado.

Cómo se resuelve hoy sin agentes

En una empresa mediana mexicana, la conciliación de facturas contra órdenes de compra se resuelve de tres formas. La primera es a mano, con el sistema abierto en una pantalla y el correo en la otra. La segunda es con las reglas del propio ERP, que atrapan lo fácil —coincidencia exacta de folio y monto— y dejan pasar todo lo demás. La tercera es un lector de documentos que extrae los campos y los deja en una hoja para que alguien decida.

Las tres funcionan razonablemente para las facturas que vienen bien. El trabajo de verdad está en el diez o quince por ciento que no cuadra: entregas parciales, notas de crédito, cambios de precio pactados por teléfono, proveedores que facturan tres órdenes juntas. Ahí es donde se van los días.

Qué cambia con un agente y qué no

Un agente bien puesto sí resuelve buena parte de ese diez por ciento, porque puede leer el correo donde el proveedor explica la entrega parcial y relacionarlo con la factura. Eso una regla del ERP no lo hace.

Lo que no cambia es que multiplicar agentes multiplica el trabajo de coordinación, exactamente igual que con personas. Cada agente que se suma tiene que recibir contexto —qué se lleva revisado, qué decidió el anterior, qué excepciones aplican a ese proveedor— y ese contexto se paga en tokens en cada llamada, no una sola vez.

Y hay un segundo efecto, más reciente y peor conocido en las juntas de dirección. La otra respuesta habitual cuando algo no sale es dejar que el modelo razone más largo. Un equipo de Anthropic con colaboradores académicos publicó en julio de 2025 un trabajo sobre escalado inverso en tiempo de inferencia: construyeron tareas donde alargar el razonamiento empeora el resultado. Encontraron cuatro familias de fallo, y una de ellas aparece en cualquier proceso administrativo real: cuando el enunciado trae información irrelevante —una cifra que no viene al caso, un bloque de datos que sobra— el modelo se engancha con ella conforme razona más.

Una factura real trae mucho de eso: leyendas fiscales, cadenas de sellos, condiciones que aplican a otra orden. Es justo el terreno donde razonar más largo no ayuda.

Cuánto cuesta y qué hace falta antes de empezar

Las cuentas se pueden hacer con datos propios y conviene hacerlas antes de contratar nada. Un agente único que procese dos mil facturas al mes, consumiendo del orden de ocho mil tokens entre lo que lee y lo que escribe por factura, mueve unos dieciséis millones de tokens mensuales. A los precios públicos de los modelos de gama media eso son decenas de dólares al mes, no miles.

El mismo proceso repartido entre cinco agentes con un coordinador no consume cinco veces eso: consume más, porque cada agente necesita recibir el contexto de lo que hicieron los otros. Cuánto más depende por completo de cuánto contexto se reenvíe en cada llamada, y es un número que hay que medir en el propio proceso antes de escalarlo. Ese es el punto: el sobrecosto de coordinación no se estima, se mide.

Lo que hace falta tener antes de empezar no es tecnología: es el catálogo de proveedores limpio, las órdenes de compra en un sistema al que se pueda consultar, y una definición escrita de qué se considera una excepción. Sin eso, el agente hereda el desorden y lo procesa más rápido.

Cómo saber si funcionó

Tres números, medidos antes y después, y ninguno de ellos es la cantidad de agentes.

El porcentaje de facturas que se concilian sin que las toque una persona. Si con un agente estaba en setenta y con cinco sigue en setenta y dos, el reparto no está pagando lo que cuesta.

El costo mensual en tokens dividido entre las facturas procesadas. Es la única forma de ver el sobrecosto de coordinación, porque el total absoluto crece también cuando crece el volumen.

Los días que tarda el cierre de cuentas por pagar. Es lo que se quería arreglar, y es lo que se olvida medir.

Brooks cerraba su argumento diciendo que el problema no era la gente sino la estructura del trabajo. Cincuenta años después, con agentes en lugar de programadores, la estructura del trabajo sigue mandando.