Cada sistema operativo que hemos usado —desde MS-DOS hasta iOS— se diseñó pensando en el mismo tipo de usuario: una persona con ojos, dedos, y la paciencia para navegar menús. ¿Qué pasaría si ese ya no fuera el usuario principal?
Qué hace un sistema operativo tradicional
Un sistema operativo, en el fondo, resuelve un puñado de problemas muy concretos:
- Administra recursos — CPU, memoria, almacenamiento
- Administra procesos — qué se ejecuta, en qué orden, con qué prioridad
- Ejecuta aplicaciones — el software que realmente usa la persona
- Organiza archivos — dónde vive la información y cómo se accede a ella
- Controla permisos — quién puede hacer qué
- Media la interacción con hardware — pantalla, teclado, red, sensores
Todo esto se diseñó, capa por capa, alrededor de un supuesto: al final de la cadena hay una persona mirando una pantalla y decidiendo qué hacer a continuación.
¿Y si el usuario principal ya no fuera solamente humano?
Esa es la pregunta detrás del concepto de Agentic OS (sistema operativo agéntico): ¿qué necesitaría un sistema operativo si los principales usuarios ya no fueran solamente humanos, sino agentes de IA?
Un agente no necesita una pantalla. No necesita botones ni menús. Pero sí necesita otras cosas que los sistemas operativos actuales no fueron diseñados para dar por defecto: una identidad verificable, memoria persistente entre tareas, permisos granulares sobre qué puede tocar, y la capacidad de coordinarse con otros agentes sin que un humano esté mediando cada intercambio.
Una arquitectura conceptual para agentes
Si tuviéramos que diseñar, desde cero, un sistema pensado para que agentes de IA fueran los usuarios principales, tendría que resolver piezas como estas:
- Agentes — la unidad activa del sistema, en vez de "aplicaciones" pasivas esperando un clic
- Memoria — persistente, no solo mientras dura una sesión
- Herramientas — capacidades concretas que un agente puede invocar
- Permisos — qué puede hacer cada agente, y sobre qué recursos exactamente
- Identidad — cómo se sabe qué agente hizo qué, y en nombre de quién actúa
- Tareas — unidades de trabajo con objetivo, no comandos sueltos
- Procesos — cómo se ejecutan esas tareas, se pausan, se retoman, se cancelan
- Comunicación entre agentes — cómo un agente le pasa trabajo o contexto a otro
- Supervisión — cómo un humano observa, interviene o aprueba lo que hacen los agentes
- Ejecución 24/7 — procesos que corren de forma continua, no solo cuando alguien abre una app
Sistema operativo tradicional vs. Agentic OS
Sistema operativo tradicional → aplicaciones → usuario humano decide y actúa Agentic OS → agentes → herramientas y sistemas (ERP, CRM, bases de datos, APIs...) → humanos supervisando, no operando cada clic
En el modelo tradicional, el humano es el motor: abre la aplicación, hace clic, espera el resultado, decide el siguiente paso. En un Agentic OS, el agente es el motor de la ejecución, y el humano se mueve hacia un rol de supervisión: define el objetivo, revisa resultados, interviene cuando algo se sale de lo esperado.
Un concepto todavía en construcción
Vale la pena decirlo con claridad: el Agentic OS no es un producto que exista hoy de forma consolidada, ni un estándar que todos estén implementando igual. Es un concepto emergente, del que distintos equipos e investigadores están explorando piezas distintas —algunos desde la memoria, otros desde la orquestación multiagente, otros desde el sandboxing— sin que exista todavía un consenso sobre cómo se ve la versión final.
Es más útil pensarlo como una dirección hacia la que varias piezas de la industria están apuntando, que como un producto que se pueda comprar o instalar.
Cómo se conecta esto con una empresa real
Llevado a una empresa, un Agentic OS no significa "reemplazar Windows". Significa tener una capa que coordina múltiples agentes trabajando simultáneamente sobre el ERP, el CRM, el correo, los documentos, las bases de datos y los sistemas legacy de esa empresa —cada uno con su propia identidad, sus propios permisos, y su propia tarea asignada, todos supervisados por las mismas personas que hoy operan esos sistemas manualmente.
No es un agente aislado haciendo una tarea. Es una infraestructura donde varios agentes pueden operar a la vez, de forma coordinada, sin pisarse entre sí ni sin que un humano tenga que microgestionar cada uno.
Qué podría significar para los desarrolladores
Si esta dirección se consolida, el trabajo de desarrollo empieza a parecerse menos a "construir una aplicación con una interfaz" y más a "diseñar el sistema de permisos, memoria y coordinación en el que varios agentes van a operar". Las preguntas cambian: no es solo qué botones necesita el usuario, sino qué puede hacer un agente sin supervisión, qué necesita aprobación, y cómo se audita después lo que hizo.
Es un desplazamiento parecido al que vivió la industria cuando pasamos de programas de escritorio a servicios en la nube: cambia el tipo de problema que hay que resolver, no solo la herramienta que se usa para resolverlo.
Aplicación de agentes vs. verdadero Agentic OS
Conviene no confundir dos cosas. Tener un chatbot o un agente que automatiza una tarea puntual —contestar correos, generar reportes— es una aplicación de agentes: útil, real, pero acotada a una función.
Un Agentic OS es algo de otro orden: una infraestructura donde muchos agentes, con identidad y permisos propios, pueden operar de forma continua sobre múltiples sistemas, coordinarse entre sí, y ser supervisados como conjunto —no uno por uno. La diferencia es la misma que hay entre tener una app en tu celular y tener el sistema operativo que hace posible que existan miles de apps distintas al mismo tiempo.
Paso a paso para empezar a moverte hacia esta dirección, con Claude
No hace falta esperar a que exista un "Agentic OS" formal. Ya se pueden coordinar varios agentes de Claude hoy:
- Dale identidad a cada agente — nombra cada sesión de Claude Code con claridad (por ejemplo, una sesión para "landing-methodology" y otra para "recursos-del-blog"), para saber siempre quién hizo qué.
- Usa subagentes para tareas paralelas — el Agent tool de Claude Code puede lanzar subagentes especializados (de exploración, de planeación, de revisión de código) sin saturar el contexto de la conversación principal.
- Coordina sesiones distintas entre sí — con mensajería entre sesiones (
SendMessage/ListAgents), una sesión de Claude puede pedirle trabajo a otra. Así se generó, de hecho, parte del contenido de este mismo blog: una sesión de metodología le pidió a otra que redactara un artículo. - Da permisos por sesión, no un permiso compartido — cada sesión de Claude Code tiene su propia configuración de qué puede y no puede tocar.
- Deja tareas corriendo en segundo plano mientras trabajas en otra cosa, y recibe una notificación cuando terminen en vez de vigilarlas en tiempo real.
- Supervisa el conjunto, no sesión por sesión — revisa reportes y notificaciones, no cada acción individual.
- Empieza con dos sesiones coordinadas antes de pensar en escalar a diez o veinte.