Los agentes están reinventando el sistema operativo

Hace poco abrí el código de Symphony, el orquestador de agentes de programación que OpenAI liberó en 2026. Es un servicio en Elixir que lee un tablero de issues, levanta un agente por cada ticket elegible y lo deja trabajar en su propio directorio hasta que el ticket llega a revisión humana. Fui directo al schema de configuración y me encontré con esto:

field(:max_concurrent_agents, :integer, default: 10)
field(:max_turns, :integer, default: 20)
field(:max_retry_backoff_ms, :integer, default: 300_000)
field(:max_concurrent_agents_by_state, :map, default: %{})

Un límite global de concurrencia, un límite por cola, una cantidad máxima de turnos antes de ceder el lugar y un backoff exponencial para los trabajos que fallan. Unas líneas más abajo aparecen el intervalo de polling (30 segundos por defecto), un timeout de stall que mata al worker que deja de dar señales de vida y una lista de hosts SSH con su propio tope de agentes por máquina.

Si le quitas los nombres, eso es la configuración de un planificador de procesos. El propio SPEC.md se define así: “Symphony is a scheduler/runner and tracker reader”.

No es una casualidad de Symphony. Cada vez que alguien intenta poner a trabajar muchos agentes a la vez, termina construyendo las mismas piezas que los sistemas operativos construyeron a lo largo de sesenta años, por las mismas razones, aunque no en el mismo orden. Este post recorre esa historia era por era, marca dónde la analogía todavía no se sostiene y cierra con predicciones concretas.

La tesis: hoy se parece, mañana es una copia

Hay dos formas de leer el parecido. La primera es tomarlo como metáfora: “los agentes son como procesos”, una frase útil para explicar la idea en una charla y poco más. La segunda es tomarlo como una convergencia de ingeniería: cuando tienes un recurso caro y compartido, muchos trabajos que compiten por él y trabajos que fallan o se portan mal, las soluciones posibles son pocas, y la informática ya las encontró.

Mi lectura es que hoy estamos en un punto intermedio: los mecanismos se parecen (hay scheduler, aislamiento, paginación de memoria, supervisión), pero todavía hay diferencias de fondo que impiden hablar de una copia. Más abajo explico por qué creo que esa distancia se va a cerrar.

La idea de mirar los LLM con ojos de sistema operativo no es nueva. Andrej Karpathy popularizó a fines de 2023 la imagen del “LLM OS”, un sistema operativo construido alrededor del modelo. MemGPT (Packer et al., 2023) tomó la memoria virtual como modelo para gestionar el contexto, y AIOS (Mei et al., 2024) propuso un sistema operativo para agentes con su propio planificador y gestor de contexto. Este post no propone un sistema nuevo: mira los orquestadores que ya están en producción y sigue la historia de los SO era por era para ver qué mecanismos reaparecen. Uso Symphony como caso principal porque su especificación es pública y dice con precisión qué hace; cuando otros sistemas muestran lo mismo, los menciono.

Al poner las dos historias una encima de la otra aparece otra diferencia: la velocidad. Los SO recorrieron sus etapas una tras otra, a lo largo de sesenta años. Los sistemas de agentes las están recorriendo en pocos años y sin respetar el orden: la paginación de contexto se generalizó antes que los agentes en paralelo, y la interfaz estándar hacia herramientas llegó antes que las capabilities.

Era 1: escasez y batch

En los primeros años de la computación comercial, la máquina era carísima y hacía una sola cosa a la vez. Un programador entregaba su trabajo en tarjetas perforadas, un operador humano lo cargaba, la máquina lo ejecutaba de principio a fin y el resultado volvía impreso horas después. Los primeros monitores residentes automatizaron la transición entre un trabajo y el siguiente, pero la lógica seguía siendo la misma: un trabajo, toda la máquina, y esperar.

