No RAG, no base de datos vectorial — memoria construida con archivos markdown. Cuatro tipos de memoria, estrategia de índice, carga automática vs bajo demanda, y la disciplina de poda que la mantiene viva.

Esta es la parte 3 de la serie Alice Way. En la parte 2 Diseño de persona, separé la persona ("quién es este colaborador") de la memoria ("qué sabe actualmente como verdad"). Este artículo es el registro de cómo construí esa memoria.

Empecé pensando en soluciones elaboradas: base de datos vectorial, embeddings, pipelines RAG. Lo descarté todo en pocos días. La cantidad de contexto que realmente acumulo en un día no es tan grande. Lo que necesitaba era un lugar no volátil, legible por humanos y que la herramienta pudiera cargar automáticamente. La respuesta fue el sistema de archivos.

0. La memoria es una extensión de la mente

Si una persona es "quién es este colaborador," la memoria es "qué tiene actualmente en mente este colaborador."

Un contexto que se evapora obliga al operador a pagar el coste de reconstruir el mismo estado mental cada día. Qué se decidió ayer, por qué se decidió, qué no funcionó: si todo eso desaparece al inicio de la siguiente sesión, el operador reconstruye cada mañana la misma porción de mente.

La memoria no es RAG, no es una base de datos vectorial. Es el dispositivo más simple posible para evitar que las decisiones, el feedback y el contexto del operador se pierdan en la siguiente sesión.

A partir del §1, este artículo cubre cómo se construyó ese dispositivo — con un puñado de archivos markdown y un único índice.

1. La decisión simple — archivos markdown

Lo que encontré:

memory/
├── MEMORY.md              # índice (carga automática)
├── user_role.md           # tipo usuario
├── feedback_testing.md    # tipo feedback
├── project_q2_release.md  # tipo proyecto
├── reference_grafana.md   # tipo referencia
└── ...

Una memoria = un archivo
Un único índice (MEMORY.md) con punteros de una línea a cada archivo
Cada archivo es markdown, directamente legible por humanos
La herramienta carga automáticamente las primeras N líneas del índice al inicio de la sesión

Eso es todo. Sin infraestructura sofisticada. Gestionado en git, editado en un editor de texto, buscado con grep.

El contexto que realmente acumulas cada día es sorprendentemente pequeño. La disciplina importa más que la infraestructura.

2. Cuatro tipos de memoria

No toda la información se trata como un solo tipo. La divido en cuatro.

2.1 `user` — hechos sobre el operador

Quién es el operador, qué rol juega, qué áreas conoce.

---
name: user-role-and-expertise
description: Rol del operador · experiencia · plataformas
metadata:
  type: user
---
 
El operador es un ingeniero senior, lenguajes principales X·Y·Z, trabaja principalmente en A·B.
El frontend es reciente — explicar conceptos de frontend mediante analogías de backend.

El mayor beneficio de este tipo es que las respuestas se ajustan al nivel y dominio del operador. El tono de estudiante desaparece, y las cosas que el operador ya sabe dejan de re-explicarse.

2.2 `feedback` — guía explícita

Guía explícita del operador. Tanto "no hagas esto" como "sigue haciendo esto."

---
name: integration-test-policy
description: Los tests de integración deben ejecutarse contra una BD real — sin mocks
metadata:
  type: feedback
---
 
Ejecutar tests de integración contra la BD real, no una simulada.
 
**Por qué:** El trimestre pasado el test simulado pasó pero la migración en prod falló.
**Cómo aplicar:** Cada test en integration/. unit/ puede seguir usando mocks.

Para el tipo feedback, siempre escribir Por qué y Cómo aplicar junto a la regla. Las reglas sin motivo fallan en los casos límite. Con la razón explícita, es posible trasladar la misma intención a situaciones nuevas.

El feedback se registra tanto para correcciones tras un fallo como para validaciones tras un éxito. La segunda categoría es fácil de omitir, pero hacerlo obliga a re-negociar la misma buena decisión en la siguiente sesión.

