Agent OS es una etiqueta que aparece en cada vez mas conversaciones desde mediados de 2024. No describe un producto concreto sino una categoria en formacion: la capa que se sienta entre las aplicaciones agenticas y los modelos de lenguaje para encargarse de planificacion, gestion de contexto, memoria persistente, tolerancia a fallos y aislamiento. En octubre de 2025 ya hay tres o cuatro proyectos que reclaman esa etiqueta con fundamento, varios productos que la intentan y una base de investigacion que empieza a formalizar el concepto. Toca revisar que hay de real detras del termino.
De donde viene el termino
El articulo AIOS publicado por Kai Mei y un grupo de la Rutgers University en marzo de 2024 acunia la expresion con propiedad. La tesis del articulo es que los agentes autonomos basados en modelos de lenguaje tienen los mismos problemas clasicos que un sistema operativo tuvo que resolver con los procesos: competencia por recursos, planificacion de tareas, aislamiento entre contextos, gestion de memoria, control de acceso. La propuesta no es una analogia vaga sino un disenio concreto con modulos separados para cada una de esas funciones.
Lo interesante del articulo no es el codigo, que es mas academico que productivo, sino la ontologia. Antes de AIOS, cuando alguien hablaba de una plataforma de agentes pensaba en un entorno como LangChain: librerias para orquestar llamadas a modelos, herramientas, memoria corta y poco mas. Despues de AIOS, la conversacion separa claramente el entorno de aplicacion del que podriamos llamar kernel agentic, la parte que no escribes para cada agente sino que es compartida.
Esa separacion es util porque el entorno de aplicacion cambia muy rapido y el kernel deberia cambiar despacio. Si tu gestion de memoria y tu planificador viven dentro de la misma libreria que tus herramientas especificas, cada cambio en las herramientas arrastra el riesgo de tocar la capa fundamental. Si estan separados, puedes evolucionar la aplicacion sin tocar el kernel.
Que piezas componen un Agent OS
Los proyectos que hoy reclaman la etiqueta coinciden en cuatro piezas con distinto grado de madurez. La primera es el planificador de solicitudes: cuando varios agentes comparten computo, 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 mas tokens.
La segunda es la gestion de contexto. Un agente largo puede generar conversaciones que exceden la ventana del modelo, y hay que decidir que se resume, que se descarta y que se guarda fuera. Los sistemas mas sofisticados mantienen un estado estructurado con secciones pinneadas, resumenes rotatorios y recuperacion bajo demanda desde un almacen vectorial.
La tercera es la memoria persistente. A diferencia del contexto, sobrevive a multiples ejecuciones y permite que un agente aprenda de interacciones pasadas. Implementarla bien es dificil porque hay que decidir que se recuerda, con que estructura, como se indexa y como se limpia cuando la informacion es obsoleta.
La cuarta es el aislamiento. Si varios agentes comparten un proceso, un fallo en uno no debe afectar a los demas; si un agente ejecuta herramientas que acceden al sistema o a la red, debe hacerlo en un entorno acotado. Aqui 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 en 2025 publica una version 0.2 donde el kernel se separa del SDK. La arquitectura nueva permite ejecutarlo como servicio remoto y que las aplicaciones se conecten por RPC, algo que se parece mas a un sistema operativo de verdad que la version inicial empaquetada como libreria.
MemGPT lleva desde 2023 formalizando la gestion de memoria a largo plazo con la metafora del paginador: el agente tiene una memoria principal limitada (el contexto) y una memoria secundaria ilimitada que es un almacen persistente al que se pagina bajo demanda. En 2025 el proyecto ha evolucionado hacia una plataforma completa llamada Letta.
OpenAI publico Swarm a finales de 2024 como marco experimental para orquestar agentes con especializaciones distintas. Aunque se presento como libreria, el modelo de transferencia de control y el patron de handoff son primitivas de sistema: decidir quien ejecuta, con que contexto y cuando ceder. En el lado abierto, Dify, LangGraph y CrewAI han ido absorbiendo ideas de Agent OS manteniendo su identidad como marcos de aplicacion; LangGraph, en particular, ha desarrollado un modelo de estado persistente y checkpointing que se parece mucho a la pieza de memoria de un Agent OS. La linea entre libreria y kernel se esta volviendo borrosa.
Los problemas practicos sin resolver
Hay tres problemas que todos los proyectos reconocen y ninguno ha resuelto con claridad. El primero es el coste de las abstracciones. Cada capa que anades entre la aplicacion 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 almacen de memoria persistente puede anadir 500 milisegundos sin aportar valor visible. Los proyectos que ignoran este coste terminan como demos bonitas que nadie usa en produccion.
El segundo es la evaluacion. Comparar un Agent OS con otro es dificil porque no hay benchmarks estandar y los que existen miden cosas dispares: tasa de finalizacion de tareas, coste por tarea, fidelidad a instrucciones, robustez ante fallos de herramientas. Un proyecto puede ser excelente en uno y mediocre en otro, y la eleccion depende mucho del caso de uso. Esta falta de benchmarks comparables es lo que mas frena la consolidacion del concepto.
El tercero es la gobernanza. Un Agent OS decide cosas importantes: que agente accede a que recurso, cuanta computacion consume, a que datos llega. Esas decisiones tienen implicaciones de seguridad, privacidad y cumplimiento, y hoy se tratan de forma ad hoc en cada proyecto. Hasta que no exista un modelo claro de politicas, auditabilidad y trazabilidad, Agent OS seguira siendo un concepto mas aplicable en investigacion que en entornos con exigencias regulatorias.
Que deberia buscar alguien que construye hoy
Para un equipo que empieza a construir aplicaciones agenticas serias en otono de 2025, la pregunta no es si necesita un Agent OS sino cuales de sus piezas necesita. Pocos casos necesitan los cuatro componentes desde el dia uno. La mayoria empieza con gestion de contexto decente, anade memoria persistente cuando la sesion unica deja de ser suficiente, incorpora planificacion cuando empieza a ejecutar en paralelo, y considera aislamiento solo cuando el modelo de amenaza lo justifica.
Este enfoque incremental es mas sano que adoptar un Agent OS completo desde el inicio. Los proyectos que han adoptado frameworks muy completos desde el primer dia suelen acabar luchando con abstracciones que no entienden para problemas que todavia no tienen. Al reves, los equipos que construyen cada pieza segun la necesitan llegan a algo parecido a un Agent OS por acumulacion, y lo entienden.
Esta es tambien la trayectoria historica de los sistemas operativos reales. Ningun equipo disenia un sistema operativo desde cero para ejecutar una aplicacion; lo que se hace es usar el que hay o construir las piezas minimas que hacen falta. El concepto de Agent OS se hara util cuando las piezas esten suficientemente estabilizadas como para tomarse prestadas sin fricciones, y ese momento todavia no ha llegado del todo.
Cómo pensar la decisión
Me parece util pensar en Agent OS como una lente analitica mas que como un producto a elegir. La lente ayuda a organizar las preguntas correctas: donde esta la planificacion, donde esta la memoria, que aislamiento necesito, como gestiono el contexto. Responder esas preguntas con honestidad te da una arquitectura clara, aunque la implementes con piezas de distintos proyectos.
Para equipos grandes con varios productos agenticos, adoptar un Agent OS compartido puede amortizar esfuerzo: la memoria persistente, la autenticacion de herramientas o el planificador merecen centralizarse. Para un solo producto, mejor empezar con piezas pequenias y resistir la tentacion de importar un marco entero. Mi intuicion es que en 2026 habra dos o tres proyectos maduros como para adoptarlos sin sufrir; mientras tanto conviene tratar el concepto como vocabulario de disenio, no como compromiso de plataforma.
