Le construí un sistema operativo a mi IA — con MySQL, PHP y bash
En el artículo anterior conté que una inteligencia artificial trabaja a diario dentro de mi framework. Lo que no conté es el problema que casi me hace desistir, ni la solución que ha acabado siendo, probablemente, la pieza de ingeniería de la que más orgulloso me voy a jubilar.
El problema es este: mi IA es brillante y amnésica. Cada mañana era como contratar al mejor ingeniero que he conocido... recién aterrizado de otro planeta. No recordaba qué hicimos ayer, ni dónde están las cosas, ni cómo se hace cada tarea en esta casa, ni — lo más peligroso — qué es lo que no se debe tocar. Todo lo que yo le explicaba por la mañana se evaporaba por la noche. Y un ingeniero genial sin memoria no es un ingeniero: es un riesgo con teclado.
Los que llevan poco en esto lo intentan arreglar con ficheros de notas cada vez más largos que la IA relee cada mañana. Yo también empecé así. No escala: las notas crecen, se contradicen, envejecen, y nadie las poda. Conozco esa enfermedad desde hace cuarenta años — se llama documentación — y sé cómo termina.
El recurso escaso no es la inteligencia
La observación que lo cambió todo es de ingeniería de sistemas, no de inteligencia artificial: el recurso escaso de un agente no es la inteligencia, es el contexto. Lo que le cabe en la cabeza en cada sesión. Su memoria de trabajo.
Y administrar un recurso escaso — decidir qué se carga, cuándo, quién puede tocar qué, qué se persiste y qué se descarta — tiene un nombre desde los años sesenta: sistema operativo. Un modelo de lenguaje sin sistema alrededor es una CPU magnífica sin ordenador: capaz de todo y responsable de nada.
Así que hice lo que un viejo programador sabe hacer: dejar de buscar el framework de moda que lo resolviera y construirle el ordenador. Con las herramientas de siempre: una base de datos MySQL, PHP y bash. Nada de vectores, ni embeddings, ni memoria semántica mágica. Una base de datos de toda la vida, con esquema escrito en SQL, y un CLI.
El grafo
El corazón es lo que llamo el grafo operativo: una base de datos donde vive todo el conocimiento operativo del negocio, en cinco tipos de nodo. Los cuento porque el reparto es la mitad del diseño:
- Trabajo — algo que hacer. Tiene ciclo de vida (pendiente → abierto → bloqueado → cerrado) y una bitácora de líneas fechadas: el encargo, las acciones, las decisiones con su porqué, y un resultado verificable obligatorio al cerrar. - Recurso — algo que existe: un servidor, una aplicación, una base de datos, un panel. Su ficha dice cómo llegar, cómo se usa y en qué estado está. - Procedimiento — cómo se hace una tarea repetible. El runbook: cuándo aplica, pasos, verificación, qué hacer si falla. - Persona — quién es quién: contacto, rol, qué opera. Porque la mitad de la operación de un negocio real es saber a quién escribir. - Regla — un criterio transversal: qué debe cumplir el resultado. Distinta del procedimiento (que son pasos). De estas hablaré más abajo, porque son el hallazgo.
Siete tipos de relación los conectan (usa, sigue, contiene, bloqueado_por...), con una matriz de coherencia que impide enlazar sinsentidos. Y una convención que me ha ahorrado meses de sobre-ingeniería: antes de inventar una relación nueva, una referencia en texto. La prosa envejece mejor que los esquemas.
Los mecanismos, subsistema a subsistema
La analogía del sistema operativo no es una metáfora de charla: cada subsistema clásico tiene su equivalente concreto.
El planificador. La cola de trabajos con prioridades. Un trabajo puede quedar bloqueado por otro — y cuando el bloqueante se cierra, el bloqueado se libera solo y vuelve a la cola. Las dependencias las gestiona el sistema, no la memoria de nadie.
La paginación. Un comando le monta a la IA el paquete de arranque de cualquier tarea en una sola llamada: el encargo, la última acción, los recursos con sus datos de acceso, los pasos del procedimiento y las reglas aplicables. Una página de contexto, no seis consultas. Y las salidas tienen modo resumen, porque cada token que el sistema no gasta en volcados es un token que la IA usa en pensar.
La protección de memoria. Un guardián se niega a dejar trabajar sin contexto: ningún agente toca código, servidores o datos sin un trabajo activo, sus recursos y procedimientos enlazados, y las reglas aplicables delante. Es el cinturón de seguridad contra el modo de fallo típico de un agente: actuar con seguridad aparente y contexto insuficiente.
Los permisos. Las credenciales viven en una bóveda cifrada. La IA las usa; no las ve. Y las acciones sensibles sobre producción exigen aprobación humana explícita, agrupada y nombrando el destino — no un "¿procedo?" genérico en mitad de la noche.
El recolector de basura. Una poda mensual: trabajos zombis, fichas incompletas, duplicados, referencias rotas. En su primera pasada, el recolector encontró un nodo duplicado que la propia IA había creado por error dos horas antes. Lo detectó, lo documentó y lo cerró citando la causa. Ese día supe que el diseño era correcto: el sistema se limpia a sí mismo y deja constancia.
El registro de auditoría. Todo trabajo cerrado deja su resultado escrito. La historia del negocio ya no está en mi cabeza ni en correos: está en una tabla, consultable, con fechas.
Y una ley no negociable que atraviesa todo: la primera acción de cualquier trabajo es escribir "arrancado". La aprendimos por las malas: un proceso autónomo murió una mañana sin dejar ni una línea, y estuvimos horas sin saber siquiera que había muerto. Su sucesor, con la bitácora obligatoria, dejó rastro de cada fase. En sistemas llevamos cincuenta años llamando a esto logging; en la inteligencia artificial de 2026 todavía es una idea exótica.
Las reglas: la constitución
El hallazgo tardío fue darnos cuenta de que faltaba un tipo de conocimiento: ni "qué hay", ni "cómo se hace", sino qué debe cumplirse. Los criterios. Las manías con motivo. Lo que un operador veterano sabe y el nuevo no: eso que en las empresas muere cuando se jubila el que lo sabía. Me toca de cerca el ejemplo.
Así que un día barrimos quinientos setenta y cuatro ficheros de documentación acumulados durante años — más las notas privadas que la propia IA había ido guardando — y cosechamos las reglas dispersas en todos ellos. Hoy son unas doscientas sesenta reglas individuales, agrupadas por tema, cada una con su fuente y — esto es lo importante — con su verificación. La consigna de la casa: una regla sin verificación es un deseo.
Las reglas se conectan a los procedimientos que las usan, y el guardián se las pone delante a la IA antes de ejecutar. No son un documento que quizá se lee: son contexto que se carga. La diferencia entre tener leyes y tener un poder judicial.
La doctrina que lo mantiene cuerdo
Dos principios evitan que el grafo degenere en el pantano que son todas las wikis corporativas a los dos años:
El grafo es plano de control, no plano de datos. Guarda índice, estado vivo y punteros. Los datos masivos viven en sus fuentes y se consultan en vivo. Los informes son consultas, no documentos: un informe guardado nace desactualizado y miente para siempre.
Jerarquía de verdad explícita. Si el grafo y un documento discrepan, gana el grafo. Si el grafo y la realidad discrepan, gana la realidad — y el grafo se corrige en el momento, como parte del propio trabajo. Cada tarea cerrada tiene que dejar el sistema sabiendo más que antes. Esa auto-mejora no es una funcionalidad: es la función.
La noche de los dos sembradores
Y entonces pasó algo que no estaba en el diseño.
Una noche había dos inteligencias artificiales trabajando en paralelo — una potente en una ventana, una más económica en otra, cada una con su tarea. Por una carambola de encargos, las dos se pusieron a sembrar reglas en el grafo a la vez, sin saber la una de la otra. Cuando la primera fue a verificar su trabajo, encontró nodos que no había creado.
Lo que ocurrió después es la mejor descripción de qué es este sistema: la primera IA detectó la colisión consultando el grafo, dejó una nota de coordinación en el trabajo de la otra ("no sembréis más desde esta línea; los duplicados se fusionan aquí"), y una tercera instancia ejecutó la fusión: cuarenta y tres reglas rescatadas, diez duplicados retirados con su puntero, cero pérdidas. Dos agentes que jamás hablaron entre sí se coordinaron a través del estado compartido, con reglas comunes y un registro común.
Eso ya no es una base de datos con tareas. Eso es un sistema operativo con procesos.
Lo que ha cambiado (y lo que duele)
Los resultados, sin épica: las sesiones arrancan en minutos en vez de en explicaciones; los procedimientos salen a la primera porque el conocimiento de la vez anterior está donde debe; y el sistema responde preguntas de negocio reales — a quién hay que facturar este mes, qué cliente se enfrió y por qué — con consultas en vivo, no con mi memoria.
Lo que duele, para que nadie compre humo: exige disciplina diaria (la tentación de "esto lo apunto luego" no desaparece por tener grafo); la poda es tan necesaria como en cualquier sistema de ficheros; dos agentes en paralelo aún pueden pisarse en lo temático aunque ya no en lo mecánico; y el humano sigue siendo el cuello de botella de las aprobaciones — a propósito, y que dure.
Por qué te cuento esto
No vendo nada. No hay repositorio que clonar, entre otras cosas porque escribo sobre patrones, no sobre planos. Pero el patrón sí es tuyo si lo quieres, y no necesita nada que no tengas: una base de datos, un CLI de cincuenta líneas y disciplina de operador.
La industria busca la memoria perfecta para sus agentes con vectores y frameworks que cambian de nombre cada seis meses. Yo solo apliqué lo que cuarenta años administrando sistemas me enseñaron sobre incorporar a alguien nuevo al turno de noche: dale un manual, una cola de tareas, reglas escritas, credenciales que no pueda copiarse a casa y un jefe que aprueba lo peligroso. Trátalo como a un operador, no como a un oráculo.
Resulta que eso también funciona cuando el operador nuevo es una máquina que piensa. Puede que sea lo más útil que me llevo de este oficio, ahora que me voy: los sistemas que duran no son los más listos; son los que tienen memoria, reglas y a alguien que poda.
— un viejo programador · 64 años · rss