Qué es un sistema operativo de IA para una empresa: la capa sobre la que corren nuestros agentes

Un sistema operativo de IA, para una empresa, es la capa compartida sobre la que trabajan todos los agentes de IA y todas las personas del equipo: dónde vive el conocimiento, dónde se registra el trabajo, qué procedimientos siguen los agentes, qué puede tocar cada uno y qué tiene que aprobar una persona. En inglés también se le dice agent OS. Los agentes van y vienen. La capa es lo que se queda.

Según datos de Google Ads, las búsquedas de “ai operating system” crecieron 876% en un año, y hoy los primeros resultados son sobre todo glosarios e hilos de foros. Aquí va el significado para un negocio, desde cómo operamos Bamboo Tech Studio.

El nuestro es un vault de Obsidian versionado con git, más las reglas que lo rodean. A octubre de 2026 suma más de 660 commits desde el 13 de junio de 2026, 29 skills, 14 decisiones registradas, un registro de tareas que ya pasó el número 553 y una memoria de agente con 81 notas. Sobre él trabajan un asistente de programación en nuestras laptops, agentes de monitoreo y cumplimiento en servidores, agentes de chat para el equipo, y dos personas.

Un sistema operativo de IA es la capa que está debajo de los agentes

El primer impulso es armar un agente con un prompt largo. Funciona hasta que llega el segundo: los dos necesitan el mismo contexto, los dos crean tareas, los dos pueden romper cosas y nadie recuerda qué reglas recibió cada uno.

El sistema operativo de una computadora resuelve eso para los programas: archivos compartidos, permisos, procesos, registros. Un sistema operativo de IA lo hace para los agentes. Cada agente queda pequeño y reemplazable; la memoria, las reglas y los controles son de la empresa.

Las siete piezas de un agent OS, y qué se rompe sin cada una

1. Memoria compartida

Un wiki que los agentes leen y mantienen: clientes, proyectos, servidores, decisiones, lecciones. La organización del nuestro la contamos en LLM Wiki en producción, y los tipos de memoria en memoria de agentes de IA en la práctica. Aquí va solo el punto de gobernanza: está bajo git. Cada cambio tiene autor, fecha y diff.

Sin ella: cada sesión arranca de cero y cada agente arma su propia versión privada de la verdad.

2. Una sola puerta de entrada para el trabajo

Toda tarea entra en un registro, con un enlace a la nota que la documenta, en la misma edición. La lista de tareas de una sesión de chat sirve mientras la sesión corre, pero solo esa sesión la ve y termina con ella. El registro es lo que queda y lo que todos pueden leer.

Un detalle la sostiene: para cerrar una tarea hay que escribir lo que pasó, incluido “se cerró sin hacerse, porque X”, que es lo que evita reabrir la misma tarea tres meses después.

Sin ella: el trabajo muere con la sesión de chat, y la segunda persona no ve qué hacen los agentes.

3. Procedimientos estándar, escritos como skills

Una skill es un SKILL.md corto con propósito, entradas, pasos ordenados, resultados y trampas conocidas. Nuestra regla para escribir una: la tarea se hace más de dos veces, tiene pasos definidos y el “cómo” es fácil de hacer mal. Tenemos 29, para cosas como publicar un sitio, aprovisionar un servidor, responder a un WordPress hackeado o lanzar un agente con los secretos inyectados al arrancar. Viven en una carpeta plana, agrupadas por un campo domain:, porque los agentes las encuentran por nombre.

Sin ellas: cada sesión vuelve a deducir el procedimiento y el mismo error reaparece cada pocas semanas.

4. Permisos por agente

Cada agente recibe una identidad y una lista de lo que puede leer y escribir. Dos decisiones de diseño pesan más que la lista:

• La identidad la pone quien lanza al agente, nunca el agente. No puede hacerse pasar por otro porque no elige su propio nombre.
• La tabla de permisos es un archivo en git. Primero se aplica lo denegado, después la escritura y después la lectura, y todo lo que no aparece se rechaza. Una carpeta nueva no amplía el alcance de nadie por accidente, y “quién podía leer esto en agosto” se responde con git log.