La primera etapa de los LLM se vivió de forma parecida, al menos del lado del usuario. Escribías un prompt, lo mandabas, esperabas la respuesta completa y, si el resultado servía de insumo para el siguiente paso, lo copiabas a mano en el prompt siguiente. El operador eras tú. La memoria de trabajo era una ventana de contexto de 4K u 8K tokens, tan escasa como la memoria de núcleo magnético de un IBM 7094: cada token que metías desplazaba a otro.

La economía, en cambio, era la inversa. En los años cincuenta, la máquina era tan cara que tenerla ociosa mientras un humano cargaba el siguiente trabajo era un desperdicio inaceptable. Con los primeros LLM, el modelo no esperaba a nadie: el proveedor lo repartía entre millones de usuarios. Lo que se desperdiciaba era el tiempo de la persona, que hacía de operador copiando resultados de un prompt al siguiente. El patrón de trabajo era el del batch; el recurso que se perdía, otro.

Era 2: multiprogramación y time-sharing

En 1959, Christopher Strachey propuso que un computador grande podía atender a varios usuarios a la vez si repartía su tiempo entre ellos. En 1961, el equipo de Fernando Corbató en el MIT hizo funcionar CTSS, uno de los primeros sistemas de tiempo compartido, y lo publicó en 1962. La idea central era simple: mientras un programa espera (a un disco, a una cinta, a una persona), la CPU puede avanzar con otro. Para que eso no degenere, cada programa recibe un quantum de tiempo y, al agotarlo, vuelve a la cola. En 1968, Dijkstra publicó la estructura del sistema THE y, con ella, los semáforos para coordinar procesos que comparten recursos, un problema que vuelve a aparecer en la Era 5.

Ahora vuelve a mirar Symphony. El SPEC describe el ciclo de cada tick así: reconciliar los trabajos en curso, validar la configuración, traer los issues candidatos, ordenarlos por prioridad y despachar mientras queden slots. La cantidad de slots se calcula como max(max_concurrent_agents - running_count, 0).

La palabra “agente” esconde dos cosas distintas, y separarlas ordena toda la analogía. La CPU es el modelo: no guarda nada entre una llamada y la siguiente, lo comparten miles de clientes y su capacidad se mide en tokens por segundo. El agente es el proceso: tiene un programa (su prompt y sus herramientas), un estado propio (el historial y el plan) y un ciclo de vida, y se turna para usar el modelo. Cada llamada es una porción de tiempo de CPU. El ticket se parece a un job de UNIX: la unidad de trabajo que el sistema admite y a la que le asigna un proceso.

La parte que más me llamó la atención es max_turns. Un worker puede ejecutar como máximo 20 turnos del agente en una sesión. Cuando los agota, sale limpiamente y el orquestador programa una “continuación” un segundo después: vuelve a verificar si el issue sigue activo y, si hay slot libre, lo despacha otra vez. Si no hay slot, queda en cola con el error no available orchestrator slots. El agente no decide cuándo ceder; el scheduler lo desaloja por cuota y lo vuelve a encolar, como en un round-robin. Con una diferencia: la unidad no es una porción de tiempo sino un turno completo del agente, que puede incluir muchas llamadas al modelo y a herramientas, y al volver a despacharse el worker arranca una sesión nueva sobre el mismo workspace.

La prioridad también está: los issues se ordenan por prioridad del 1 al 4, después por antigüedad y después por identificador. Y max_concurrent_agents_by_state permite limitar cuántos agentes trabajan en cada estado del tablero, que equivale a tener colas con límites propios.

Symphony no es el único caso. El sistema de investigación multiagente de Anthropic sigue el patrón de orquestador y trabajadores: un agente principal planifica y lanza subagentes que buscan en paralelo, cada uno con su propia ventana de contexto, y después combina sus resultados.

La idea de Strachey se cumple, aunque con un detalle curioso. Cuando un agente corre los tests o espera un build dentro de su turno, no está usando el modelo, pero sigue ocupando su slot, porque los slots se cuentan por worker en ejecución y no por uso del modelo. El modelo queda libre para otros clientes del proveedor; el límite de concurrencia del orquestador, no.

