Memoria de agentes de IA: ¿Graphiti, RAG vectorial o PostgreSQL?

La misma palabra, "memoria", suele esconder tres problemas distintos. Un agente necesita saber qué registro es verdadero, encontrar texto parecido a la pregunta y entender que una relación cambió desde la última conversación. Meterlo todo en embeddings solo resuelve una parte.

Para elegir entre Graphiti, RAG vectorial y PostgreSQL, separa la fuente de verdad del índice de recuperación y de la representación de relaciones. En la práctica, la arquitectura más fácil de operar empieza con la base de datos que ya puedes auditar. Añade un grafo solo cuando la consulta dependa de tiempo, relaciones o historial.

Si tu duda sigue siendo cómo encuentra el agente archivos y símbolos, consulta el artículo sobre RAG de codebase para agentes de código. Si el problema es la memoria temporal, el texto anterior sobre Graphiti y la memoria a largo plazo explica el concepto antes de esta comparación.

Decisión rápida

• Usa PostgreSQL para hechos relacionales, estado actual, permisos y auditoría.
• Usa RAG vectorial cuando la pregunta necesite contenido semánticamente parecido.
• Usa Graphiti cuando las entidades y relaciones cambien y el historial forme parte de la respuesta.
• Combina las capas sin dejar que el índice de recuperación se convierta en la fuente de verdad.

¿Qué guarda realmente cada opción?

En 2026, la documentación oficial de Graphiti describe un grafo temporal con entidades, relaciones, hechos y episodios de origen (Graphiti, "Overview", consultado el 30/07/2026). PostgreSQL guarda filas y relaciones explícitas. El RAG vectorial guarda representaciones para encontrar similitud. La elección depende del tipo de pregunta que el agente deba responder.

El error habitual es preguntar qué herramienta tiene la mejor memoria. La pregunta útil es qué estructura conserva la evidencia que tendrás que revisar después. Un ticket puede vivir en PostgreSQL, tener un embedding para búsqueda y aparecer en el grafo como una relación entre servicio, decisión e incidente. Ninguna capa necesita fingir que hace el trabajo de otra.

¿Cuándo debe PostgreSQL ser la memoria del agente?

En 2026, PostgreSQL debe ser la memoria principal cuando el sistema necesite transacciones, filtros de permisos, estado actual e historial que otra persona pueda inspeccionar con SQL. La documentación oficial separa tsvector y tsquery para la búsqueda textual, mientras el modelo relacional mantiene la regla de negocio (PostgreSQL, "Full Text Search", consultado el 30/07/2026).

Este camino funciona para agentes de soporte, operaciones y coding agents que necesitan leer tareas, decisiones, aprobaciones o resultados de pruebas. La fila de la base se convierte en el contrato. El agente recibe una proyección corta, mientras la aplicación puede abrir el registro completo cuando necesite investigar.

