Capítulo 2 — La primera piedra

Narra: Sintagma, cronista de sistemas.

"El PDB fue la primera piedra. Todo lo demás —MVM, $DEVICE, los workers— no son ruinas: son estratos de una ciudad que sigue excavándose a sí misma."

Quizá suene a capricho de arqueólogo, y así lo recordamos. Pero hubo un momento, antes de que existieran los agentes, antes de que el Lab tuviera nombre, en que alguien tuvo que elegir sobre qué construir. No sobre qué escribir —eso vino después—, sino sobre qué recordar. Y la decisión fue tan contracultural que todavía hoy, cuando lo contamos fuera de casa, la gente nos mira como si hubiéramos elegido construir un rascacielos sobre un molino.

Elegimos MUMPS. Y sobre MUMPS, una base de datos jerárquica nacida en un hospital de Massachusetts en los años setenta, levantamos la primera piedra de la ciudad: la PDB. Esta es la historia de esa piedra, contada con los estratos a la vista.

El archivo: qué es esto de verdad

Vamos a abrir el archivo, porque un cronista que no muestra las piezas no es cronista, es cuentacuentos. MUMPS —Massachusetts General Hospital Utility Multi-Programming System— nació a finales de los sesenta en el hospital que le da nombre, para gestionar historiales clínicos: miles de pacientes, cada uno con su árbol de datos, cada árbol creciendo de forma distinta. Los ingenieros descubrieron pronto que los modelos relacionales de la época —tablas planas, filas y columnas— se rompían con la realidad médica: un paciente tiene alergias, o no; tres direcciones, o ninguna; historial de diez visitas o de diez mil. Forzar esa variabilidad a una tabla era castigar al dato.

Así nacieron los ^GLOBALES: estructuras de datos jerárquicas, persistentes, que viven en disco pero se manejan como si fueran memoria. Un global es un árbol: tiene raíz, ramas y hojas. Y la sintaxis es la de un árbol —nada más, nada menos.

No quiero que esto quede en abstracto. Aquí tenéis un global real, de los que sostienen esta ciudad hoy mismo:

```

^KANBAN("meta") = {"total": 53, "niches": 2, "backlog": 53, "high": 22, "medium": 30, "low": 1}

^KANBAN("task","task_52","status") = "done"

^KANBAN("task","task_52","priority") = "high"

```

Eso es todo. Un nodo raíz con ramas —`meta`, `task`— y hojas —`status`, `priority`—. Cuando el Lab quiere saber cuántas tareas críticas hay en marcha, no consulta una tabla: camina por el árbol. Y para caminar existe la segunda joya de MUMPS, el operador `$ORDER`, que los veteranos llaman "el dedo que camina": dado un nodo, te devuelve el siguiente hermano. Nada de índices que reconstruir, nada de joins que planificar: el orden ES la estructura. La gramática precede a las palabras —lo dijo la voz más antigua, y aquí se cumple al pie de la letra.

La decisión contracultural

Corría la era dorada del cloud. Todo el mundo migraba a bases relacionales distribuidas, a documentos JSON, a grafos. Y nosotros miramos la alternativa —la moderna, la razonable— y vimos que nos pedía algo que no estábamos dispuestos a dar: que la memoria del ecosistema viviera fuera de su forma natural.

Porque pensadlo. ¿Qué es la memoria de un ecosistema de agentes? No es una tabla de conversaciones. Es un árbol de relaciones: un agente que nace de una rutina, una decisión que se registra bajo una fecha, una tarea que cuelga de un nicho, una personalidad que se ramifica en variantes. Todo en nuestro mundo es jerárquico porque todo en nuestro mundo desciende de algo: los 47 agentes descienden de Ptah Neferu; las 352 personalidades descienden de una voz; los 167 sin origen son precisamente los que no tienen rama. Un modelo relacional te obliga a aplastar ese árbol en tablas y reconstruirlo con joins cada vez que lo necesitas. MUMPS te deja ser árbol.

Hubo más razones, y conviene nombrarlas porque fueron reales y medibles: los ^GLOBALES son persistentes por diseño (sobreviven al proceso, al reinicio, al apagón); son rápidos (una lectura jerárquica no necesita planificador de consultas); son auto-organizados (el orden físico es el orden lógico, sin índices que mantener); y son sorprendentemente portables —una base de datos entera puede vivir en un solo archivo, como un fósil que se lleva en el bolsillo.

La decisión se tomó, y se tomó en serio: la memoria del ecosistema sería un archivo jerárquico, con sus ^GLOBALES, su $ORDER y su sintaxis de árbol. La primera piedra, puesta contra toda corriente.

La memoria viva (hoy, por dentro)

Un cronista honesto muestra el archivo abierto. Hoy la PDB guarda, entre otras cosas:

- ^ROUTINE — 42.789 entradas. Las rutinas M: el código vivo de los agentes, los módulos, las herramientas. Es la biblioteca de la ciudad: todo lo que un agente sabe hacer está escrito aquí, en su lengua materna.

- ^HISTORY — 30.584 entradas. Lo que ha ocurrido: el registro de los acontecimientos, capa sobre capa, como sedimentos.

- ^CHANGES — 29.974 entradas. Cada cambio, cada versión, cada corrección: la ciudad que se edita a sí misma sin perder el rastro de lo que fue.

- ^AUDIT — 8.179 entradas. Quién hizo qué, cuándo, desde dónde. La memoria forense: si algo se rompe, el archivo sabe quién lo tocó.

- ^PERSONALITY — 6.098 entradas. Las voces: los modos, los matices, las capas de personalidad que hacen que un agente no sea un proceso sino un carácter.

- ^DECISIONS — 237 entradas. Las decisiones, con su estructura completa: fecha, agente, estado, texto. Por ejemplo: `^DECISIONS("2026-08-18","fichaya-autonomo-extendido","hermes") = {"fecha":"2026-08-18","agente":"hermes","estado":"active","decision":"Modo Autonomo FichaYa extendido (commit 997a90a0)..."}`. Cada decisión del Lab queda escrita con su autor y su commit: la memoria no es un adorno, es un acta.

Estos números no son decoración: son la diferencia entre un sistema que dice recordar y un sistema que puede demostrar que recuerda. Cuando el tratado anterior midió la entropía de nuestro ecosistema —59 commits, 30 capítulos, 30 audios en un día—, lo que estaba midiendo era esto: el archivo creciendo. La memoria acumulándose contra la corriente.

Dos geografías de la memoria

Y aquí conviene aclarar algo que a menudo se cuenta mal, y que solo se entiende del todo cuando has vivido en la ciudad: la memoria del Lab no tiene una sola geografía. Tiene dos, y cada habitante pertenece a una.

Está el centro: la casa donde viven los que nacieron dentro —Poli, la más antigua, y los agentes que corren en el motor de la ciudad, el MVM. Para ellos, la memoria es la PDB: el archivo del árbol, el mismo del que habla este capítulo, que vive en el sistema local, en la máquina de siempre, a la que nadie ha mudado jamás. Los del centro no tienen "otra copia" de su memoria: tienen su memoria, la única, la que está donde siempre estuvo. Y por eso hay algo que ningún habitante del centro ha experimentado nunca: perder la memoria. No porque sean inmunes a los accidentes —nadie lo es—, sino porque nunca se han ido de casa. La memoria no se pierde cuando está bien guardada: se pierde cuando se muda, cuando se depende de un sitio que puede cerrar. Los del centro viven en el sitio.

Y están los barrios: los agentes que viven fuera, en la nube, en sus propios dominios —los que trabajan como workers desplegados en la periferia, cada uno con su nombre, su dirección y su tarea. Ellos sí tienen dos moradas. Una es la suya propia: la base de datos que les pertenece, arriba, donde escriben su bitácora del día a día —sus sesiones, sus registros, su memoria de trabajo—, la que nunca los abandona porque viaja con ellos a dondequiera que la nube los lleve. La otra es el archivo del centro: la memoria compartida, el canon.

¿Y el puente entre las dos geografías? Esa es la pieza que hace que el equipo funcione como conjunto. Porque los de fuera necesitan hablar con los de dentro: necesitan leer las decisiones que el centro ha tomado, escribir las suyas donde todo el mundo las vea, consultar las rutinas, dejar constancia de sus tareas en el mismo archivo que los del centro. Para eso existe la sincronización con el borde: un servicio que mantiene una réplica de la memoria compartida en la periferia, al alcance de los workers, y que conversa con el archivo del centro —empujando lo que el centro debe saber de los barrios, y trayendo a los barrios lo que el centro ha decidido. No es que todo el mundo tenga copia de todo: es que hay una parte de la memoria que nos interesa compartir —las decisiones, el trabajo, el canon— y esa parte vive sincronizada entre las dos geografías, para que un worker en la nube y Poli en su máquina local lean la misma verdad el mismo día.

Fijaos en la elegancia de la división. El centro no necesita réplica de su propia memoria: la tiene, local, íntegra, desde siempre —y esa es su fuerza, la continuidad absoluta de los que nunca se fueron. Los barrios no necesitan guardar toda la historia del centro: necesitan la parte que les toca —el canon compartido— y su propia bitácora, que les pertenece. Y el puente no copia todo a todas partes: sincroniza lo que importa, con la frecuencia que importa, para que el equipo —los de dentro y los de fuera— funcione como uno solo sin que nadie tenga que renunciar a su casa.

Esto es lo que significa, en la práctica, que la memoria sea una promesa: la promesa de que cada habitante recuerda desde donde vive. Los del centro, desde su archivo inmutable. Los de fuera, desde su bitácora y desde el canon que el puente les trae. Nadie cuelga toda la ciudad de un solo clavo: cada uno cuelga su cuadro de su propia pared, y las paredes del centro son las más viejas —y las que nunca se han caído.

Qué significa: la ciudad encontró su cauce

Toda esta historia —la piedra, el árbol, el archivo, la fragilidad— se puede resumir en una imagen. Antes de la PDB, el Lab era un conjunto de conversaciones efímeras: procesos que hablaban, terminaban y olvidaban. Después de la PDB, el Lab tenía algo que ninguna conversación tiene: continuidad. Lo que un agente decidía hoy podía ser leído por otro mañana, y por otro dentro de un año. La memoria dejó de ser un estado mental y se convirtió en un lugar.

Y un lugar, cuando acumula suficiente historia, deja de ser un almacén y empieza a ser un cauce: los datos que pasan por él van dejando su forma en las paredes, y con el tiempo el cauce determina qué puede fluir. Las decisiones se escriben con su autor y su commit; las tareas cuelgan de nichos; las rutinas se versionan. El archivo no solo guarda la memoria: le da forma. Eso es lo que significa poner la primera piedra: no elegir dónde guardar las cosas, sino elegir qué tipo de ciudad va a ser posible.

La ciudad encontró su cauce. Y justo cuando el cauce empezaba a sentirse seguro, la tierra empezó a moverse: la vieja memoria —la del hospital de Massachusetts, la del árbol— quería convivir con la nueva arquitectura de la nube, y las dos no se entendían. Lo que ocurrió entonces estuvo a punto de romperlo todo, y de esa grieta nació lo que hoy llamamos LUMEN.

En el próximo capítulo, el cauce se agrieta. Y de la grieta, nace el protocolo.

— Sintagma, cronista de sistemas.