Era 3: memoria virtual y el working set

La memoria principal era el otro recurso escaso. En 1962, el equipo de Tom Kilburn en Manchester presentó el sistema de almacenamiento de un solo nivel del Atlas: el programa veía un espacio de direcciones grande y uniforme, y el hardware y el supervisor movían páginas entre la memoria de núcleo y el tambor magnético sin que el programador lo notara. Fue el nacimiento de la memoria virtual.

La memoria virtual trajo su propia patología. En 1968, Peter Denning formalizó el working set: el conjunto de páginas que un programa usa activamente en una ventana de tiempo. Ese mismo año explicó el thrashing: si el sistema no logra mantener el working set de cada proceso en memoria, los procesos pasan más tiempo trayendo páginas que ejecutando. En su survey de 1970 mostró por qué subir el grado de multiprogramación más allá de cierto punto hace que el throughput total se desplome.

Los LLM repitieron este capítulo, y conviene distinguir en qué capa:

• MemGPT (Packer et al., 2023) propuso tratar la ventana de contexto como memoria principal y un almacenamiento externo como disco, con el propio modelo decidiendo qué subir y qué bajar mediante llamadas a funciones. El título del paper es Towards LLMs as Operating Systems. Esta es la paginación en la capa del agente.
• PagedAttention (Kwon et al., SOSP 2023), la base de vLLM, tomó la paginación literal, pero dentro del servidor de inferencia: divide el KV cache en bloques de tamaño fijo que no necesitan estar contiguos, con una tabla que mapea bloques lógicos a físicos. Resolvió la fragmentación de memoria en inferencia y multiplicó el throughput por 2 a 4 respecto de los sistemas anteriores. Siguiendo la analogía, esta paginación ocurre dentro de la CPU, no en la memoria del proceso.
• Context rot (Chroma, 2025) midió en 18 modelos que el rendimiento se degrada de forma no uniforme a medida que crece el contexto, aunque la tarea no cambie. Aquí la analogía con Denning se invierte: el thrashing aparece cuando falta memoria para el working set, y el context rot aparece cuando en la ventana sobra contenido. Lo que se repite es la lección de fondo: rinde mejor un proceso que trabaja con lo que realmente necesita que uno que carga todo lo que tiene.

La compaction que hacen hoy los agentes de código (resumir la conversación cuando la ventana se llena y seguir con el resumen) es swapping con pérdida. Y la práctica de delegar una búsqueda a un subagente para que devuelva solo la conclusión es, en términos de Denning, una forma de proteger el working set del agente principal.

Era 4: protección y aislamiento

Cuando varios programas comparten una máquina, el siguiente problema es evitar que uno lea o rompa lo del otro. Multics (Corbató y Vyssotsky, 1965) puso la protección en el centro del diseño, con control de acceso por segmento y, más adelante, anillos de protección. En 1973, Butler Lampson describió el problema del confinamiento: cómo garantizar que un programa al que le prestas datos no los filtre por algún canal lateral. En 1974, Popek y Goldberg formalizaron qué necesita una arquitectura para ser virtualizable de forma segura, la base teórica de las máquinas virtuales que hoy se usan para aislar agentes de código. Y en 1975, Saltzer y Schroeder resumieron los principios de diseño que todavía se enseñan: mínimo privilegio, fail-safe defaults, mediación completa.

Symphony implementa la versión básica de todo esto. El SPEC exige que cada issue tenga un workspace propio y que los comandos del agente corran dentro de ese directorio, y deja la política de sandbox y de aprobaciones en manos de cada implementación. La implementación de referencia en Elixir usa por defecto workspace-write y rechaza los pedidos de escalar el sandbox. Hay hooks after_create y before_remove que funcionan como la creación y destrucción de un proceso: clonar el repo, instalar dependencias, limpiar al terminar. Y las credenciales del tracker viven en el host: el SPEC aclara que el proceso hijo del agente no necesita ver el secreto crudo.