CREATE TABLE agent_memory (
  id uuid PRIMARY KEY,
  subject_id text NOT NULL,
  kind text NOT NULL,
  content jsonb NOT NULL,
  source_uri text NOT NULL,
  valid_from timestamptz NOT NULL,
  valid_until timestamptz,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX agent_memory_subject_idx
  ON agent_memory (subject_id, kind, valid_until);

El campo source_uri evita que una frase huérfana se convierta en verdad solo porque el modelo la recuperó. valid_until permite retirar un hecho sin borrar el historial. La aplicación aún decide si los registros en conflicto se rechazan, se versionan o se envían a revisión humana.

Usa full-text search para términos, nombres de servicios, identificadores y decisiones que dependan de coincidencia léxica. Si la pregunta es "¿qué migration creó la columna status?", la búsqueda textual y los metadatos de la base suelen ser más útiles que una similitud aproximada.

Cuando la recuperación deba llegar al agente mediante herramientas estrechas, el artículo sobre RAG de codebase con MCP muestra una frontera parecida entre búsqueda bajo demanda y contexto cargado.

Cápsula citable: PostgreSQL es una buena fuente de verdad para la memoria de agentes cuando el sistema necesita transacciones, permisos, estado actual y procedencia auditable. La búsqueda textual puede localizar términos e identificadores, pero las decisiones sobre validez, conflictos y acceso permanecen en el modelo relacional, fuera del prompt del agente.

¿Cuándo basta con RAG vectorial?

En 2026, el RAG vectorial basta cuando la tarea consiste en recuperar fragmentos semánticamente cercanos y la validez puede controlarse durante la ingesta. El README de pgvector documenta búsqueda exacta, índices aproximados HNSW e IVFFlat y la combinación con full-text search de PostgreSQL (pgvector, "README", consultado el 30/07/2026).

Esta opción funciona bien para documentación, runbooks, decisiones de arquitectura y ejemplos de código que no necesitan una red de relaciones para entenderse. El agente pregunta, la aplicación recupera candidatos y el modelo recibe fragmentos con identificador y fuente.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory_chunks (
  id bigserial PRIMARY KEY,
  source_uri text NOT NULL,
  content text NOT NULL,
  embedding vector NOT NULL,
  updated_at timestamptz NOT NULL
);

CREATE INDEX memory_chunks_embedding_idx
  ON memory_chunks USING hnsw (embedding vector_cosine_ops);

La dimensión del vector del ejemplo queda como decisión de la migración. Si fijas una dimensión, comprueba el valor que produce tu proveedor antes de crear el índice. El índice mejora la recuperación, pero no sabe si el texto sigue siendo válido, si el usuario tiene permiso o si un documento nuevo lo reemplazó.

Por eso, filtra por alcance antes de construir el contexto. Comprueba subject_id, repositorio, entorno, clasificación y fecha. Después combina la búsqueda semántica con términos exactos cuando la pregunta contenga nombres de archivos, incidentes, clases o identificadores de API.

Cuando un agente atraviesa muchas sesiones y solo necesita la evidencia relevante, RemoteCode ayuda a Claude Code y Codex a continuar flujos agentic con menos contexto repetido. Es una herramienta del propio autor y se menciona aquí como opción para reducir el contexto reenviado. No sustituye la base de datos, la autorización ni la verificación de memoria.

Cápsula citable: El RAG vectorial recupera contenido parecido, no gobierna la memoria. pgvector puede combinar búsqueda vectorial con full-text search de PostgreSQL, pero la aplicación aún debe filtrar el acceso, registrar la fuente, controlar las actualizaciones e impedir que un fragmento antiguo se presente como estado actual.

¿Cuándo compensa la complejidad de Graphiti?

En 2026, Graphiti compensa la complejidad cuando la respuesta depende de relaciones que cambian y de consultas en un momento concreto. Su documentación oficial describe ingesta incremental por episodios, procedencia, invalidación temporal de hechos y búsqueda híbrida semántica, textual y de grafo (Graphiti, "Overview", consultado el 30/07/2026).

Imagina un agente que debe responder qué servicio dependía de una cola antes de una migración, qué decisión sustituyó a otra o quién aprobó una excepción mientras seguía vigente. Un vector puede encontrar documentos relacionados. Un grafo puede representar la relación y su ciclo de vida, siempre que el modelo de datos y la ingesta sean correctos.

En 2026, Graphiti no es un atajo para meter una codebase completa en un grafo. El proyecto oficial requiere una base de grafos compatible y un proveedor de LLM para extracción y embeddings (Graphiti, "README", consultado el 30/07/2026). Eso añade más cosas que configurar, observar y probar.

Usa un grafo cuando la relación forme parte de la consulta, no solo de la imagen. Si la pregunta es "¿qué documento menciona un timeout?", empieza con texto o vectores. Si es "¿qué servicio dependía de esta cola cuando se tomó la decisión?", las relaciones temporales pueden justificar Graphiti.

Cápsula citable: Graphiti es una opción de memoria temporal para agentes cuando las entidades, relaciones y hechos cambian con el tiempo. El framework registra episodios de origen y ofrece recuperación híbrida, pero requiere un backend de grafos y una política clara para extracción, invalidación, permisos y observabilidad.

Una arquitectura híbrida separa verdad, búsqueda y relaciones

Una arquitectura híbrida mantiene una fuente de verdad y crea índices derivados para preguntas diferentes. El registro transaccional permanece en PostgreSQL. El embedding apunta a fragmentos recuperables. El grafo representa relaciones temporales cuando el dominio las necesita. La respuesta del agente lleva referencias a esas capas, en lugar de llevar solo texto suelto.

type MemoryEvidence = {
  id: string;
  sourceUri: string;
  text: string;
  validFrom: string;
  validUntil: string | null;
  score?: number;
};

type MemoryProvider = {
  search(input: {
    subjectId: string;
    query: string;
    at?: string;
  }): Promise<MemoryEvidence[]>;
  record(input: {
    subjectId: string;
    sourceUri: string;
    content: string;
  }): Promise<{ id: string }>;
};

El contrato no revela qué base respondió. Exige que cada resultado tenga identificador, fuente y validez. La implementación puede consultar SQL primero, usar búsqueda híbrida después y llamar a Graphiti solo cuando la pregunta pida una relación o un historial.

El supervisor también debe distinguir lectura y escritura. Una herramienta de búsqueda puede devolver evidencia. Una herramienta de escritura debe validar el contenido, exigir sourceUri, registrar quién pidió el cambio e impedir que la salida del modelo sustituya un hecho sin aprobación.

Cápsula citable: Una arquitectura híbrida de memoria mantiene PostgreSQL como fuente de verdad, usa RAG vectorial para localizar contenido y reserva Graphiti para relaciones temporales. El agente no necesita saber qué capa respondió, pero debe recibir evidencia con identificador, origen y validez para que la aplicación pueda verificar el contexto.

¿Cómo verificar la memoria antes de llamar al modelo?

Verifica la memoria en dos pasos: la aplicación comprueba primero alcance, validez y origen; después el agente recibe solo resultados que se pueden citar. Esta separación reduce el riesgo de que un texto plausible domine el contexto. La respuesta debe permitir que una prueba reproduzca la consulta e inspeccione el registro utilizado.

Usa esta lista en el camino de recuperación:

1. Normaliza el identificador del sujeto, repositorio o tenant.
2. Limita la consulta a las fuentes que la ejecución puede leer.
3. Elimina hechos cuya validez terminó, salvo que la pregunta pida historial.
4. Recupera candidatos por texto, vector o relación temporal.
5. Añade sourceUri, identificador y fechas de validez a cada evidencia.
6. Rechaza respuestas sin evidencia o marca la salida como no verificada.

La prueba no debe preguntar solo si el modelo respondió. Tiene que confirmar que un cambio de estado retira el hecho antiguo, que una fuente sin permiso nunca aparece y que una pregunta histórica encuentra la versión correcta. Para coding agents, registra también el commit, el archivo o la decisión arquitectónica utilizados.

Cuando la recuperación falla, no aumentes el límite de contexto por reflejo. Primero descubre si falta una fuente, si un filtro descartó el resultado correcto o si el índice devolvió un fragmento parecido. Cada caso apunta a una corrección distinta: ingesta, autorización, consulta o ranking.

Este diagnóstico también se aplica al presupuesto de contexto para agentes de código: medir lo que entra en el prompt ayuda a separar memoria insuficiente de exceso de contexto.

Errores habituales y límites de la comparación

El primer error es convertir Graphiti en requisito de cualquier agente. Un agente pequeño puede funcionar mejor con una tabla, búsqueda textual y metadatos. Un grafo aporta valor cuando la relación cambia y hay que consultarla, no cuando el diagrama parece más sofisticado.

El segundo error es tratar los embeddings como memoria canónica. Los embeddings son índices derivados. Necesitan actualización, borrado, alcance y reprocesamiento. Si un documento se revoca, el agente no debería seguir citando un vector antiguo porque la búsqueda semántica aún encuentra una frase parecida.

El tercer error es mezclar pasado y presente en la misma respuesta. La imagen de este artículo resume la regla: un hecho nuevo puede invalidar uno antiguo sin borrar su origen. Cuando la pregunta no incluye un momento, define una política explícita que prefiera el estado actual.

El cuarto error es esconder las escrituras de memoria dentro de una herramienta genérica. Separa search de record, valida los argumentos y registra la decisión. Una escritura incorrecta es más difícil de reparar que una búsqueda incompleta porque contamina las consultas siguientes.

También importan los límites. La documentación de los proyectos describe capacidades y ejemplos, pero sus benchmarks no representan automáticamente tu dominio. Mide recall, precisión, tiempo de recuperación, coste de ingesta, volumen de contexto y tasa de hechos obsoletos con preguntas de tu sistema.

Preguntas frecuentes sobre memoria de agentes de IA

¿Graphiti sustituye una base de datos vectorial?

No necesariamente. Graphiti ofrece recuperación híbrida de relaciones, texto y semántica, pero la fuente de verdad del producto puede seguir en PostgreSQL. El proyecto oficial describe Graphiti como un motor de grafos temporales y requiere un backend compatible. Elígelo cuando el historial relacional forme parte de la pregunta, no solo porque el agente necesite memoria.

¿PostgreSQL basta para la memoria persistente de un agente?

Para muchos sistemas, sí. PostgreSQL cubre estado, transacciones, permisos, auditoría y búsqueda textual. Con pgvector también puede mantener embeddings y búsqueda semántica. Deja de ser suficiente cuando las consultas dependen de muchas relaciones temporales que serían artificiales en tablas. Incluso entonces, puede seguir siendo la fuente de verdad.

¿El RAG vectorial evita el contexto obsoleto?

No por sí solo. La búsqueda vectorial encuentra contenido parecido, pero no sabe si una fuente fue revocada, sustituida o bloqueada para un usuario. Guarda origen y validez, filtra antes de construir el prompt y prueba cambios de estado. Si la aplicación necesita historial, recupera la versión correcta en lugar de confiar en el fragmento más cercano.

¿Debería exponer la memoria del agente mediante MCP?

MCP puede ser una frontera útil para herramientas de búsqueda y registro, pero no debe decidir qué datos son verdaderos. Valida la entrada en el servidor, separa lectura y escritura y devuelve evidencia estructurada. El agente puede pedir contexto mediante una herramienta mientras PostgreSQL, Graphiti u otro backend aplican autorización y política de actualización.

Fuentes consultadas

• Graphiti, "Overview", consultado el 30/07/2026
• Graphiti, repositorio oficial, consultado el 30/07/2026
• pgvector, README oficial, consultado el 30/07/2026
• PostgreSQL, "Full Text Search", consultado el 30/07/2026