En la tabla, nuestro agente de monitoreo de infraestructura puede leer las notas de infraestructura y escribir en un solo archivo, su bitácora de incidentes. Un agente de soporte cuyo espacio tiene datos de clientes puede leer una carpeta y no escribir nada. Las carpetas privadas están negadas a todos los agentes, y además nunca llegan a los agentes en servidores: quedan fuera del control de versiones, así que las copias de solo lectura que leen esos agentes no las contienen. La forma más simple de limitar un agente a una carpeta no requiere código: lanzar el servidor de herramientas del vault con esa carpeta como raíz. Lo probamos: rechazó ../, rutas codificadas y enlaces simbólicos hacia afuera.

Sin ellos: cualquier agente con las herramientas del vault puede leerlo todo, incluido material que pertenece a otro cliente o a un socio.

5. Puntos de aprobación: los agentes agregan, las personas cierran

Nuestra regla: los agentes pueden crear tickets, seguimientos, borradores y propuestas. Cerrar, borrar, facturar y todo lo irreversible queda en manos de personas. El modo de fallo que evita: ante una pregunta de solo lectura, un agente puede cerrar un compromiso real, aun diciendo que no sabe si el trabajo está hecho.

Los agentes que corren en servidores tienen una puerta todavía más chica. Leen un espejo de solo lectura del vault, que se actualiza cada 10 minutos, y escriben agregando un archivo nuevo en su propia carpeta de propuestas. Un hook de git en el servidor lo hace cumplir: la llave SSH del agente define su identidad, y un push solo puede agregar archivos dentro de la carpeta de ese agente. Editar o borrar cualquier cosa, incluso una propuesta anterior suya, se rechaza. Lo probamos con escrituras fuera de su carpeta, ediciones, borrados, merges y una ruta indebida escondida en un segundo commit: todo se rechazó y el alta legítima pasó.

Un organizador archiva algunas propuestas solo, con reglas fijas y sin modelo: archivos nuevos, destino inexistente y prefijos de carpeta angostos definidos por agente. El resto espera a una persona.

Para todo trabajo destructivo, de personas o agentes, usamos cinco controles: capacidad probada para esa operación exacta, identificadores explícitos de lo que se va a tocar, un antes y después con su radio de impacto, aprobación del responsable dentro de un límite definido, y un plan de reversa más una forma de verificar el efecto. La aprobación para un sitio no es aprobación para toda la flota.

Sin ellos: el agente que encuentra el problema decide también el arreglo, y te enteras después.

6. Un monitoreo que trata el silencio como un hallazgo

Un escáner que solo manda un mensaje cuando encuentra algo tiene un punto ciego. Si deja de correr, por ejemplo porque una edición le quita el permiso de ejecución, se queda callado, y ese silencio se lee igual que una buena noticia. La edición que lo rompe puede ser incluso la que agrega controles nuevos, así que la detección nueva no corre ni una vez.

Nuestra regla para toda revisión periódica: cada ejecución completa deja una marca, un vigilante aparte avisa cuando esa marca envejece y llega un resumen positivo aunque no haya nada mal, para que el silencio nunca sea la única señal. Con los agentes, igual: “mensaje enviado” en su propia salida es el agente narrando. Revisamos el canal donde el mensaje debía aparecer.

Sin él: un monitor muerto y un sistema limpio se ven idénticos.

7. Reglas escritas a partir de modos de fallo de producción

Muchos fallos distintos en sistemas de IA en producción tienen la misma forma: algo falla y queda registrado como un estado normal, como “pendiente”, “enviado” o directamente nada. Tenemos un estándar contra eso con doce reglas. Algunas:

• El estado por defecto nunca es el optimista. Si no sabes qué pasó, el estado es “no se sabe”.
• Nada se confirma antes de que ocurra el efecto. Un agente no debe decirle a un cliente “ya avisamos al equipo” si el aviso no salió de verdad.
• Una regla que solo vive en el prompt no es una regla. Un modelo puede hacer igual lo que su prompt prohíbe, así que el control tiene que vivir fuera de él.
• Siempre un tope. Arregla la causa concreta y además limita cualquier bucle a N acciones por minuto, incluidos los que todavía no conoces.

Sin ellas: cada incidente se arregla una vez y su primo aparece el mes siguiente en otro agente.

Muchos agentes y muchas personas sobre la misma capa