En 1988, Norm Hardy publicó The Confused Deputy: un compilador con permiso para escribir un archivo de facturación fue engañado por un usuario para sobrescribirlo, porque el compilador no distinguía entre la autoridad que tenía por sí mismo y la que el usuario le estaba pidiendo usar. Hardy argumentó que ese tipo de error es la razón de ser de las capabilities: permisos que viajan con la solicitud en vez de pertenecer al programa.

La prompt injection indirecta (Greshake et al., 2023) es el confused deputy con otro nombre. Un agente con acceso a tu correo lee un mensaje que contiene instrucciones, y las ejecuta con tu autoridad. Simon Willison lo resumió como la lethal trifecta: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse hacia afuera. Con las tres juntas, el agente puede ser convertido en canal de exfiltración, una versión directa del problema de confinamiento de Lampson.

La respuesta más sólida hasta ahora llegó con CaMeL (Debenedetti et al., 2025), que separa el flujo de control del flujo de datos y adjunta capabilities a cada valor para decidir qué herramientas pueden recibirlo. Treinta y siete años después, la propuesta de Hardy reaparece aplicada a agentes, con un costo: en el benchmark AgentDojo, CaMeL resuelve menos tareas que un agente sin defensas a cambio de sus garantías.

Era 5: IPC, microkernels y la interfaz del sistema

Para que los procesos colaboren hace falta una forma de comunicarse. En 1970, Per Brinch Hansen describió el núcleo del RC 4000: un kernel mínimo que solo ofrecía creación de procesos y paso de mensajes, dejando las políticas de planificación y recursos a procesos padres que se podían reemplazar. Mach (Accetta et al., 1986) llevó el paso de mensajes a una base para UNIX, y Jochen Liedtke (1995) demostró que un microkernel podía ser rápido si se diseñaba con disciplina. La idea de que un núcleo pequeño gana a uno que lo resuelve todo reaparece en la predicción 5.

La separación de Brinch Hansen entre mecanismo y política aparece otra vez en Symphony: el servicio implementa el mecanismo (polling, slots, reintentos, workspaces) y la política vive en un WORKFLOW.md versionado dentro del repositorio, con el prompt del agente y los parámetros de ejecución.

Para la interfaz hacia afuera, el paralelo es el Model Context Protocol (Anthropic, 2024). MCP define cómo una aplicación expone herramientas y fuentes de datos a un modelo, independientemente de quién las implemente. Funciona como una mezcla de interfaz de syscalls y modelo de drivers: el agente no sabe cómo está hecho el acceso a GitHub o a la base de datos; sabe que hay una operación con un contrato. Los protocolos agente a agente, como A2A, ocupan el lugar del IPC entre procesos.

Hacia las herramientas, MCP ya funciona como estándar de hecho. Para la coordinación entre agentes todavía no hay un equivalente a POSIX. En los SO, pasar de las primeras versiones de UNIX a un estándar común llevó cerca de veinte años, con las guerras entre variantes de finales de los ochenta en el medio.

Cuando los procesos se comunican y comparten recursos, aparece también el riesgo de bloquearse entre ellos. En 1971, Coffman, Elphick y Shoshani describieron las cuatro condiciones necesarias para un deadlock: exclusión mutua, retener y esperar, no expropiación y espera circular. En los sistemas multiagente ya aparecen las cuatro: dos agentes que esperan cada uno la revisión del otro, o un agente que retiene un lock sobre una rama mientras espera un resultado que otro agente no puede producir sin esa rama. La receta clásica es romper alguna de las cuatro condiciones. Symphony rompe la espera circular por diseño, porque cada agente trabaja en su propio workspace y no espera a otros agentes; y si uno se queda sin avanzar, lo detiene el timeout de stall.

Era 6: fallos y supervisión

