El 90% de los AI Agents que Construyes Hoy Serán Amnésicos Mañana
No porque el modelo no tenga contexto. Sino porque su "memoria" es un buffer lineal de mensajes.
Y un buffer no es una arquitectura.
Deslizas mensajes en un array `messages[]`, crece sin límite, y cuando se topa con la ventana de contexto haces lo único que sabes: truncas o resumes. El resultado es un agente que ayer acordó contigo que cada lunes a las 9 te iba a mandar un resumen de tu semana, y hoy te pregunta quién eres.
El 90% de los AI agents que se construyen hoy son amnésicos por diseño. No es una broma. Es arquitectura.
*La diferencia entre agentes que funcionan y agentes que fallan no está en el modelo. Está en la capa de memoria oculta. *
Voy a desmontar por qué el enfoque estándar está roto, por qué "cabes más tokens" no es lo mismo que "recordar", y te dejo un framework de tres capas con code real que puedes implementar hoy.
---
El Problema: La Amnesia Estructural de los LLMs
Los transformers no retienen estado entre llamadas. Por construcción. Cada llamada a la API empieza de cero.
El estado que sí tiene el agente vive en el prompt que tú le montas. Y si ese prompt es simplemente el historial completo de mensajes, tienes tres problemas simultáneos:
Primero: el sesgo de recencia. Los transformers atienden mejor los tokens recientes. Cuanto más largo es el historial, más probabilidad de que la información relevante del principio quede sepultada. La degradación no es lineal — es exponencial con la longitud.
Segundo: la latencia crece por sesión. Cada turno añade tokens al request. A las 50 interacciones estás pagando latencia y coste por contextos que el agente ya ni procesa.
Tercero: no consolida nada. Lo que tu agente "aprendió" hoy — tus preferencias, tus proyectos, una decisión crítica — no sobrevive al cierre de la sesión. Nada se escribe a un store persistente.
La compactación ingenua tampoco salva: resumir todo pierde fidelidad. Terminas con un resumen de un resumen de un resumen, y la información específica — el nombre del cliente, la cifra exacta, la decisión — se evapora en el tercer nivel de abstracción.
La Objeción de los 1M Tokens
"Sí, pero las ventanas de contexto ahora son de 1M+. Cabe toda la conversación."
*Caber no es recordar. *
Un historial de 500k tokens degrada la atención del modelo, dispara la latencia y, sobre todo, no persiste nada entre sesiones. Cierras la ventana y el conocimiento aprendido hoy desaparece. No hay write path. No hay consolidación. No hay memoria — hay un cache temporal gigante.
La ventana de contexto es working memory chip. La memoria de verdad vive en otro sitio.
---
El Framework de 3 Capas para Memoria de AI Agents
La arquitectura correcta separa tres capas con patrones de lectura/escritura y vida útil distintos. No es casualidad que mapee a la memoria humana: working memory de capacidad limitada (los ~7 chunks de Miller, 1956), conocimiento semántico a largo plazo y memoria episódica como línea temporal de experiencias.
Capa 1 — Working Memory: el contexto inmediato. Ventana deslizante con presupuesto de tokens acotado. Historia reciente + un resumen compactado que se mantiene vivo en el system prompt.
Capa 2 — Long-Term Memory: conocimiento semántico persistente. Hechos extraídos, preferencias, datos de negocio. Almacenados como embeddings + metadata, recuperados por similitud semántica.
Capa 3 — Episodic Memory: el registro temporal de lo que pasó. Decisiones tomadas, acciones ejecutadas, resultados obtenidos. Cada episodio es un evento timestamped que se recupera por similitud de situación.
La implicación práctica no es filosófica: separar las capas es lo que permite escalar un agente sin que el prompt explote. Es la razón por la que tú no "recuerdas" repitiendo tu vida entera cada mañana.
¿Esto es RAG con otro nombre?
No. Y la diferencia es operativa, no terminológica.
RAG es solo el read path: recuperación semántica. La memoria de tres capas añade el write path — consolidación de hechos y lecciones después de cada sesión — y una capa episódica temporal que RAG no tiene.
Sin write path no hay aprendizaje. Hay búsqueda.
---
El Contraste en Code: Amnesia vs. Arquitectura
Mira la versión ingenua que el 90% de los equipos implementa:
```python
class AgentMemoryNaive:
"""El patrón que garantiza amnesia entre sesiones."""
def __init__(self):
self.messages = [] # append-only. Sin límite. Sin estructura.
def add(self, role: str, content: str):
self.messages.append({"role": role, "content": content})
Cierra la aplicación. Cierra la sesión.
El agente no recuerda NADA mañana.
```
Un append-only a un array. Sin presupuesto de tokens, sin consolidación, sin persistencia, sin esquema. Cuando el historial crece, truncas. Cuando truncas, pierdes. Amnesia por diseño.
Ahora la versión de tres capas:
```python
from dataclasses import dataclass, field
from typing import Optional
@dataclass
class Episode:
episode_id: str
timestamp: str
intention: str # qué quería el usuario
actions: list[str] # qué hizo el agente
outcome: str # qué pasó
lesson: Optional[str] # qué aprender para la próxima
@dataclass
class AgentMemory:
working: list[dict] # ventana deslizante + resumen
working_budget: int # presupuesto de tokens
running_summary: str # resumen compactado
episodic_store: list # SQLite: Episode rows
semantic_index: list # Vector DB: hechos persistentes
```
Tres capas. Tres patrones de vida distinta. Esta es la unidad de diseño — no un único store.
---
Paso 1: Working Memory con Presupuesto de Tokens
La working memory es una ventana deslizante con un presupuesto duro. No crece infinitamente — se recorta con un tope y lo que excede se condensa en un resumen que viaja en el system prompt.
```python
def trim_and_summarize(history: list, budget: int, summarize_fn) -> tuple[list, str]:
"""Recorta el historial al presupuesto y consolida el sobrante en running_summary."""
total = sum(len(m["content"]) for m in history)
if total <= budget:
return history, history[-1].get("summary", "")
Keep the last ~40% as verbatim (recency matters)
cutoff = max(len(history) // 2, min(len(history), 8))
recent = history[-cutoff:]
old = history[:-cutoff]
new_summary = summarize_fn(old, previous_summary=None)
return recent, new_summary
```
El `summarize_fn` es una llamada al LLM: "Condensa estos mensajes en hechos, decisiones y estado pendiente." El resultado se inyecta en el system prompt de cada turno. La working memory nunca explota porque tiene techo.
Paso 2: Long-Term Memory con Write Path
Aquí está la clave que la mayoría se salta. No basta con recuperar. Necesitas escribir.
```python
import chromadb
client = chromadb.PersistentClient(path="./agent_memory")
collection = client.get_or_create_collection("long_term_facts")
def consolidate_facts(conversation: list[dict], extractor_fn, embeddings_fn):
"""Después de cada sesión: extrae hechos, embedéalos y escríbelos."""
facts = extractor_fn(conversation)
for fact in facts:
fact = {"text": "...", "fact_type": "...", "source_session": "...", "confident": 0.9}
embedding = embeddings_fn(fact["text"])
collection.add(
ids=[fact["fact_id"]],
embeddings=[embedding],
metadatas=[{
"fact_type": fact["fact_type"],
"source_session": fact["source_session"],
"confident": fact["confident"],
}],
documents=[fact["text"]],
)
def recall(facts_query: str, k: int = 8, fact_type: str | None = None):
"""El read path: recuperación semántica con filtro por tipo."""
where = {"fact_type": fact_type} if fact_type else None
return collection.query(query_texts=[facts_query], n_results=k, where=where)
```
Sin `consolidate_facts` no eres más que un sistema de búsqueda. El write path — extraer hechos y lecciones, escribirlos de vuelta al store — es lo que convierte un search engine en memoria.
Paso 3: Episodic Memory en SQLite
Los hechos semánticos responden "qué sé". La capa episódica responde "qué pasó". Cada episodio es una fila timestamped con esquema explícito.
```python
import sqlite3
from datetime import datetime, timezone
def init_episodic_store(db_path: str = "./episodic.db"):
conn = sqlite3.connect(db_path)
conn.execute("""
CREATE TABLE IF NOT EXISTS episodes (
episode_id TEXT PRIMARY KEY,
timestamp TEXT NOT NULL,
intention TEXT,
actions TEXT, -- JSON list
outcome TEXT,
lesson TEXT,
situation_embedding BLOB
)
""")
conn.commit()
return conn
def record_episode(conn, episode: Episode, embedding_fn):
ts = datetime.now(timezone.utc).isoformat()
conn.execute(
"INSERT INTO episodes VALUES (?,?,?,?,?,?,?)",
(episode.episode_id, ts, episode.intention,
json.dumps(episode.actions), episode.outcome,
episode.lesson, embedding_fn(episode.intention).tobytes()),
)
conn.commit()
```
La recuperación episódica no es por keywords — es por similitud de situación. Cuando el usuario plantea un problema parecido al de la semana pasada, comparas la intención del episodio actual contra los embeddings de `intention` de episodios anteriores y recuperas el episodio más cercano, con su outcome y su lesson. Eso es lo que evita que el agente repita el error que ya cometió.
Paso 4: Componer el System Prompt con Prioridad
El prompt final inyecta las tres capas ordenadas por prioridad dentro del presupuesto:
```python
def build_system_prompt(agent_identity, recent_turns, episodic_hits, semantic_facts, token_budget):
sections = []
1) Identity y running summary (working memory compactada)
sections.append(f"IDENTIDAD: {agent_identity}")
2) Episodios relevantes (lo que pasó antes en situaciones similares)
if episodic_hits:
sections.append("EPISODIOS RELEVANTES (contexto entre sesiones):")
for ep in episodic_hits:
sections.append(
f"- [{ep['timestamp']}] Intención: {ep['intention']} | "
f"Acciones: {ep['actions']} | Resultado: {ep['outcome']} | "
f"Lección: {ep['lesson']}"
)
3) Hechos semánticos (conocimiento persistente)
if semantic_facts:
sections.append("HECHOS DEL USUARIO (conocimiento a largo plazo):")
for fact in semantic_facts:
sections.append(f"- {fact['text']}")
4) Historial reciente (working memory cruda)
if recent_turns:
sections.append("CONVERSACIÓN RECIENTE:")
for turn in recent_turns:
sections.append(f"{turn['role']}: {turn['content']}")
Recorta si excede el presupuesto
prompt = "\n".join(sections)
if len(prompt) > token_budget * 3.5: # ~3.5 chars/token
prompt = trim_to_budget(prompt, token_budget)
return [{"role": "system", "content": prompt}]
```
El orden importa. Los episodios van antes que los hechos, y los hechos antes que el historial crudo. Lo que persiste entre sesiones tiene prioridad sobre lo que pasó hace cinco turnos.
---
El Test de Persistencia: Mide Tu Propia Amnesia
Sobre el "90%": es una hipótesis editorial. Aún no existe un benchmark público y consolidado de memoria de agentes. Cualquiera que te cite una cifra exacta sin metodología te está vendiendo humo.
Lo que sí puedes hacer es medir tu tasa de amnesia. El test es brutalmente simple:
Paso 1: En la sesión de hoy, haz que el agente "aprenda" tres hechos verificables. "Mi cliente principal se llama Marta. El deadline del proyecto es el martes. La factura mensual debe ir en PDF."
Paso 2: Cierra la aplicación. Espera. Abre una sesión nueva.
Paso 3: Pregunta: "¿Qué hemos acordado hasta ahora? ¿Cuál es el deadline?"
Paso 4: Cuenta cuántos de los tres hechos recupera correctamente. Divide entre tres. Ese es tu recall rate entre sesiones.
Ejecuta este test antes de tocar nada — apuesto a que estás en el 0%. Luego implementa el framework de tres capas y repite. Repite tras cada cambio. Documenta la metodología. Esa cifra medida es la única que vale — y si la publicas, estarás haciendo más por la comunidad que el millonésimo listicle de "10 prompts para ChatGPT".
---
Herramientas y Stack Recomendado
No necesitas inventar nada. El stack existe:
LangGraph Checkpointer / LangMem: si ya usas LangGraph, el checkpointer te da persistencia de estado de grafo entre ejecuciones. LangMem añade memoria auto-gestionada.
Zep o Mem0: plataformas de memoria gestionadas que implementan las tres capas por ti.
pgvector o Chroma: para long-term memory semántica. Si ya usas Postgres, pgvector es la opción limpia.
Redis: working memory con TTL razonable para estado compartido en producción.
SQLite: episodic store. Ligero, transaccional, suficiente para millones de episodios.
LangSmith o un harness propio: para el test de persistencia entre sesiones. No optimices memoria sin medirla.
La Analogía Resend: el Email También se Declaró Resuelto
Hace una década el mercado de APIs de email se declaró "resuelto". SendGrid y Mailgun llevaban años. Y luego llegó Resend y demostró que el diferenciador no era infraestructura — era la experiencia de desarrollador: tiempo hasta el primer email enviado.
En memoria de agentes pasa exactamente igual. Todo el mundo dice "resuelto con contexto o RAG". El diferenciador será la capa de memoria: cuánto tardas en lograr el primer recuerdo útil.
Esa es la métrica que deberías perseguir: TTFU — time-to-first-useful-recall. No "cuántos GB cabe en mi ventana". Sino: cuánto tarda tu agente en recordar un hecho que aprendió ayer y usarlo para tomar una mejor decisión hoy.
La memoria es la capa de plataforma oculta del agente. La deuda de memoria no aparece en el dashboard de tokens ni de latencia — aparece meses después, cuando el agente contradice un hecho aprendido en la sesión 1 o repite el mismo error que ya cometió. Es el riesgo de continuidad de tu producto, y por eso la arquitectura de memoria es una decisión de plataforma, no un detalle de implementación.
---
Resumen: Lo que Te Llevas
1. El buffer lineal es amnesia por diseño. No solo pierde el contexto de ayer — degrada el de hoy por sesgo de recencia.
2. Tres capas, tres vidas distintas. Working memory con presupuesto de tokens, long-term semántica con write path, episodic con esquema timestamped.
3. Sin write path no hay memoria. Recuperación sin consolidación es búsqueda, no aprendizaje.
4. Mide con el test de persistencia. La cifra del 90% es una hipótesis — tu trabajo es convertirla en metodología y publicar la que te salga.
5. TTFU es la métrica de producto. Time-to-first-useful-recall, no tamaño de ventana.
El modelo ya no es el diferenciador. Todos los agentes corren sobre los mismos LLMs. La capa donde se gana o se pierde el producto — la experiencia real del usuario que vuelve mañana y descubre que su agente le recuerda lo que acordaron ayer — es la memoria.
Construye la tuya como lo que es: una plataforma oculta con write path, esquema episódico y un test que mida tu propia tasa de amnesia. El resto es cosmética.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF