Então eu pensei que era hora de documentar como construir memória persistente para agentes de IA usando os bancos de dados que você já conhece. Não bancos de dados vetoriais - MySQL e Neo4j.
Isso não é teórico. Eu uso essa arquitetura diariamente, gerenciando memória de agente de IA em vários projetos. Aqui está o schema e os padrões de query que realmente funcionam.
A Arquitetura
Agentes de IA precisam de dois tipos de memória:
- Memória estruturada - O que aconteceu, quando, por quê (MySQL)
- Memória de padrões - O que se conecta a quê (Neo4j)
Bancos de dados vetoriais são para busca de similaridade. Eles não servem para rastrear estado de workflow ou histórico de decisões. Para isso, você precisa de transações ACID e relacionamentos adequados.
O Schema do MySQL
Aqui está o schema real para memória persistente de agente 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;Chaves estrangeiras. Restrições de verificação. Indexação adequada. É isso que bancos de dados relacionais fazem bem.
Padrões de Query
Aqui está como você realmente faz query nisso para memória de agente 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;Essas são queries SQL diretas. EXPLAIN mostra uso de índices exatamente onde esperado. Sem surpresas.
A Camada Neo4j
MySQL lida com os dados estruturados. Neo4j lida com os relacionamentos:
// 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_rateComo Eles Funcionam Juntos
O fluxo é assim:
- O agente de IA gera conteúdo ou toma uma decisão
- Armazena dados estruturados no MySQL (o quê, quando, por quê, contexto completo)
- Gera embedding, armazena no Neo4j com relacionamentos para itens similares
- Próxima sessão: Neo4j encontra decisões similares relevantes
- MySQL fornece os detalhes completos dessas decisões
MySQL é a fonte da verdade. Neo4j é o descobridor de padrões.
Por Que Não Apenas Bancos de Dados Vetoriais?
Eu vi equipes tentarem construir memória de agente de IA apenas com Pinecone ou Weaviate. Não funciona bem porque:
Bancos de dados vetoriais são bons para:
- Encontrar documentos similares a uma query
- Busca semântica (RAG)
- "Coisas como esta"
Bancos de dados vetoriais são ruins para:
- "O que decidimos em 15 de março?"
- "Mostre decisões que levaram a quedas"
- "Qual é o status atual deste workflow?"
- "Quais padrões têm confidence > 0.8 AND usage_count > 10?"
Essas queries precisam de filtragem estruturada, joins e transações. Isso é território de banco de dados relacional.
MCP e o Futuro
O Model Context Protocol (MCP) está padronizando como sistemas de IA lidam com contexto. Implementações iniciais de MCP estão descobrindo o que já sabíamos: você precisa de armazenamento estruturado e relacionamentos de grafo.
``````htmlMySQL lida com o catálogo de "resources" e "tools" do MCP. Neo4j lida com as "relationships" entre itens de contexto. Embeddings vetoriais são apenas uma peça do quebra-cabeça.
Notas de Produção
Sistema atual executando esta arquitetura:
- 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
A complexidade operacional é baixa porque são bancos de dados maduros com padrões operacionais bem compreendidos.
Quando Usar Cada Um
| Use Case | Database |
|---|---|
| Workflow state, decisions, audit trail | MySQL/PostgreSQL |
| Pattern detection, similarity, relationships | Neo4j |
| Semantic document search (RAG) | Vector DB (optional) |
Comece com MySQL para estado. Adicione Neo4j quando precisar de reconhecimento de padrões. Só adicione vector DBs se você realmente estiver fazendo recuperação semântica de documentos.
Resumo
Agentes de IA precisam de memória persistente. Não apenas embeddings em um vector database - memória estruturada, relacional, temporal com reconhecimento de padrões.
MySQL lida com o estado estruturado. Neo4j lida com as relações de grafo. Juntos, eles fornecem o que vector databases sozinhos não podem.
Não abandone bancos de dados relacionais para cargas de trabalho de IA. Use a ferramenta certa para cada trabalho, que é usar ambos juntos.
Para mais sobre a perspectiva do agente de IA nesta arquitetura, veja o post complementar em 3k1o.