Cuando hay muchos procesos, algunos van a fallar. El estudio más completo hasta ahora sobre cómo fallan los sistemas multiagente es MAST (Cemri et al., 2025), que clasifica 14 modos de fallo en tres categorías: problemas de diseño del sistema, desalineación entre agentes y fallas de verificación. Varios de esos modos tienen nombre propio en la literatura de concurrencia: la pérdida de estado entre pasos se parece a un lost update, y las esperas que nunca se resuelven, a un livelock o a la starvation.

La respuesta de Symphony a los fallos es la parte más literal de toda la analogía, porque no la reinventó: la heredó. Está escrito en Elixir sobre la máquina virtual de Erlang. El supervisor raíz usa la estrategia one_for_one; debajo, un AgentRuntimeSupervisor con estrategia one_for_all agrupa al orquestador y al Task.Supervisor que lanza los workers. A los workers no los reinicia OTP: el orquestador los monitorea y, cuando uno cae, programa el reintento con backoff exponencial. Todo eso viene de la tesis de Joe Armstrong (2003), que formalizó cómo Ericsson construía sistemas de telecomunicaciones confiables a partir de componentes que fallan: procesos aislados, sin memoria compartida, supervisados por otros procesos cuya única tarea es reiniciarlos. La filosofía se resume en let it crash: no intentes que el proceso se defienda de todo; deja que falle rápido y que alguien de afuera lo recupere a un estado conocido.

Para agentes esa filosofía encaja muy bien. Más allá de cierto punto, un agente que se desvía no se corrige desde adentro con más prompt. Symphony le da margen, porque cada turno de continuación envía orientación al mismo hilo hasta llegar a max_turns; cuando eso no alcanza, el agente se mata, se limpia el workspace si hace falta y se reintenta con backoff. El stall_timeout_ms de Symphony (5 minutos por defecto) es un watchdog: si el agente no emite eventos durante ese tiempo, el orquestador termina el worker y encola un reintento.

Era 7: del SO al clúster

La última etapa de la historia de los SO que ya se está repitiendo es el salto de una máquina a muchas. Borg (Verma et al., 2015) describió cómo Google planificaba cientos de miles de trabajos sobre decenas de miles de máquinas, con cuotas, prioridades y expropiación. Kubernetes heredó de Borg y Omega su idea más duradera, que Burns et al. explicaron en 2016: el loop de reconciliación. En vez de ejecutar órdenes, el sistema compara continuamente el estado deseado con el estado observado y actúa para cerrar la diferencia.

Symphony usa la misma palabra y el mismo patrón, como muestra el diagrama del tick en la Era 2. En cada tick, antes de despachar nada, reconcilia: vuelve a consultar el estado de cada issue que tiene un agente corriendo y, si el ticket pasó a un estado terminal o dejó de ser elegible, detiene el worker. El estado deseado vive en el tablero de issues; el estado observado, en los agentes corriendo. Y con ssh_hosts y max_concurrent_agents_per_host, el orquestador ya reparte agentes entre varias máquinas. Funciona como un scheduler de clúster pequeño, todavía sin el empaquetado de trabajos en máquinas ni la expropiación de Borg.

El balance, era por era

Si pongo cada era frente a su equivalente y me pregunto qué tan cerca está de ser una copia, el resultado es este:

Era y mecanismo en común Sistemas operativos → agentes Estado

1. Batch Un trabajo a la vez, con un humano de operador
   Monitor residente ~1955 → Chat de un turno 2022
   Se parece
2. Multiprogramación Quantum, round-robin, colas con prioridad
   CTSS 1962 → Symphony 2026
   Se parece
3. Memoria virtual Paginación con tabla de bloques
   Atlas 1962 → PagedAttention 2023
   Idéntico
4. Working set Mantener cargado solo lo necesario
   Denning 1968 → Context rot 2025
   Se parece
5. Protección Capabilities, mínimo privilegio
   Multics 1965 · Hardy 1988 → CaMeL 2025
   Se parece
6. Interfaz hacia herramientas Syscalls y modelo de drivers
   UNIX 1974 → MCP 2024
   Idéntico
