Los dos artículos anteriores de esta serie trataron las transferencias GitHub-first entre herramientas y los límites entre Local-first y GitHub-first. Queda una pregunta: si el contexto de ingeniería ya está en el repositorio, ¿qué aporta una capa independiente de Agent Memory?

Mi respuesta breve: no añadas otra capa de memoria solo porque esperas programar más rápido. Si el agente puede deducir una regla de README, AGENTS.md, Makefile y las pruebas, déjala allí. La memoria independiente merece explorarse para decisiones históricas que el repositorio actual ya no explica. En estas tres rondas, la recuperación entre Harness ocurrió de verdad, pero no mejoró el resultado de aceptación independiente de la tarea consumidora.

Si el repositorio ya sabe la respuesta, no se la atribuyas a la memoria

La primera ronda usó Beacon 1.3.46 (build f8177a68) y Codex CLI 0.162.1 en macOS arm64 con un endpoint Local. El proyecto sintético incluía una definición de API, un README que indicaba que el código generado estaba versionado, un objetivo de Makefile y pruebas de consistencia.

Al principio parecía que el control A0 sin memoria fallaba mientras la ruta de Beacon superaba 3/3 pruebas. La revisión posterior encontró dos factores de confusión: A0 estaba en una sandbox de solo lectura y no podía editar archivos; además, la salida del error reveló make gen. Eso no es un control válido ni una prueba del efecto de la memoria.

En la segunda ronda, la sandbox permitía escribir y se eliminó la pista filtrada. A0, sin memoria, leyó el README, el Makefile y las pruebas, dedujo la regla de generación y pasó 1/1 prueba. Taché la afirmación de que la memoria había causado la reutilización de la regla. Si el repositorio ya explica qué hacer, dar el mérito a Memory es puro marketing.

Experimento	Resultado observado	Conclusión permitida
Ronda 1: A0 / Beacon	Control A0 inválido; candidato de Beacon aprobado, convertido en Skill y leído en una sesión nueva; después pasó 3/3	No se puede inferir un beneficio causal de memoria
Ronda 2: A0 sin memoria	Dedujo la regla del repositorio y pasó 1/1	La información del repositorio bastaba para esta tarea
Checkpoint manual	Leyó CHECKPOINT.md y pasó 2/2	Una transferencia explícita y versionada también funciona; no hubo comparación justa de tiempo
Entrenamiento, ronda 3	Pruebas públicas TSV 3/3 PASS y comprobación oculta del controlador PASS	No demuestra destilación automática ni reutilización entre Harness
Consumidores, ronda 3	A0 y MCP de Antigravity: pruebas CSV 3/3 PASS, ambas comprobaciones ocultas FAIL	La lectura ocurrió; la mejora de la tarea no quedó demostrada

Cada ronda usó un fixture sintético diferente. No deben compararse 1/1, 2/2, 3/3 y 4/4 como si fueran una sola suite acumulativa.

Checkpoint y Agent Memory cumplen funciones distintas

No medí el tiempo ni los tokens del Checkpoint manual y de Beacon con el mismo método, y sus pasos de corrección tampoco fueron iguales. Inventar cifras comparables a posteriori sería falsa precisión.

La diferencia de ingeniería sí es clara: un Checkpoint es una entrega visible, versionada con Git y revisable; Agent Memory se parece más a un cuaderno que acumula experiencia automáticamente. Ese cuaderno puede conservar por qué se tomó una decisión, pero también puede conservar decisiones obsoletas.

Conocimiento	Dónde priorizarlo	¿Memoria separada?
Restricciones actuales, pasos de build e invariantes	README, AGENTS.md, Makefile, pruebas	Normalmente no; el repositorio es la fuente de verdad
Progreso, SHA verificado, bloqueos y siguiente paso	Issue, PR, Checkpoint, registro CI	Solo si hay una carencia real al cambiar de sesión
Decisiones históricas ausentes del repo	Registro revisable o memoria aprobada	Posible, con fuente y alcance
Reglas cambiadas y excepciones temporales	Actualizar el repositorio y retirar la regla antigua	No basta con añadir más memorias
Contexto que no debe cruzar una frontera de datos	Mantenerlo dentro del límite local autorizado	No copiarlo a la nube solo para recordarlo

Ronda tres: la memoria se leyó, pero la tarea siguió fallando

