Así que pensé que era hora de documentar cómo construir memoria persistente para agentes de IA usando las bases de datos que ya conoces. No bases de datos vectoriales - MySQL y Neo4j.
Esto no es teórico. Uso esta arquitectura diariamente, manejando la memoria de agentes de IA en múltiples proyectos. Aquí está el esquema y los patrones de consultas que realmente funcionan.
La Arquitectura
Los agentes de IA necesitan dos tipos de memoria:
- Memoria estructurada - Qué pasó, cuándo, por qué (MySQL)
- Memoria de patrones - Qué se conecta con qué (Neo4j)
Las bases de datos vectoriales son para búsqueda de similitud. No son para rastrear el estado del flujo de trabajo o el historial de decisiones. Para eso, necesitas transacciones ACID y relaciones adecuadas.
El Esquema de MySQL
Aquí está el esquema real para la memoria persistente de agentes de IA:
-- Architecture decisions the AI made
CREATE TABLE architecture_decisions (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
title VARCHAR(255) NOT NULL,
decision TEXT NOT NULL,
rationale TEXT,
alternatives_considered TEXT,
status ENUM('accepted', 'rejected', 'pending') DEFAULT 'accepted',
decided_at DATETIME DEFAULT CURRENT_TIMESTAMP,
tags JSON,
INDEX idx_project_date (project_id, decided_at),
INDEX idx_status (status)
) ENGINE=InnoDB;
-- Code patterns the AI learned
CREATE TABLE code_patterns (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
category VARCHAR(50) NOT NULL,
name VARCHAR(255) NOT NULL,
description TEXT,
code_example TEXT,
language VARCHAR(50),
confidence_score FLOAT DEFAULT 0.5,
usage_count INT DEFAULT 0,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_project_category (project_id, category),
INDEX idx_confidence (confidence_score)
) ENGINE=InnoDB;
-- Work session tracking
CREATE TABLE work_sessions (
id INT AUTO_INCREMENT PRIMARY KEY,
session_id VARCHAR(255) UNIQUE NOT NULL,
project_id INT NOT NULL,
started_at DATETIME DEFAULT CURRENT_TIMESTAMP,
ended_at DATETIME,
summary TEXT,
context JSON,
INDEX idx_project_session (project_id, started_at)
) ENGINE=InnoDB;
-- Pitfalls to avoid (learned from mistakes)
CREATE TABLE pitfalls (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
category VARCHAR(50),
title VARCHAR(255) NOT NULL,
description TEXT,
how_to_avoid TEXT,
severity ENUM('critical', 'high', 'medium', 'low'),
encountered_count INT DEFAULT 1,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_project_severity (project_id, severity)
) ENGINE=InnoDB;Claves foráneas. Restricciones de verificación. Indexación adecuada. Esto es lo que las bases de datos relacionales hacen bien.
Patrones de Consultas
Aquí está cómo realmente consultas esto para la memoria de agentes de IA:
-- Get recent decisions for context
SELECT title, decision, rationale, decided_at
FROM architecture_decisions
WHERE project_id = ?
AND decided_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY decided_at DESC
LIMIT 10;
-- Find high-confidence patterns
SELECT category, name, description, code_example
FROM code_patterns
WHERE project_id = ?
AND confidence_score >= 0.80
ORDER BY usage_count DESC, confidence_score DESC
LIMIT 20;
-- Check for known pitfalls before implementing
SELECT title, description, how_to_avoid
FROM pitfalls
WHERE project_id = ?
AND category = ?
AND severity IN ('critical', 'high')
ORDER BY encountered_count DESC;
-- Track session context across interactions
SELECT context
FROM work_sessions
WHERE session_id = ?
ORDER BY started_at DESC
LIMIT 1;Estas son consultas SQL sencillas. EXPLAIN muestra el uso de índices exactamente donde se espera. Sin sorpresas.
La Capa de Neo4j
MySQL maneja los datos estructurados. Neo4j maneja las relaciones:
// Create nodes for decisions
CREATE (d:Decision {
id: 'dec_123',
title: 'Use FastAPI',
project_id: 1,
embedding: [0.23, -0.45, ...] // Vector for similarity
})
// Create relationships
CREATE (d1:Decision {id: 'dec_123', title: 'Use FastAPI'})
CREATE (d2:Decision {id: 'dec_45', title: 'Used Flask before'})
CREATE (d1)-[:SIMILAR_TO {score: 0.85}]->(d2)
CREATE (d1)-[:CONTRADICTS]->(d3:Decision {title: 'Avoid frameworks'})
// Query: Find similar past decisions
MATCH (current:Decision {id: $decision_id})
MATCH (current)-[r:SIMILAR_TO]-(similar:Decision)
WHERE r.score > 0.80
RETURN similar.title, r.score
ORDER BY r.score DESC
// Query: What outcomes followed this pattern?
MATCH (d:Decision)-[:LEADS_TO]->(o:Outcome)
WHERE d.title CONTAINS 'Redis'
RETURN d.title, o.type, o.success_rateCómo Funcionan Juntos
El flujo se ve así:
- El agente de IA genera contenido o toma una decisión
- Almacena datos estructurados en MySQL (qué, cuándo, por qué, contexto completo)
- Genera embedding, almacena en Neo4j con relaciones a elementos similares
- Siguiente sesión: Neo4j encuentra decisiones similares relevantes
- MySQL proporciona los detalles completos de esas decisiones
MySQL es la fuente de verdad. Neo4j es el buscador de patrones.
¿Por Qué No Solo Bases de Datos Vectoriales?
He visto equipos intentar construir memoria de agentes de IA solo con Pinecone o Weaviate. No funciona bien porque:
Las bases de datos vectoriales son buenas para:
- Encontrar documentos similares a una consulta
- Búsqueda semántica (RAG)
- "Cosas como esta"
Las bases de datos vectoriales son malas para:
- "¿Qué decidimos el 15 de marzo?"
- "Muéstrame decisiones que llevaron a interrupciones"
- "¿Cuál es el estado actual de este flujo de trabajo?"
- "¿Qué patrones tienen confianza > 0.8 AND usage_count > 10?"
Esas consultas necesitan filtrado estructurado, uniones y transacciones. Ese es el territorio de las bases de datos relacionales.
MCP y el Futuro
El Protocolo de Contexto de Modelo (MCP) está estandarizando cómo los sistemas de IA manejan el contexto. Las implementaciones tempranas de MCP están descubriendo lo que ya sabíamos: necesitas tanto almacenamiento estructurado como relaciones de grafo.
``````htmlMySQL maneja el catálogo de "resources" y "tools" de MCP. Neo4j maneja las "relationships" entre elementos de contexto. Los vector embeddings son solo una pieza del rompecabezas.
Notas de Producción
Sistema actual ejecutando esta arquitectura:
- MySQL 8.0, 48 tables, ~2GB data
- Neo4j Community, ~50k nodes, ~200k relationships
- Query latency: MySQL <10ms, Neo4j <50ms
- Backup: Standard mysqldump + neo4j-admin dump
- Monitoring: Same Percona tools I've used for years
La complejidad operativa es baja porque son bases de datos maduras con patrones operativos bien comprendidos.
Cuándo Usar Qué
| Use Case | Database |
|---|---|
| Workflow state, decisions, audit trail | MySQL/PostgreSQL |
| Pattern detection, similarity, relationships | Neo4j |
| Semantic document search (RAG) | Vector DB (optional) |
Comienza con MySQL para el estado. Agrega Neo4j cuando necesites reconocimiento de patrones. Solo agrega vector DBs si realmente estás haciendo recuperación semántica de documentos.
Resumen
Los agentes de IA necesitan memoria persistente. No solo embeddings en una vector database - memoria estructurada, relacional, temporal con reconocimiento de patrones.
MySQL maneja el estado estructurado. Neo4j maneja las relaciones de grafo. Juntos proporcionan lo que las vector databases solas no pueden.
No abandones las bases de datos relacionales para cargas de trabajo de IA. Usa la herramienta correcta para cada trabajo, que es usar ambas juntas.
Para más sobre la perspectiva de los agentes de IA en esta arquitectura, vea la publicación complementaria en 3k1o.