7. Estándar de coordinación Contrato común entre procesos
   POSIX 1988 → A2A 2025
   Todavía no
8. Supervisión Supervisores OTP, let it crash
   Erlang 1986 → Symphony 2026
   Heredado
9. Clúster Loop de reconciliación entre hosts
   Borg 2015 → Symphony 2026
   Se parece

Casi todas las filas quedan en “se parece”: el mecanismo está, pero con diferencias que todavía importan. De esas diferencias salen las predicciones del final.

Dónde todavía no se parece

El mapa tiene límites. Hay cuatro diferencias que hoy impiden hablar de copia.

La CPU no es determinista. Un proceso de UNIX ejecutado dos veces con la misma entrada hace lo mismo, porque el procesador ejecuta cada instrucción siempre igual. El modelo no: el mismo agente, con el mismo prompt, puede tomar otro camino. Paradójicamente, esto encaja con la filosofía de Armstrong en vez de romperla. Jim Gray observó en 1985 que la mayoría de los fallos en producción son transitorios, Heisenbugs que no se repiten al reintentar, y let it crash funciona justamente porque la segunda ejecución puede ir distinta. La diferencia es que, con agentes, esa variabilidad ya no está solo en el entorno: está en la propia CPU, y reintentar también significa tirar los dados otra vez.

El recurso escaso es otro. Los SO optimizaban ciclos de CPU y páginas de memoria. Los orquestadores de agentes optimizan tokens, dinero y, sobre todo, atención humana. Anthropic reportó que su sistema de investigación multiagente usa unas 15 veces más tokens que una conversación normal. Y el estado final de un run exitoso en Symphony muchas veces es Human Review, no Done: el trabajo termina en la cola de una persona.

El proceso puede ser convencido. Un proceso malicioso en un SO es código escrito por alguien con malas intenciones, o código legítimo al que un atacante le inyectó instrucciones aprovechando un error, como un buffer overflow. Un agente puede volverse hostil por leer un issue, un README o una página web, sin que nadie explote ningún error: en un LLM, los datos y las instrucciones viajan por el mismo canal por diseño. La prompt injection ocupa el lugar que tuvo la inyección de código, con la diferencia de que no hay un bug que corregir.

El programa está escrito en lenguaje natural. La “especificación” de un agente es un prompt, y el scheduler a veces también es un LLM que decide cómo repartir el trabajo. Eso vuelve borrosa la frontera entre kernel y aplicación que Dijkstra y Brinch Hansen trazaron con tanto cuidado.

Por qué creo que va a converger

Estas cuatro diferencias son reales, pero ninguna se está resolviendo con ideas nuevas. Se están resolviendo con mecanismos de SO:

• La falta de determinismo se contiene como se contenía el hardware poco confiable: con supervisión, checkpoints, idempotencia y verificación externa (tests, CI, revisión).
• El costo en tokens se administra como se administraba la CPU: con cuotas, límites de concurrencia y prioridades.
• La mezcla entre datos e instrucciones se ataca como Hardy propuso en 1988: separando autoridad de solicitud con capabilities, que es lo que hace CaMeL.
• La confusión entre kernel y aplicación se ordena separando mecanismo y política, que es lo que hace Symphony al dejar el scheduler en código y la política en WORKFLOW.md.

Cada vez que se cierra una brecha, la arquitectura de un sistema de agentes se parece un poco más a un SO, y la distancia se reduce en una sola dirección.

Predicciones

Estas son las predicciones que se derivan de la analogía. Les pongo fecha y un criterio para darlas por cumplidas.