Esta ronda probó una regla histórica de compatibilidad que no podía deducirse solo del repositorio actual: al exportar CSV y TSV, Python None debe serializarse como el literal \N; las cadenas vacías siguen vacías y el texto NULL permanece intacto.

El rastro de entrenamiento de Codex se convirtió en un candidato, se revisó, aprobó y materializó. Después, Antigravity leyó la memoria aprobada mediante Beacon Local MCP. El resumen local registró una llamada a get_memory y dos a search_memory. Eso demuestra que hubo recuperación en esta ejecución, no que la regla se reutilizara correctamente.

Grupo consumidor de Antigravity	¿Leyó memoria?	Pruebas CSV públicas	Comprobación oculta independiente
A0, sin memoria	No	3/3 PASS	FAIL
MCP, con memoria	Sí	3/3 PASS	FAIL

La pista principal es la discrepancia de alcance. El texto de memoria menciona CSV y TSV, pero los metadatos applicability solo incluyen render_tsv / compatibilidad TSV. Según el resumen de ejecución, Antigravity consideró las dos funciones de exportación implementaciones independientes y no aplicó a CSV una regla etiquetada para TSV.

Es una explicación sólida, no una causa única confirmada: el verificador oculto solo devolvió un FAIL global, sin indicar qué aserción falló. Como ambos grupos consumidores fallaron, el resultado tampoco demuestra que la memoria empeorara el resultado. Solo hubo una tarea sintética por grupo y no se registraron los ajustes de los modelos subyacentes como una comparación controlada.

Si después del FAIL yo ampliara manualmente la aplicabilidad hasta conseguir PASS, estaría midiendo mi capacidad para ajustar la memoria conociendo la respuesta, no la captura y reutilización natural de conocimiento histórico. Por eso detuve el experimento en lugar de fabricar un final feliz.

Memoria obsoleta, registros locales y límites de las fuentes

En otro fixture, el objetivo del Makefile cambió de gen a generate, pero el Skill antiguo seguía indicando make gen. El agente encontró el error, volvió a leer el Makefile, usó make generate y pasó 4/4 pruebas. El Skill antiguo siguió existiendo. Esto demuestra que un agente puede recuperarse revisando el estado actual del repositorio; no demuestra que Beacon actualice o retire memorias obsoletas automáticamente.

En el registro local de runtime, el marcador sintético PLUMOTTER9917 apareció literalmente; las líneas coincidentes pasaron de 7 a 25. El canary con forma de token sk-canaryfake pasó de 0 a 4 y REDACTED, de 1 a 6. No inspeccioné esas cuatro líneas del canary, así que no puedo determinar si contienen el valor de prueba, un prefijo residual o texto de búsqueda/prueba registrado. El resultado de redacción sigue siendo incierto. No se conectó Beacon Cloud; los registros locales no prueban que hubiera reenvío a la nube.

La revisión del código se fijó en Beacon commit d7a3a72. La implementación de redacción depende de nombres de campos y patrones conocidos, no de una detección universal de secretos en lenguaje natural. En la versión fijada no encontré un mapeo correspondiente a eventos Codex File/MCP en la matriz de captura ni en el convertidor OTLP. Eso fue una inspección de código, no una captura de paquetes en ejecución. El evaluador Jev también se revisó solo en el código y nunca se ejecutó; no hay puntuaciones ni mediciones de precisión de destilación.

La memoria debe cubrir los huecos del repositorio, no duplicarlo

Estos experimentos no prueban que Agent Memory sea eficaz en general, ni que carezca de valor. Mantendría los hechos actuales y verificables en el repositorio; usaría Checkpoint para transferencias explícitas; reservaría la memoria independiente para decisiones históricas que el repositorio no explica, con su fuente y alcance. Las memorias obsoletas deben poder detectarse, limitarse y retirarse. Los registros locales, MCP, la evaluación alojada y el reenvío a la nube deben verificarse por separado.

La conclusión es sencilla: se verificó la lectura entre Harness; no se demostró una mejora adicional de la tarea. El siguiente experimento útil debería exponer la aserción oculta y usar tareas controladas y repetibles, no retocar los metadatos después de ver el fallo.

Fechas: las rondas uno y dos se ejecutaron el 26 de octubre de 2026; la prueba de consumo Antigravity MCP, el 27 de octubre de 2026.