Un sistema operativo de IA tiene más de un lector, así que necesita algunas reglas sobre quién escribe qué.

• Un esquema, varias familias de agentes. CLAUDE.md para Claude Code, un AGENTS.md más corto y neutral para Codex y otros, y una carpeta STANDARDS/ que manda cuando no coinciden. Cuando una regla cambia, cambia primero en el estándar.
• Conocimiento compartido, estado de trabajo por persona. Todos leen las notas de trabajo de todos; los agentes de cada persona escriben solo las suyas. El porqué está en el artículo sobre el LLM Wiki.
• Los secretos quedan fuera de la memoria. Nuestro estándar: las notas guardan una referencia al secreto, nunca su valor, y los agentes reciben los secretos al arrancar desde un gestor de secretos dedicado, con un proyecto separado por cada frontera de agente.
• Compartir hacia afuera tiene su propio control. Lo que intercambiamos con un socio externo se revisa antes de cada commit, y lo que decide si una nota sale es de quién es, no su tipo.

Un prompt no es un permiso: sandbox a nivel de sistema operativo

Los permisos sobre las herramientas del vault suben el piso, pero un agente con terminal igual puede leer archivos. Con los agentes cuya salida debe pasar por una persona, conviene revisar dos huecos antes de lanzar: un puente de chat puede pasarle su llave de publicación al entorno del agente, y un runtime de agente puede habilitar una terminal sin importar sus propias restricciones de herramientas.

Por eso, en esos agentes el control vive en el sistema operativo. El agente corre sin entorno heredado, con los directorios personales ocultos, un sistema de archivos de solo lectura y la red de salida bloqueada salvo una lista de destinos permitidos. La llave vive con un usuario de servicio aparte, y el agente llega a ella solo a través de unas pocas herramientas angostas por un socket local. Además corre en un harness que hace cumplir su propia lista de herramientas. En nuestro agente de CRM en WhatsApp, cada turno termina con una de dos herramientas, “di esto” o “no hay nada que decir”, porque un modelo que puede cerrar en prosa puede dejar su respuesta en un log que nadie lee. El artículo sobre agentes de WhatsApp explica esos modos de fallo en detalle.

Cómo encajan las piezas

Un día típico:

1. Un agente en un servidor detecta un problema y manda una alerta o deja una propuesta.
2. Una persona lee la propuesta. Si es real, entra una tarea al registro con enlace a una nota.
3. El arreglo sigue una skill. Si no existe y el trabajo se va a repetir, se escribe una.
4. Si hay algo destructivo de por medio, pasa los cinco controles.
5. Si la causa de fondo fue un fallo registrado como éxito, se revisa si al estándar de fallos le falta una regla y la memoria del agente suma una lección corta con su porqué.

Ninguno de estos pasos depende de un modelo o proveedor en particular.

Cómo empezar: la primera semana y el primer mes

Primera semana

1. Crea una carpeta de archivos Markdown y ponla bajo git ese mismo día.
2. Escribe un esquema corto que los agentes deban leer primero: mapa de carpetas, tipos de nota y dónde van las tareas.
3. Haz del registro de tareas la única puerta de entrada, con enlace a una nota en cada fila.
4. Escribe skills para las dos o tres cosas que ya repites.
5. Adopta una regla: los agentes agregan, las personas cierran.
6. Saca todos los secretos de las notas y de los prompts.

Primer mes

1. Dale a cada agente una identidad fijada por quien lo lanza y permisos con todo denegado por defecto, en un archivo bajo git.
2. Pon a los agentes de servidor detrás de un espejo de solo lectura y propuestas de solo agregar.
3. Agrega a cada monitor una marca de ejecución y una alerta cuando esa marca envejezca.
4. Escribe tu propio estándar de fallos a partir de los incidentes que ya tuviste.
5. Arranca un registro de decisiones con fecha y razones.
6. Deja que los agentes anoten lecciones de sus errores, cada una con su porqué y cómo aplicarla.

Lo que un agente de IA puede y no puede hacer en tu empresa se decide en esta capa.

Es el mismo sistema que usamos para construir y operar los agentes de IA y automatizaciones que entregamos a nuestros clientes. Si quieres ayuda para montar un sistema operativo de IA para tu equipo, hablemos.