Agent OS: el concepto que está moldeando la nueva capa

Actualizado: 2026-05-03

Agent OS es una etiqueta que aparece en cada vez más conversaciones desde mediados de 2024. No describe un producto concreto sino una categoría en formación: la capa que se sienta entre las aplicaciones agénticas y los modelos de lenguaje para encargarse de planificación, gestión de contexto, memoria persistente, tolerancia a fallos y aislamiento. Ya hay tres o cuatro proyectos que reclaman esa etiqueta con fundamento, varios productos que la intentan y una base de investigación que empieza a formalizar el concepto. Toca revisar qué hay de real detrás del término.

Puntos clave

• El paper AIOS (Rutgers, marzo 2024) acuña el concepto con rigor: los agentes autónomos tienen los mismos problemas que un SO tuvo que resolver con los procesos.
• Un Agent OS se compone de cuatro piezas con distinto grado de madurez: planificador de solicitudes, gestión de contexto, memoria persistente y aislamiento.
• Los proyectos existentes (AIOS 0.2, MemGPT/Letta, Swarm, LangGraph) abordan subconjuntos, no el stack completo.
• Tres problemas sin resolver frenan la consolidación: coste de abstracciones, falta de benchmarks comparables y ausencia de modelo de gobernanza.
• Para equipos que construyen hoy: adoptar las piezas según la necesidad, no el framework completo desde el día uno.

De dónde viene el término

El artículo AIOS publicado por Kai Mei y un grupo de la Rutgers University en marzo de 2024 acuña la expresión con propiedad. La tesis es que los agentes autónomos basados en modelos de lenguaje tienen los mismos problemas clásicos que un sistema operativo tuvo que resolver con los procesos:

• Competencia por recursos.
• Planificación de tareas.
• Aislamiento entre contextos.
• Gestión de memoria.
• Control de acceso.

La propuesta no es una analogía vaga sino un diseño concreto con módulos separados para cada una de esas funciones.

Lo interesante del artículo no es el código —más académico que productivo— sino la ontología. Antes de AIOS, cuando alguien hablaba de una plataforma de agentes pensaba en LangChain: bibliotecas para orquestar llamadas a modelos, herramientas y memoria corta. Después de AIOS, la conversación separa claramente el entorno de aplicación del que podríamos llamar kernel agéntico, la parte que no escribes para cada agente sino que es compartida.

Esa separación es útil porque el entorno de aplicación cambia muy rápido y el kernel debería cambiar despacio.

Qué piezas componen un Agent OS

Los proyectos que hoy reclaman la etiqueta coinciden en cuatro piezas:

1. Planificador de solicitudes. Cuando varios agentes comparten cómputo, hay que decidir el orden y la prioridad: desde FIFO simple hasta estrategias que favorecen a agentes con deudas de latencia o penalizan a los que consumen más tokens.
2. Gestión de contexto. Un agente largo puede generar conversaciones que exceden la ventana del modelo. Los sistemas más sofisticados mantienen un estado estructurado con secciones ancladas, resúmenes rotativos y recuperación bajo demanda desde un almacén vectorial.
3. Memoria persistente. A diferencia del contexto, sobrevive a múltiples ejecuciones y permite que un agente aprenda de interacciones pasadas. Implementarla bien es difícil: hay que decidir qué se recuerda, con qué estructura, cómo se indexa y cómo se limpia cuando la información es obsoleta.
4. Aislamiento. Si varios agentes comparten un proceso, un fallo en uno no debe afectar a los demás. Si un agente ejecuta herramientas que acceden al sistema o a la red, debe hacerlo en un entorno acotado. Aquí entran Firecracker, Kata Containers o gVisor: el aislamiento fuerte pide primitivas de sistema, no solo de lenguaje.

Los proyectos reales que hoy existen

El AIOS original sigue activo y publicó una versión 0.2 donde el kernel se separa del SDK. La arquitectura nueva permite ejecutarlo como servicio remoto con aplicaciones conectadas por RPC, algo que se parece más a un sistema operativo real que la versión inicial empaquetada como biblioteca.

MemGPT lleva desde 2023 formalizando la gestión de memoria a largo plazo con la metáfora del paginador: el agente tiene una memoria principal limitada (el contexto) y una memoria secundaria ilimitada que es un almacén persistente al que se pagina bajo demanda. El proyecto ha evolucionado hacia una plataforma completa llamada Letta.

OpenAI Swarm se presentó como marco experimental para orquestar agentes con especializaciones distintas. Aunque se presentó como biblioteca, el modelo de transferencia de control y el patrón de handoff son primitivas de sistema.

En el lado abierto, LangGraph ha desarrollado un modelo de estado persistente y checkpointing que se parece mucho a la pieza de memoria de un Agent OS. La línea entre biblioteca y kernel se está volviendo borrosa.

Los problemas prácticos sin resolver

Hay tres problemas que todos los proyectos reconocen y ninguno ha resuelto con claridad:

• Coste de abstracciones. Cada capa que añades entre la aplicación y el modelo es latencia y complejidad. Si tu agente hace tres llamadas al modelo por respuesta, pasar por un planificador, un gestor de contexto y un almacén de memoria persistente puede añadir 500 ms sin aportar valor visible.
• Evaluación. Comparar un Agent OS con otro es difícil porque no hay benchmarks estándar y los que existen miden cosas dispares: tasa de finalización de tareas, coste por tarea, fidelidad a instrucciones, robustez ante fallos de herramientas.
• Gobernanza. Un Agent OS decide cosas importantes: qué agente accede a qué recurso, cuánta computación consume, a qué datos llega. Esas decisiones tienen implicaciones de seguridad, privacidad y cumplimiento, y hoy se tratan de forma ad hoc.

Qué debería buscar alguien que construye hoy

Para un equipo que empieza a construir aplicaciones agénticas serias, la pregunta no es si necesita un Agent OS sino cuáles de sus piezas necesita. Pocos casos necesitan los cuatro componentes desde el día uno. La mayoría empieza así:

1. Gestión de contexto decente.
2. Añade memoria persistente cuando la sesión única deja de ser suficiente.
3. Incorpora planificación cuando empieza a ejecutar en paralelo.
4. Considera aislamiento solo cuando el modelo de amenaza lo justifica.

Este enfoque incremental es más sano que adoptar un Agent OS completo desde el inicio. Los proyectos que han adoptado frameworks muy completos desde el primer día suelen acabar luchando con abstracciones que no entienden para problemas que todavía no tienen.

Conclusión

Pensar en Agent OS como una lente analítica —más que como un producto a elegir— ayuda a organizar las preguntas correctas: dónde está la planificación, dónde está la memoria, qué aislamiento necesito, cómo gestiono el contexto. Para equipos grandes con varios productos agénticos, adoptar un Agent OS compartido puede amortizar esfuerzo; para un solo producto, mejor empezar con piezas pequeñas y resistir la tentación de importar un marco entero.