2.3 `project` — contexto del trabajo en curso

Hechos sobre el trabajo actual. El tipo más volátil.

---
name: q2-merge-freeze
description: Calendario de congelación de merge para el corte de la versión móvil Q2
metadata:
  type: project
---
 
La congelación de merge comienza el 2026-03-05 (corte de rama de versión móvil).
 
**Por qué:** El equipo móvil está cortando su rama de versión.
**Cómo aplicar:** Marcar el trabajo de PR no crítico programado después de esa fecha.

La clave es convertir el tiempo relativo en tiempo absoluto. Expresiones como "la próxima semana" o "el jueves" pierden significado pocos días después de entrar en la memoria. Hay que registrar siempre fechas absolutas del tipo "2026-03-05".

El tipo project se desactualiza más rápido, por lo que también es el más podado (ver §5).

2.4 `reference` — punteros a sistemas externos

Punteros a dónde vive la información. No la información en sí.

---
name: oncall-latency-dashboard
description: Tablero Grafana grafana.internal/d/api-latency — el tablero de latencia de guardia
metadata:
  type: reference
---
 
Tablero a consultar cuando se toca código de manejo de solicitudes.
La guardia lo monitorea; es lo que alerta a alguien, así que comparar antes/después en los cambios.

reference registra qué es algo en una ubicación concreta de un sistema externo (Linear, Grafana, Notion, Slack, etc.). La información en sí cambia; la ubicación es estable. Recordar la ubicación evita tener que buscarla de nuevo cada vez.

3. El índice — un único `MEMORY.md`

Cada archivo de memoria se descubre a través de un único índice.

# Memoria
 
> Las primeras 200 líneas se cargan automáticamente. Las reglas centrales viven en la persona; esto son solo punteros.
 
## Índice de archivos de memoria
 
### Reglas / procedimientos
- [work-process.md](rules/work-process.md) — procedimiento de recepción de trabajo
- [multi-agent.md](rules/multi-agent.md) — delegación de Subagents, Quality Gate
- ...
 
### Feedback / referencias
- [feedback/](feedback/) — testing / model_policy / env_minimalism / ...
- [reference/dashboards.md](reference/dashboards.md) — índice de tableros de guardia

El índice no es memoria. Es una colección de anzuelos de una línea que apuntan a las memorias. El índice en sí nunca lleva contenido: solo punteros.

Esta división mantiene el índice corto. Aunque la herramienta solo carga automáticamente las primeras N líneas al inicio de la sesión, el anzuelo de cada memoria cabe en ese espacio. Cuando una memoria concreta se vuelve relevante, solo ese archivo se lee en ese momento.

Un índice más lectura activada por disparo cubre la mayoría de los casos de forma más simple que RAG.

4. Carga automática vs bajo demanda — la economía de tokens

El sistema combina dos modos de carga.

Modo	Qué entra	Cuándo
Carga automática	Primeras N líneas de `MEMORY.md`	Cada inicio de sesión
Lectura bajo demanda	Archivos específicos a los que apunta el índice	Al entrar en trabajo relacionado con ese archivo

Esta división es el corazón de la economía de tokens. Leer cada archivo de memoria en cada sesión consume tokens. Cargar automáticamente solo el índice, y leer los cuerpos solo cuando se necesiten, hace que casi cada sesión empiece muy ligera.

Dos disparos deciden cuándo se lee un cuerpo.

El operador lo menciona explícitamente — "mira la política de tests de integración"
El trabajo en sí entra en el área relevante — empezar un PR relacionado con BD carga las memorias relacionadas con BD

El segundo caso importa más. El operador no tiene que decir "mira esta política" en cada ocasión: el colaborador carga la memoria relevante por sí solo. La description de una línea en el índice es la base para esa decisión.

5. Poda — la memoria colapsa si solo crece

La mayor trampa de un sistema de memoria es acumular sin podar. La acumulación pura crea dos problemas.

