Un sistema de IA no crece a lo ancho, crece hacia arriba

Más agentes, más flujos, más automatización. Durante un tiempo funciona. Después llega el punto en que más de todo ya no mejora nada.

Nuestro siguiente salto no vino de tener más. Vino de una capa por encima.

A lo ancho ya habíamos crecido#

La flota llevaba mucho tiempo funcionando antes de esta reforma. La dirigían orquestadores: tareas programadas, pipelines en TypeScript, modelos pequeños para el triaje que clasificaban correos y resumían informes. Una generación tuvo un director de orquesta que consultaba a un puñado de especialistas, cada uno con una única conexión a una herramienta. Nada de eso era provisional. Funcionaba barato, fiable y discreto, cada noche, y la mayor parte sigue funcionando hoy.

Esa forma de construir tenía un límite deliberado. Los trabajadores recibían texto y devolvían texto, que es justo lo correcto para clasificar, agrupar e informar. Las intervenciones reales, en cambio, cambiar código, medir algo, comprobar una afirmación, exigían una secuencia que anticipara cada paso. También lo construimos. Solo que un sistema con esa forma no sigue creciendo, únicamente se llena más. Cada capacidad nueva es otro flujo, y cada flujo es otro sitio que alguien tiene que actualizar cuando algo cambia.

Entonces la tecnología dio un salto#

Los agentes que dependen de un proyecto pueden hoy actuar por su cuenta: abrir un archivo y modificarlo, manejar un navegador, ejecutar una prueba y leer lo que imprime. Se conectan a servicios y fuentes de datos mediante MCP, un estándar abierto que permite que un programa se enchufe a herramientas externas, y empiezan cada tarea con un fragmento relevante de lo que el sistema recuerda. Todo eso ocurre dentro de Claude Code.

Un montaje pequeño aprovecha un salto así cambiando unos cuantos scripts. Un sistema con una flota en marcha lo aprovecha de otra manera: crece hacia arriba.

Dirigir se convirtió en encargar#

En cuanto los trabajadores podían actuar por su cuenta, planificarles cada movimiento desperdiciaba capacidad. Quien dicta el camino obtiene exactamente el camino que se le ocurrió de antemano, nunca el mejor que el agente habría visto sobre el terreno. El orquestador planificaba una secuencia. El supervisor asigna un encargo. No es lo mismo.

Puestos uno junto al otro, la diferencia se ve con claridad:

El precio es más cuidado en un punto nuevo del proceso. Un encargo mal redactado es peor que una secuencia mal planificada, porque ya no hay nadie en medio que tape el hueco de pasada.

Qué contiene un encargo#

Un encargo no es una frase. Es un paquete, y lo que deba ser vinculante para la ejecución tiene que estar dentro.

Nombra el objetivo y, con la misma claridad, lo que queda fuera. El alcance es lo que está escrito, no lo que sería completo. Nombra las decisiones que ya están tomadas, para que el agente ni las vuelva a discutir ni las invente después. Nombra los archivos que le pertenecen, y en trabajo paralelo dos agentes nunca tienen los mismos, si hace falta cada uno en su propia copia. Nombra las herramientas permitidas, porque todo lo que no está permitido expresamente cuenta como prohibido, y eso pesa sobre todo en lo que cuesta dinero o sale hacia fuera.

Después viene la parte que decide, más tarde, si el encargo servía de algo. Los criterios de aceptación se escriben de forma que se puedan comprobar: está hecho cuando este comando muestra este resultado, no cuando parece correcto. Las comprobaciones exigidas aparecen por su nombre, junto con la obligación de citar su salida en el informe. Las condiciones de parada dicen cuándo el agente se detiene y pregunta en lugar de adivinar: faltan datos, hay contradicción con el alcance, una regla se interpone. Y al final están las prohibiciones, lo que no ocurre bajo ninguna circunstancia, por razonable que le parezca al agente en ese momento.

