Hay una fantasía silenciosa detrás de muchas de nuestras conversaciones sobre inteligencia artificial: la idea de que, si podemos lanzar diez agentes al mismo tiempo, entonces nosotros también nos volvimos diez veces más productivos.

Un agente revisa código. Otro escribe tests. Otro resume un documento largo. Otro investiga alternativas. Otro arma el primer borrador de una propuesta. La pantalla se llena de procesos, ramas, diffs, reportes, recomendaciones. Todo parece moverse, y la sensación de movimiento se confunde con la sensación de avance.

Hasta que llega el momento de mirar.

Ahí aparece el límite incómodo: los agentes trabajan en paralelo, pero nuestra atención no.

Un solo core caro

Podemos delegar ejecución, exploración, búsqueda. Podemos pedir variantes, comparaciones, hipótesis, borradores. Podemos tener cinco asistentes trabajando mientras nos servimos un café. Pero cuando hay que decidir qué importa, qué se integra, qué se descarta, qué riesgo aceptamos y qué historia vamos a contar, volvemos a una condición bastante antigua: una sola conciencia al frente, obligada a ordenar lo que muchos procesos dejaron sobre la mesa.

En el mejor de los casos, funcionamos como un procesador heterogéneo: un core serial caro, rodeado de muchos workers baratos.

La computación aprendió esto hace décadas, y lo aprendió a los golpes. Los procesadores no se volvieron infinitamente rápidos agregando más núcleos. Gene Amdahl lo formalizó en 1967, en Validity of the Single Processor Approach to Achieving Large-Scale Computing Capabilities: la aceleración que conseguís paralelizando un trabajo está limitada por la fracción de ese trabajo que sigue siendo inevitablemente secuencial. Podés tirarle cien núcleos a un problema; la parte que tiene que pasar en orden fija el techo, y ese techo no se mueve por más cores que pongas a esperar. Algunas instrucciones corren al mismo tiempo. Otras comparten memoria, estado, locks, invariantes. Y cada vez que dos procesos quieren tocar la misma cosa, aparece una sección crítica: el tramo que el sistema atraviesa de a uno, sin importar cuántos núcleos haya ociosos del otro lado.

La computación, eso sí, encontró más tarde una salida parcial. Veinte años después de Amdahl, John Gustafson hizo una objeción famosa: en la práctica nadie paraleliza un problema de tamaño fijo para terminarlo antes; agarrás uno más grande y lo resolvés en el mismo tiempo. Si el trabajo crece junto con los núcleos, la fracción paralela pasa a dominar y el techo se corre hacia arriba. Donde Amdahl ve una tarea congelada, Gustafson ve una ambición que se expande. Pero el rescate tiene letra chica: vale mientras puedas inflar la parte paralela hasta que la serial quede en una nota al pie. El día que no podés agrandar lo paralelo, volvés a chocar contra el mismo techo.

Con la IA pasa algo muy parecido, salvo que el núcleo serial caro somos nosotros, y es el único que no podemos agrandar. Decidir, integrar, hacernos responsables no se vuelve más liviano porque abramos más agentes; cada agente nuevo, de hecho, le agrega material. El silicio le escapa a Amdahl creciendo hacia lo paralelo. A nosotros esa salida nos está vedada: lo que no escala somos nosotros mismos.

Usar muchos agentes no es el problema. Creer que eliminan la sección crítica humana, sí.

El impuesto de la orquestación

Esa sección crítica tiene nombres poco glamorosos: revisar, entender, integrar, priorizar, hacerse responsable. Es el lugar donde se paga lo que Addy Osmani llamó el impuesto de la orquestación en The Orchestration Tax (2026). Lanzar trabajo es barato; cerrar el loop es caro. Y la asimetría es brutal: la producción de los agentes escala con un par de teclas, pero la revisión escala con una sola persona. En la formulación de Osmani, correr muchos agentes no significa que de golpe haya más de vos.

Por eso algunos workflows con IA se sienten mágicos durante los primeros minutos y agotadores después de una hora. No porque los agentes hayan fallado, sino porque produjeron más superficie de decisión de la que una persona podía absorber. El cuello de botella dejó de estar donde lo veníamos buscando. Ya no era escribir el código, redactar el texto o encontrar la información. Ahora era sostener el modelo mental de todo eso junto.