La información obsoleta sigue viva — un proyecto cerrado hace un mes aún tiene su calendario en la memoria, empujando hacia juicios incorrectos.
El índice se infla — las entradas crecen más allá del rango de carga automática de 200 líneas y esta pierde su utilidad.

Aplico el siguiente patrón de poda.

Tipo	Cadencia de poda	Criterio
`user`	Casi nunca	La identidad cambia lentamente
`feedback`	Una vez al trimestre	Eliminar guía que ya no aplica
`project`	Una vez al mes	Mover proyectos cerrados a un directorio de archivo
`reference`	Dos veces al año	Eliminar enlaces rotos y sistemas desaparecidos

Archivar no es eliminar. Se mueven a un directorio separado como memory/archived/. Salen del índice pero permanecen en el historial de git y en disco, por lo que se pueden recuperar si es necesario.

Un patrón adicional: una herramienta de auditoría automática. Periódicamente escanea el directorio de memoria y genera un informe del tipo "este elemento no ha sido referenciado en más de 60 días." El operador lee ese informe y toma decisiones de poda con rapidez.

6. Patrones de fallo — todos los que intenté

Patrones que probé y abandoné en el camino a este sistema.

6.1 Un único archivo gigante

Inicialmente puse toda la memoria en un archivo. Un único notes.md. En pocos días superó las 1.000 líneas, y la herramienta gastaba casi todos los tokens del inicio de sesión leyéndolo.

→ Lección: La memoria debe dividirse. Separación de índice + archivos de cuerpo.

6.2 División demasiado fina

Lo opuesto — división demasiado fina. Un archivo por decisión. Aparecieron 50 archivos, el índice se disparó y consumió toda la ventana de carga automática.

→ Lección: Un archivo = un "tema," no una "decisión." Múltiples decisiones sobre el mismo tema van al mismo archivo.

6.3 Acumulación indiscriminada

Probé una automatización que "resume el trabajo de hoy y añade a la memoria" al final de la sesión. La memoria crecía cada día y las decisiones importantes se ahogaban en el ruido.

→ Lección: Lo que va en la memoria es una decisión, hecho o puntero que seguirá siendo útil en la siguiente sesión. El progreso del día va en el tablero de tareas o en un log de historial, no en la memoria.

6.4 Texto plano sin metadatos

Empecé con markdown plano, sin frontmatter. A medida que el recuento creció, "qué tipo es esto" y "por qué se escribió esto" se volvieron imposibles de rastrear.

→ Lección: Exigir al menos tres campos de frontmatter: name, description, type. En el cuerpo, dos líneas adicionales: Por qué y Cómo aplicar.

7. Efecto real

Qué cambió después de adoptar este sistema.

Ítem	Antes	Después
Restauración de contexto al inicio de sesión	5–10 min	Instantáneo (carga automática del índice)
Re-negociar la misma decisión	A menudo	Casi nunca
Re-explicar el trabajo de ayer	Cada vez	Nunca (está en la memoria)
Juicio incorrecto por información obsoleta	A veces	Raro (poda)
Patrón de gasto de tokens	Plano-alto cada sesión	Proporcional al trabajo (lo superficial permanece ligero)

El mayor cambio es la última fila. El gasto de tokens sigue la profundidad del trabajo. El trabajo superficial termina casi de forma gratuita; los recursos van al trabajo profundo.

8. Comprimido en un principio

El diseño del sistema de memoria se resume en un principio.

"El índice siempre está ahí. El cuerpo solo entra cuando se necesita. Lo que ya no es válido sale del índice."

Cuando los tres se cumplen, la memoria deja de ser una carga creciente y empieza a ser un activo que acelera el trabajo.

El siguiente artículo cubre la capa siguiente a la que apuntan la persona y la memoria: skills y slash commands, es decir, qué repeticiones vale la pena promover a una invocación de una sola línea.

3. Sistema de memoria — dónde y cómo se acumula el contexto dinámico