Nadie sale en portada por poner tuberías

Esta semana ha salido un modelo nuevo, GPT-6 Astra, y se ha llevado todas las portadas: hilos, análisis, gente explicando qué significa para el futuro de la humanidad. Mientras tanto, en el sitio donde de verdad se trabaja, pasaban cuatro cosas que no ha cubierto nadie.

Coop: entornos de máquina virtual aislados para correr Claude Code y Codex. Engram: memoria persistente para agentes de codificación, local, en SQLite, conectada por MCP. La versión 0.2 de datasette-mcp, de Simon Willison. Y una nota del mismo Willison sobre manejar Blender desde un agente de codificación en macOS.

Ninguna de las cuatro es un modelo. Ninguna es lista para portada. Son tuberías.

Fíjate en lo que construye la gente, no en lo que anuncia

Hay una regla que me ha funcionado veinte años en sistemas industriales y me sigue funcionando aquí: cuando quieras saber si una tecnología va en serio, no mires los anuncios. Mira qué está construyendo la gente que ya la tiene encendida.

Los anuncios te dicen lo que alguien quiere vender. Las herramientas pequeñas te dicen dónde duele.

Y esas cuatro herramientas dicen todas lo mismo con distintas palabras: el modelo ya es lo bastante bueno, el problema es que el agente vive en una habitación vacía. No recuerda nada de ayer. No puede tocar nada que no le pegues en el contexto. Y si le dejas tocar, no hay pared que lo pare.

Tres agujeros. Aislar, recordar, alcanzar. Los cuatro proyectos de la semana están tapando esos agujeros, no compitiendo con OpenAI.

La memoria no va dentro del modelo. Va en un fichero que es tuyo

De las cuatro piezas, la que más me interesa es Engram. Y no por lo que hace, sino por dónde lo guarda.

Una memoria persistente para agentes de codificación, que vale para cualquiera que hable MCP (Claude Code, Codex, Cursor, Gemini CLI…), local por defecto, en SQLite. Traducido: tu agente recuerda, y lo que recuerda está en un fichero de tu disco que puedes abrir, copiar, versionar y borrar. No en la cuenta de nadie.

Aquí es donde a mucha gente se le tuerce el gesto, porque suena a poco. ¿Una base de datos en un fichero? ¿Eso es la gran innovación?

Sí. Eso es.

Llevo meses con agentes trabajando sobre mi vault en un Mac Mini encendido a todas horas, y la parte que más ha cambiado el resultado no ha sido cambiar de modelo. Ha sido que cada agente escriba lo que ha hecho en un sitio que sobrevive al cierre de la sesión. Mis agentes anotan su registro en la propia tarjeta de trabajo: qué montaron, sobre qué, cómo acabó. Al día siguiente, el que llega puede leerlo.

La memoria de un agente no es una función del modelo. Es una decisión de arquitectura que tomas tú, y se nota a los tres meses, no a los tres minutos.

Un agente sin memoria te da una demo. Un agente con memoria en tus ficheros te da un sistema que acumula. Es efecto compuesto, otra vez, aplicado a algo que la mayoría todavía trata como un chat.

Y una memoria que vive en tu disco tiene una propiedad que ninguna memoria alojada te da: puedes leerla. Cuando algo salga mal, que saldrá, abres el fichero y ves qué recordaba mal.

El día que mi director editorial se murió a mitad de flujo

Voy a bajarlo a suelo, porque «memoria en ficheros» dicho así no significa nada.

En mi sistema hay un tablero kanban que no es una aplicación: es una carpeta, «000 NEXUS/KANBAN/», con cuatro subcarpetas: «programadas», «pendientes», «en-curso», «hechas». Cada tarea es un fichero de texto. Y la carpeta donde vive el fichero es su estado. Mover el fichero de «pendientes/» a «en-curso/» es cambiar de columna, y esa operación es atómica: por eso nunca hay dos agentes trabajando sobre la misma tarea.

Dentro de cada tarjeta, al final, hay una sección, «Registro». Ahí escribe el agente lo que ha hecho, con fecha y hora, en sub-puntos: qué habilidad montó, sobre qué objeto, cómo acabó.

Ahora el caso. Tengo un agente que se llama «director editorial» y coordina la semana de contenido: pide tendencias, las hace filtrar, manda redactar. Un flujo de varios pasos que puede tardar horas.

Ese director no está vivo entre paso y paso. Escribe en su propia tarjeta de qué tarea depende, la devuelve a «pendientes/» y se muere. Literalmente: el proceso termina. Cuando la tarea hija aterriza en «hechas/», el lanzador lo despierta otra vez, y el director nuevo no tiene ni idea de lo que hizo el director de hace tres horas, porque es otro proceso, con el contexto en blanco.

¿Cómo sabe entonces por dónde iba?

Lee el tablero.

Su memoria no es su contexto. Es la carpeta. Reinicio a mitad de flujo significa reconstruir el estado leyendo ficheros, y funciona porque el estado está en los ficheros y no en la cabeza de nadie.

El 14 de septiembre, a las 17:41, ese flujo se rompió: el paso de filtrado falló porque una de sus entradas no existía en el vault. En la tarjeta de incidencia que se generó sola hay una frase que es exactamente de lo que va este artículo:

«sin hija de demanda de este director en hechas/ de la que re-cablear la ruta real».

Traducido: el sistema intentó arreglarse solo yendo a buscar en la carpeta de tareas terminadas una tarea anterior del mismo flujo, para copiar de ella la ruta buena. No la encontró y por eso escaló a un humano. Pero el intento de recuperación consistió en leer la memoria escrita en disco. No en preguntarle al modelo si se acordaba.

Hoy hay 66 tarjetas cerradas en «hechas/» y 91 más archivadas por meses en carpetas mensuales de archivo. Eso no es un log. Los logs los borras. Eso es la traza de auditoría de todo lo que el sistema ha hecho, en texto plano, con el nombre humano de cada cosa que tocó.

Y ahí está la segunda mitad del argumento, la que casi nadie cuenta: una memoria que puedes leer es también un sistema que puedes depurar.

El 7 de septiembre por la noche se me caducó el token de autenticación de uno de los arneses. Todos los agentes que salían por ahí empezaron a morirse. ¿Cuánto tardé en enterarme?

Dos días.

Dos días, porque el sistema tenía un mecanismo de respaldo que los relanzaba por otro arnés y las tareas seguían cerrándose con normalidad. El respaldo hacía su trabajo tan bien que ocultaba la avería. Lo descubrí de casualidad. Y la corrección no fue cambiar de modelo ni de proveedor: fue que la caída al respaldo dispare un aviso al móvil en el momento, porque el registro ya lo decía y nadie lee el registro de una tarea que salió bien.

Esa cicatriz solo se puede aprender si hay algo escrito que releer.

Memoria alojada o memoria tuya

La diferencia no es técnica, es de propiedad:

	Memoria en la cuenta del proveedor	Memoria en un fichero tuyo
Dónde vive	En su servidor	En tu disco, dentro de lo que ya versionas
Quién la lee	El modelo, cuando él decide	Tú, cualquier agente y cualquier editor de texto
Cuando recuerda algo mal	No hay nada que abrir	Abres el fichero y ves la línea exacta
Si cambias de modelo	Empiezas de cero	El fichero ni se entera
Si cambias de herramienta	Migración o pérdida	Sigue siendo un fichero de texto
Copia de seguridad	La que te den	Git, Time Machine, un pendrive
Lo que se acumula con los meses	Historial de conversaciones	Conocimiento sobre cómo trabajas
Si mañana cierran el servicio	Se va contigo dentro	Sigue ahí

La última fila es la que me hace elegir. Todo mi sistema es una carpeta de ficheros de texto: perfiles, tareas, registros. Si mañana desaparecen las herramientas que uso, me llevo el método entero. Es lo que se llevaría una fábrica si le quitaran las máquinas: el método, no el cacharro.

MCP no es un plugin. Es una puerta

Las otras dos piezas de la semana van por el otro lado del agujero.

datasette-mcp conecta un agente con Datasette, la herramienta de Willison para explorar bases de datos SQLite. Lo de Blender es todavía más gordo: un agente de codificación manejando un programa de 3D en tu Mac.

La forma vieja de resolver esto era la fuerza bruta. ¿Quieres que el agente trabaje con tus datos? Pégaselos en el prompt. ¿Que sean muchos? Pues un modelo con más ventana de contexto y a rezar.

Eso no escala. Ni con un millón de tokens.

Con un servidor MCP, el agente no recibe los datos: recibe permiso para ir a buscarlos. Pregunta, obtiene lo que necesita, sigue. Y lo mismo con Blender: no le explicas el programa, le das el mando.

Nadie lleva el almacén entero al banco de trabajo. Le das la llave al que sabe qué pieza necesita.

Ese cambio de «pegar contexto» a «abrir puertas» es la diferencia entre un asistente que te ayuda un rato y un agente que trabaja dentro de tu sistema. Y es también el momento en el que conviene acordarse de la primera pieza de la lista, la de las máquinas virtuales aisladas: cuantas más puertas abres, más importa saber en qué edificio están.

Que sea aburrido es la mejor noticia del año

Hace veinticinco años yo programaba líneas robotizadas de soldadura para General Motors. Los robots eran lo que salía en las fotos: el brazo naranja moviéndose, las chispas, la estampa de futuro.

¿Sabes qué sostenía realmente la línea?

Los utillajes. Las mordazas que sujetaban la chapa siempre en la misma posición, los sensores que confirmaban que la pieza estaba donde debía, los enclavamientos que paraban todo si algo no cuadraba. Fontanería. Nadie sacaba una foto de eso.

Sin eso, el brazo naranja te suelda al aire con una precisión exquisita.

Estamos exactamente ahí. El brazo ya funciona. Lo que se está construyendo ahora, memoria en SQLite, servidores MCP, entornos aislados, son los utillajes. Y el día que una tecnología deja de producir anuncios espectaculares y empieza a producir fontanería, no está muriendo.

Está entrando en producción.

Qué haría yo esta semana

Si tienes un agente trabajando sobre tus cosas y quieres una sola mejora, no cambies de modelo. Dale un sitio donde escribir lo que ha hecho.

Seis decisiones, y con esto lo tienes montado en una tarde.

Un fichero, y dentro de lo que ya guardas. Uno solo, en tu vault o en tu repositorio, no en una carpeta suelta del escritorio. Si ya tienes copias de seguridad de eso, la memoria de tu agente las hereda gratis.

Que escriba al terminar, no al empezar. La entrada útil no es «voy a hacer X». Es «hice X, salió Y». Una línea con fecha y hora, y debajo, sangrados, los hitos: sobre qué trabajó y cómo acabó cada cosa.

Nombres humanos, nunca identificadores. Esta me costó una cicatriz. Un agente mío cerró una tarea escribiendo «stubs_procesados: 1 (aB3xK9pQ2wE)». Perfecto para una máquina, inútil para mí. Lo que tenía que haber escrito es el título del vídeo, el canal y qué pasó con él. La regla que saqué: el registro tiene dos lectores, los agentes y tú, y los dos tienen que entenderlo sin abrir un log.

Que lo lea antes de empezar la siguiente. Escribir sin leer es un diario, no una memoria. El paso que convierte una cosa en la otra es que la primera instrucción del agente sea abrir ese fichero.

Separa la memoria del log. Mezclarlos estropea los dos. El log es el volcado de ejecución: enorme y desechable. La memoria es corta, de alta señal, y es lo que te importa dentro de tres meses.

Poda cada vez que crezca. Cuando el fichero pase de unas doscientas líneas, siéntate diez minutos: fusiona lo repetido y quita lo que ya no aplica. Una memoria que solo crece deja de leerse, y una memoria que no se lee no existe.

Cuando eso funcione, ya te plantearás abrirle puertas a tus datos con MCP.

Lo que no hay que hacer

Cuatro errores que he cometido yo, para que no los cometas tú.

Dejar que el agente decida solo qué recordar. Suena elegante y acaba en un vertedero de anotaciones triviales. En mi sistema, lo que entra en la memoria personal pasa por mi visto bueno: se me muestra la línea exacta y decido. Es un segundo y evita doscientas líneas de ruido.

Guardar el resultado sin guardar el fallo. La tarea que salió bien te enseña poco. La que se rompió es la que contiene la información. Si tu agente solo anota éxitos, has montado un boletín de prensa.

Abrir puertas antes que paredes. Es tentador empezar por MCP, porque es lo vistoso. Pero un agente con acceso a tus datos y sin aislamiento es un brazo naranja suelto por la fábrica. Primero decides dónde puede tocar; después le das la llave.

Fiarte de la demo. Un agente funciona espectacularmente el primer día y regular el día quince, cuando aparecen los casos raros. Mis perfiles de agente van por la versión ocho, y cada versión existe porque algo falló de verdad. Si el tuyo no ha cambiado desde que lo escribiste, o es perfecto o no lo has usado lo suficiente.

«Marcos, esto ya lo hace ChatGPT»

Sé lo que estás pensando, porque me lo han dicho.

«Los modelos ya tienen memoria. ¿Para qué me voy a montar yo un fichero?»

Porque no es la misma memoria. La del proveedor recuerda cosas sobre ti para darte mejores respuestas, y funciona bien para eso. La que digo yo es distinta: es el estado de tu trabajo. Qué se hizo, sobre qué fichero, con qué resultado y qué falló. Eso no te sirve encerrado en un solo proveedor, porque el día que uses dos herramientas a la vez, y las vas a usar, necesitas que las dos lean lo mismo.

«Yo lo probé, mi agente escribió su memoria y se llenó de basura inútil.»

Esa tienes razón. Es el fallo más común y no es culpa tuya: un agente al que le dices «apunta lo que aprendas» apunta todo, porque no sabe distinguir lo durable de lo anecdótico. La memoria no se arregla escribiendo más, se arregla con dos reglas: quién decide qué entra, y cuándo se poda. Sin esas dos, sí, acabas con un fichero de mil líneas que no lee ni el agente.

Un agente con amnesia no es un agente

No tengo esto resuelto. Llevo meses ajustándolo y sigo encontrándome cosas cada semana: lo del token caducado me tuvo dos días a ciegas, y el sistema lo había montado yo.

Pero de lo que sí estoy seguro es de dónde está la palanca. No está en el modelo que uses. Está en si lo que tu agente hace hoy sigue existiendo mañana.

Ahora dime una cosa, porque llevo tiempo dándole vueltas: tu agente, el que usas a diario, ¿recuerda hoy algo de lo que hizo ayer?

Si la respuesta es que no, no tienes un agente. Tienes una herramienta muy lista con amnesia.