Memoria persistente para agentes IA: cómo guardar contexto

Por qué tu agente IA olvida todo al día siguiente

Para que un agente IA recuerde quién es el cliente, qué acordaron en la conversación anterior y cuál es el estado del proceso, necesita un sistema de memoria externa que persista entre ejecuciones. Sin ello, cada conversación empieza desde cero.

La mayoría de implementaciones de agentes en producción fallan en este punto: el agente hace bien su tarea en la sesión actual, pero al día siguiente no recuerda nada. El contexto se pierde, el usuario tiene que repetir información, y el agente pierde toda la inteligencia acumulada.

Esta guía muestra cómo implementarlo, qué arquitectura funciona en producción y qué evitar.

Requisitos previos

• Agente IA funcionando (Claude, GPT-4o, Gemini o similar)
• Acceso a una base de datos (PostgreSQL, Redis o archivo JSON estructurado)
• Node.js 18+ o Python 3.10+
• Opcionalmente: un vector store (pgvector, Chroma, Pinecone)

Por qué la ventana de contexto no es suficiente

Los modelos de lenguaje tienen una ventana de contexto: el conjunto de tokens que pueden "ver" en una sola llamada. Claude 3.7 tiene 200k tokens, GPT-4o tiene 128k. Parece mucho, pero en producción se acaba rápido:

• Historial de un cliente con 50 interacciones: ~30k tokens
• Base de conocimiento del negocio: ~40k tokens
• Instrucciones del sistema y herramientas: ~10k tokens

La solución no es una ventana más grande. Es memoria selectiva: el agente recupera solo lo relevante para la conversación actual.

Las tres capas de memoria de un agente IA

Una arquitectura robusta tiene tres capas:

Memoria de trabajo (in-context): lo que el agente necesita ahora mismo. Duración: la sesión actual.

Memoria episódica (externa estructurada): hechos concretos sobre el usuario o cliente guardados en una base de datos. Por ejemplo: "Juan Perez firmó contrato en marzo, producto: Plan Empresarial, renovación: septiembre."

Memoria semántica (vectorial): documentación e historial en lenguaje natural. El agente busca por similitud semántica, no por ID.

Para el 80% de los casos de negocio, con la capa episódica es suficiente.

Implementar memoria episódica en PostgreSQL

Crea una tabla simple:

CREATE TABLE agent_memory (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  entity_id TEXT NOT NULL,
  entity_type TEXT NOT NULL,
  key TEXT NOT NULL,
  value TEXT NOT NULL,
  confidence FLOAT DEFAULT 1.0,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE UNIQUE INDEX ON agent_memory(entity_id, key);

Luego, dos herramientas que el agente llama durante la conversación:

// tools/memory.ts
export async function rememberFact(
  entityId: string,
  key: string,
  value: string
): Promise<void> {
  await db.query(#43a047">`
    INSERT INTO agent_memory (entity_id, entity_type, key, value)
    VALUES ($1, 'contact', $2, $3)
    ON CONFLICT (entity_id, key)
    DO UPDATE SET value = $3, updated_at = NOW()
  `, [entityId, key, value]);
}

export async function recallFacts(
  entityId: string
): Promise<Record<string, string>> {
  const rows = await db.query(
    #43a047">`SELECT key, value FROM agent_memory WHERE entity_id = $1`,
    [entityId]
  );
  return Object.fromEntries(rows.map(r => [r.key, r.value]));
}

El sistema prompt le indica al agente cuándo usarlas:

const systemPrompt = #43a047">`
Eres un agente de ventas para Empresa X.
Al inicio de cada conversación, llama a recallFacts(contactId) para recuperar contexto.
Si el cliente menciona algo nuevo (empresa, cargo, problema, interés), llama a rememberFact.
`;

Cuándo agregar memoria vectorial

Añade un vector store cuando:

• Tienes documentación extensa que el agente debe consultar (manuales, FAQs, contratos)
• El historial de conversaciones supera 100 mensajes por cliente
• Necesitas recuperar información por similitud semántica, no por ID exacto

Con pgvector (extensión de PostgreSQL) puedes añadir esta capacidad sin agregar otra base de datos:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE agent_knowledge (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  content TEXT NOT NULL,
  embedding vector(1536),
  source TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

La búsqueda semántica queda así:

SELECT content, source,
  1 - (embedding <=> $1::vector) AS similarity
FROM agent_knowledge
WHERE 1 - (embedding <=> $1::vector) > 0.75
ORDER BY similarity DESC
LIMIT 5;

Arquitectura del sistema

Usuario / WhatsApp / Email
          |
        Agente IA
       /          \
recallFacts()   searchKnowledge()
      |                |
 PostgreSQL       pgvector / Chroma
 (hechos clave)   (docs, FAQs, historial)
       \          /
    Contexto ensamblado
          |
       Respuesta

El agente construye su contexto dinámicamente en cada llamada: recupera los hechos clave del cliente, busca documentos relevantes si los hay, y los suma al prompt antes de responder. La ventana de contexto se usa de forma eficiente.

Lo que aprendimos en producción

Las claves tienen que ser canónicas. Usa nombres fijos (plan, pain_point, last_call_date) en vez de dejar que el modelo los invente. Si el agente guarda ultimo_contacto una vez y fecha_ultima_llamada la siguiente, nunca recupera nada de forma consistente.

Confianza es distinto a exactitud. Un confidence: 0.7 en un hecho indica que fue inferido, no declarado. El agente debe verificarlo antes de actuar sobre él.

No guardes transcripts, extrae hechos. Una conversación de 2.000 palabras se convierte en 5-8 hechos clave. El transcript completo envenena el contexto con ruido.

Los datos caducan. Un lead calificado como "muy interesado" hace seis meses puede ya no serlo. Agrega expires_at a hechos temporales y deja que el agente los marque como obsoletos.

Versiona la memoria desde el día uno. Antes de sobrescribir un hecho, guarda el valor anterior en una tabla agent_memory_history. Es imprescindible para auditoría y para detectar cambios en el comportamiento de un cliente.

En resumen

• La memoria persistente es lo que convierte un agente desechable en un agente que aprende
• Arquitectura mínima viable: PostgreSQL con clave-valor + dos herramientas (recallFacts, rememberFact)
• Añadir vector store solo si tienes documentación extensa o historial largo
• Las claves de memoria deben ser canónicas y definidas por el desarrollador, no generadas por el modelo
• Versionar la memoria con historial desde el primer día de producción

Si quieres implementar esto en tu negocio sin construirlo desde cero, en AgentesNexo lo hacemos por ti. Escríbenos en agentesnexo.com o por WhatsApp al +591 67564218