Herbert Simon vio venir esto medio siglo antes de que hubiera un solo agente corriendo. En Designing Organizations for an Information-Rich World (1971), formuló su advertencia sobre la abundancia de información y la pobreza de atención. Lo decía pensando en el diluvio de datos que ya entonces empezaba a desbordar a las instituciones, pero la frase cae con una precisión incómoda sobre la pantalla llena de diffs. El problema no era solo producir información, sino tener atención disponible para consumirla. Y el copiloto fabrica abundancia —código, borradores, opciones, comparaciones— a un costo cercano a cero. Lo único que no fabrica es la atención para evaluar esa abundancia.

Topologías de atención

Si todo esto es cierto, entonces la pregunta con la que arrancamos estaba mal planteada. El límite relevante es cuántos outputs podés revisar sin perder el juicio.

La diferencia se siente en el cuerpo. Abrís cinco agentes antes del café y volvés con cinco diffs, dos propuestas y una rama que no terminás de entender por qué existe. Cada cosa, por separado, es razonable. Juntas, son más superficie de la que tu cabeza puede sostener sin empezar a aprobar cambios que en realidad no leíste. En mi experiencia, ese suele ser el punto donde la orquestación deja de ser una palanca y se vuelve una deuda: el impuesto que no pagaste con atención lo terminás pagando con revisiones superficiales, con código que entendés cada vez menos, con un “dale, aprobá” que no era una decisión sino una rendición.

Hay tareas que sí merecen el paralelismo. Generar tests, buscar referencias, comparar alternativas, explorar casos borde, transformar formatos, preparar primeros borradores: ahí la IA se parece a un pool de workers, trabajo abundante, barato y parcialmente verificable por la propia máquina. Esa es la parte donde conviene dejar que el silicio absorba lo rutinario y reservar tu atención para lo que todavía exige criterio.

Y hay tareas que conviene proteger en modo single-thread. Definir una arquitectura, entender un problema ambiguo, decidir una estrategia, resolver un conflicto entre dos principios que no pueden cumplirse a la vez, hacer un merge conceptual entre ideas que vienen de lugares distintos. Ahí más paralelismo no ayuda; a veces directamente estorba. Lanzar tres agentes a “diseñá la arquitectura” no te devuelve tres veces el diseño: te devuelve tres diseños que ahora alguien tiene que reconciliar, y ese alguien es el único núcleo que no podías escalar. El paralelismo, mal puesto, no multiplica el trabajo: lo amontona contra el cuello de botella.

La habilidad, entonces, se parece menos a configurar herramientas y más a algo viejo: saber cuándo abrir ramas y cuándo cerrar el mundo, cuándo pedir diez alternativas y cuándo mirar una sola cosa hasta entenderla, cuándo delegar la ejecución y cuándo no delegar el criterio. Diseñar, en una palabra, la topología de la propia atención antes de diseñar la de los agentes.

El único core que no podés clonar

La IA puede multiplicar la ejecución, la exploración, la cantidad de primeros intentos. Todavía no multiplica el lugar desde donde decimos esto sí, esto no, esto importa. Ese lugar sigue siendo single-thread.

Por eso la habilidad está en diseñar el embudo por el que pasan los procesos. Cada agente nuevo agrega movimiento, pero también agrega una deuda de atención. Y cuando esa deuda crece más rápido que nuestra capacidad de revisar, el sistema deja de amplificarnos: empieza a negociar, en silencio, la calidad de nuestro juicio.

Quizás administrar agentes sea, antes que nada, aprender a poner backpressure sobre uno mismo. En los sistemas, el backpressure es la señal con la que un consumidor lento le avisa al productor que afloje: no entregar más rápido de lo que alguien puede recibir. Trasladado a uno mismo, es una regla simple y difícil: no lanzar más trabajo del que vas a poder revisar en serio. Dejar que la máquina corra donde puede correr, y reservar el único core que no podemos clonar para aquello que todavía merece ser pensado en serie.

Lecturas recomendadas

  • Gene M. Amdahl. (1967). Validity of the Single Processor Approach to Achieving Large-Scale Computing Capabilities. AFIPS Conference Proceedings. [Formulación original de la ley de Amdahl.]
  • John L. Gustafson. (1988). Reevaluating Amdahl’s Law. Communications of the ACM, 31(5). [Contrapunto a Amdahl: si el problema escala con los procesadores, la fracción paralela crece y el techo se corre.]
  • Addy Osmani. (2026). The Orchestration Tax. [Ensayo sobre el costo oculto de coordinar múltiples agentes de IA.] https://addyosmani.com/blog/orchestration-tax/
  • Herbert A. Simon. (1971). Designing Organizations for an Information-Rich World. En M. Greenberger (ed.), Computers, Communications, and the Public Interest. Johns Hopkins Press. [Origen de la idea de que la abundancia de información genera escasez de atención.]