Lo que el cliente todavía no ha decidido se aclara antes del encargo. No lo adivina el agente a mitad de camino, y tampoco se le pasa hacia abajo con un "si encuentras motivos en contra, aborta". Esa regla salió de la práctica, no de un manual. Es la más incómoda de todas, porque obliga al supervisor a terminar de pensar antes de delegar.

Todo lo que deba regir viaja dentro del encargo#

Un agente subordinado no arranca con el conocimiento del proyecto en la cabeza. No conoce las normas de la casa que la sesión principal da por supuestas. Quien lo pasa por alto delega en alguien que ignora todas las convenciones vigentes, y luego se extraña del resultado.

Por eso separamos dos cosas: el contexto puede venir de la memoria del sistema, lo aprendido, el trabajo previo, las conexiones. Lo que deba regir está escrito en el encargo, o no rige. Resulta tedioso y la primera vez parece burocracia. También es la diferencia entre un equipo al que diriges y una sucesión de casualidades.

Se comprueba con evidencia, no con la autoevaluación#

Si algo está realmente terminado se comprueba con evidencia: el cambio real, las pruebas que se ejecutaron, las capturas que se revisaron. No el resumen del agente que lo construyó. Un informe que dice que todo está en verde es una afirmación sobre una comprobación, no la comprobación.

Por eso quien revisa recibe el encargo y el resultado, nada más. Sin autoevaluación del constructor, sin un "aquí decidí así a propósito". El elogio en la introducción crea justo la expectativa que un revisor no debería tener, y entonces ve lo que espera ver. Internamente lo llamamos revisión ciega.

Lo que sale de esa separación es poco espectacular y valioso precisamente por eso: el informe se lee, los cambios afirmados se miran, las comprobaciones se vuelven a ejecutar por cuenta propia. Solo entonces el resultado sigue su camino.

Cuando un proyecto despierta a otro#

La palanca de verdad está un nivel más arriba. Un supervisor no solo puede encargar trabajo dentro de su propia sesión: puede arrancar una sesión completa en otro proyecto, una que encuentra allí todo lo que pertenece a ese proyecto, sus reglas, sus protecciones, sus herramientas, su memoria.

Con eso cambia el reparto del trabajo. El supervisor ya no necesita conocer el otro proyecto en detalle. Escribe qué hay que hacer y qué rige, despierta a la sesión que vive allí y comprueba lo que vuelve. El conocimiento especializado se queda donde corresponde, y la dirección también.

Un encargo así lleva siempre las mismas prohibiciones: el cambio más pequeño posible, no publicar nada, no desplegar nada, las comprobaciones como prueba, un único resumen limpio del cambio, un informe como archivo en lugar de un aviso de viva voz. Lo que sale al mundo lo decide una persona, cada vez.

Cada proyecto dirige a su propio equipo#

Construir, revisar, redactar, investigar, proteger: son roles, no puestos atados a una persona o a un modelo, y cada proyecto toma de ese conjunto lo que realmente necesita. La ventaja aparece al cambiar algo. Un rol se afina en un sitio y mejora en todas partes, en vez de reinventarse en cada proyecto.

Por encima construimos una capa más, una que no construye nada, solo observa el sistema y lo mide: qué crece, qué se desvía, dónde una regla afirma algo que dejó de ser cierto. Tuvo que ganarse ese lugar. Por ahora solo observa e informa; más automatización llega paso a paso. Eso también es crecer hacia arriba y no a lo ancho.

Ningún director de orquesta sobre los directores#

Lo que deliberadamente no construimos es un enrutador central que reciba cada encargo de todos los proyectos y decida quién lo hace. Habría sido el remate evidente, y el punto en el que todo se viene abajo.

Cada proyecto conserva la autoridad sobre su trabajo. La capa de arriba observa, no reparte. Un proyecto que ya no decide qué pasa con sus encargos ha dejado de ser el responsable de ellos. Y una responsabilidad que no se puede señalar nunca fue un avance, solo una capa más.