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 telar
El corazón es lo que llamo el telar: un 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 — las combinaciones permitidas, que el CLI valida al enlazar — que impide unir sinsentidos. El vocabulario es cerrado a propósito: si algo no encaja en las siete, casi nunca merece arista. Para eso está la otra convención de la casa, la que me ha ahorrado meses de sobre-ingeniería: antes de inventar una relación nueva, una referencia en texto. No es una puerta trasera del esquema; es su criterio de admisión. La prosa envejece mejor que los esquemas.
Los mecanismos, subsistema a subsistema
La analogía del sistema operativo la sostengo con las pinzas puestas: no hay kernel, y si prefieres llamar a esto un gestor de tickets con cinturones de seguridad, no te voy a pelear el nombre. Lo que sí defiendo es que no es humo de charla: cada subsistema clásico tiene aquí 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. Y seamos precisos sobre qué es duro y qué no: la negativa del CLI es dura — un código de salida, no una sugerencia —; las reglas cargadas en contexto son blandas, porque un modelo puede ignorar lo que lee. Para esa grieta están las otras dos capas: la bitácora que delata y el humano que aprueba.
Los permisos. Las credenciales viven en una bóveda cifrada por valor: la clave se deriva de un PIN que solo yo sé, más un secreto local que no viaja con los datos — si la tabla se filtra entera, es ruido. La IA recupera cada credencial por nombre, en el momento de uso y solo con la bóveda abierta por mí. Seré exacto, porque aquí es fácil venderse: el diseño minimiza la exposición de los secretos; decir que la elimina sería mentir. 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.
Y hay un trade-off que conviene confesar, porque choca de frente con la vocación testamentaria de todo esto: una bóveda sellada con un PIN que solo sabe uno y un secreto que no viaja con los datos es magnífica contra la filtración — y letal para la sucesión. El día que el PIN muere conmigo, la memoria sobrevive pero las llaves no. No tengo la respuesta definitiva (un depósito de confianza, un sobre cerrado, o la decisión explícita de que la bóveda muera con el dueño, que también es una decisión legítima); tengo la pregunta escrita, que es lo mínimo que exige este blog: quien copie el patrón, que copie también el agujero y elija qué pone encima.
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. Y desde hace poco mira también una señal que no estaba en el diseño original: qué proporción de lo escrito lo escribió la IA y qué proporción ha puesto ojos humanos encima. Si el telar se volviera un monólogo de resúmenes de máquina que nadie relee, enfermaría igual que una wiki — y el primer síntoma estaría en ese ratio, no en los datos.
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 — una tarea de cron de las de toda la vida, que las hay y las seguirá habiendo — 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.
La fontanería, sin misterio
Más de un lector estará buscando el truco: ¿un demonio escuchando? ¿el modelo conectado a la base de datos? Nada de eso. No hay proceso residente. El agente es un asistente de programación con acceso a shell en mi máquina de desarrollo, y el telar se lee y se escribe a través de un CLI pequeño sobre MySQL. Una sesión nace cuando yo la arranco: pide su paquete de contexto con un comando, trabaja, anota cada acción como líneas, y muere. Lo que persiste no es el proceso — es el contrato de datos.
Las tareas programadas de verdad son cron de toda la vida, aburridas a propósito. La aprobación agrupada tampoco es una cola asíncrona sofisticada: es una conversación — el agente propone el lote nombrando el destino, y yo digo sí o no en la misma sesión. Y el planificador de última instancia sigo siendo yo: decido cuándo hay sesión y cuándo no. Eso también es control de costes, el más viejo que existe.
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 telar degenere en el pantano que son todas las wikis corporativas a los dos años:
El telar 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 telar y un documento discrepan, gana el telar. Si el telar y la realidad discrepan, gana la realidad — y el telar 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 telar 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 telar, 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.
El ingeniero escéptico dirá: eso es una race condition resuelta a mano y documentada. Sí. Esa es exactamente la cuestión — el estado compartido convirtió una colisión invisible en un incidente visible, auditable y con arreglo trazado. A los sistemas no se les mide por no tener accidentes; se les mide por cómo los cuentan.
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 telar); 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. Y para que nadie tenga que fiarse de mi palabra, el esquema completo — tablas, tipos, relaciones y hasta la bóveda, comentarios incluidos — está publicado en el apéndice: el esquema, desnudo.
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