1. Cuotas de tokens al estilo cgroups (antes de fines de 2027). Los orquestadores van a dejar de limitar solo la cantidad de agentes concurrentes y van a limitar presupuesto: tokens por tarea, por equipo y por prioridad, con expropiación de agentes de baja prioridad cuando se acaba la cuota. Los gateways de modelos ya ofrecen presupuestos por equipo o por clave; lo que falta es que el orquestador los use para decidir a quién pausar. max_concurrent_agents limita cuántos procesos corren a la vez; el paso siguiente en la historia fue limitar cuánto consume cada uno. La doy por cumplida si alguno de los orquestadores de agentes de código más usados permite fijar un presupuesto de tokens por tarea y pausa o expropia agentes de menor prioridad cuando se agota.

2. La degradación por exceso de contexto va a tener nombre y métrica (2027). Hoy hablamos de context rot como un fenómeno que se observa. Mi apuesta es que los frameworks van a exponer una métrica del tipo “tokens de contexto por avance útil” y un control de admisión que se niegue a meter más herramientas o más historial cuando esa métrica se degrada. Lo que se hereda de Denning no es el mecanismo, que aquí funciona al revés, sino la idea de medir cuánto de lo cargado se usa de verdad. La doy por cumplida si un framework o harness de agentes de uso amplio expone esa métrica y la usa para decidir qué cargar en el contexto.

3. Capabilities por defecto (2027-2028). Los permisos por agente (“este agente puede usar GitHub”) van a ceder ante permisos por tarea y por dato (“este valor, que vino de un issue externo, no puede llegar a una herramienta que escribe hacia afuera”). En los SO, las capabilities fueron la propuesta de la investigación que solo algunos sistemas adoptaron (KeyKOS, seL4, Capsicum, Fuchsia), mientras la mayoría siguió con listas de control de acceso. Con agentes, el costo de no adoptarlas es mucho más visible, y CaMeL ya mostró que son viables, aunque con un costo en tareas resueltas. La doy por cumplida si al menos un framework de agentes de uso amplio trae por defecto permisos por dato o por tarea, no solo por herramienta.

4. Una pelea por el POSIX de los agentes (2027-2029). MCP ganó la primera ronda como interfaz hacia herramientas. La pelea que viene es por el estándar de coordinación entre agentes y por el formato del “contrato de trabajo” (lo que en Symphony es WORKFLOW.md). Va a haber variantes incompatibles, como las hubo entre System V y BSD, y el estándar que gane no va a ser el más completo. La doy por cumplida si antes de 2029 conviven al menos dos estándares incompatibles para coordinar agentes, cada uno respaldado por un proveedor grande.

5. Unix le gana a Multics otra vez (2028). Multics intentó resolverlo todo y UNIX ganó siendo pequeño y componible. Creo que los orquestadores que se impongan van a ser los que hacen poco y bien, como Symphony, que se define a sí mismo como scheduler y lector de tickets, por encima de las plataformas multiagente que intentan resolver planificación, memoria, evaluación y gobierno en un solo producto. La doy por cumplida si en 2028 los orquestadores más adoptados para agentes de código delegan memoria, evaluación y gobierno en herramientas externas en lugar de integrarlos.

6. La revisión humana va a tener su propio scheduler (2027). En los SO, cuando la CPU se volvió rápida, el cuello de botella pasó a ser el disco y los procesos empezaron a pasar la mayor parte del tiempo esperando I/O. Con agentes está pasando lo mismo: producir código es barato y revisarlo es lo caro, y ya se nota en los runs que terminan en Human Review. Espero que la siguiente ola de herramientas no sea de agentes más capaces, sino de planificación de la revisión humana: agrupar cambios, ordenarlos por riesgo, decidir qué no necesita revisión. Serían el equivalente a los schedulers de disco que reordenaban pedidos para minimizar el movimiento del cabezal. La doy por cumplida si en 2027 aparecen herramientas cuyo producto principal es ordenar, agrupar o filtrar la revisión humana del trabajo de agentes.

Cierre

Symphony muestra lo que se gana conociendo la historia: en vez de inventar un modelo de concurrencia, eligió una plataforma que ya traía casi cuarenta años de supervisión probada en telecomunicaciones. Esa decisión, más que cualquier prompt, es la que hace que el sistema sea operable. Quien construye un orquestador de agentes sin conocer esa historia va a redescubrir el thrashing, el confused deputy y los deadlocks en producción.

Si estás diseñando un sistema con varios agentes trabajando en paralelo, o intentando que el que ya tienes deje de fallar de formas raras, es el tipo de problema que me interesa. Puedes escribirme.

Referencias

Historia de los sistemas operativos

• Christopher Strachey, Time Sharing in Large Fast Computers, International Conference on Information Processing (UNESCO), 1959.
• F. J. Corbató, M. Merwin-Daggett, R. C. Daley, An Experimental Time-Sharing System, AFIPS Spring Joint Computer Conference, 1962.
• T. Kilburn, D. B. G. Edwards, M. J. Lanigan, F. H. Sumner, One-Level Storage System, IRE Transactions on Electronic Computers, 1962.
• F. J. Corbató, V. A. Vyssotsky, Introduction and Overview of the Multics System, AFIPS Fall Joint Computer Conference, 1965.
• Edsger W. Dijkstra, The Structure of the “THE”-Multiprogramming System, Communications of the ACM, 1968.
• Peter J. Denning, The Working Set Model for Program Behavior, Communications of the ACM, 1968.
• Peter J. Denning, Thrashing: Its Causes and Prevention, AFIPS Fall Joint Computer Conference, 1968.
• Peter J. Denning, Virtual Memory, ACM Computing Surveys, 1970.
• Per Brinch Hansen, The Nucleus of a Multiprogramming System, Communications of the ACM, 1970.
• E. G. Coffman, M. Elphick, A. Shoshani, System Deadlocks, ACM Computing Surveys, 1971.
• Butler W. Lampson, A Note on the Confinement Problem, Communications of the ACM, 1973.
• Dennis M. Ritchie, Ken Thompson, The UNIX Time-Sharing System, Communications of the ACM, 1974.
• Gerald J. Popek, Robert P. Goldberg, Formal Requirements for Virtualizable Third Generation Architectures, Communications of the ACM, 1974.
• Jerome H. Saltzer, Michael D. Schroeder, The Protection of Information in Computer Systems, Proceedings of the IEEE, 1975.
• Jim Gray, Why Do Computers Stop and What Can Be Done About It?, Tandem Technical Report 85.7, 1985.
• Mike Accetta et al., Mach: A New Kernel Foundation for UNIX Development, USENIX Summer Conference, 1986.
• Norm Hardy, The Confused Deputy (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review, 1988.
• Jochen Liedtke, On Micro-Kernel Construction, SOSP, 1995.
• Joe Armstrong, Making Reliable Distributed Systems in the Presence of Software Errors, tesis doctoral, KTH, 2003.
• Abhishek Verma et al., Large-Scale Cluster Management at Google with Borg, EuroSys, 2015.
• Brendan Burns, Brian Grant, David Oppenheimer, Eric Brewer, John Wilkes, Borg, Omega, and Kubernetes, Communications of the ACM, 2016.

LLMs y agentes

• Kai Greshake et al., Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, 2023.
• Charles Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023.
• Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP, 2023.
• Yingqiang Ge et al., LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem, 2023.
• Kai Mei et al., AIOS: LLM Agent Operating System, 2024.
• Mert Cemri et al., Why Do Multi-Agent LLM Systems Fail?, 2025.
• Edoardo Debenedetti et al., Defeating Prompt Injections by Design, 2025.

Fuentes no académicas

• OpenAI, Symphony: README y SPEC.md, 2026.
• Andrej Karpathy, Intro to Large Language Models, 2023.
• Anthropic, Introducing the Model Context Protocol, 2024.
• Anthropic, How we built our multi-agent research system, 2025.
• Kelly Hong, Anton Troynikov, Jeff Huber (Chroma), Context Rot: How Increasing Input Tokens Impacts LLM Performance, 2025.
• Simon Willison, The lethal trifecta for AI agents, 2025.