Diseño de arquitectura para escalar un segundo cerebro personal a un sistema de producción con AWS serverless — desde el prototipo actual hasta casos de uso especializados en legal, investigación y comunidad.
En «Construyendo un segundo cerebro en público» documenté cómo un fin de semana de marzo de 2026 se convirtió en un sistema de conocimiento con más de 150 nodos, 450+ aristas y ~200,000 palabras bilingües. El prototipo corre en Vercel — deploy instantáneo, SSL automático, CDN global. Para un sitio estático con contenido MDX, es perfecto.
Pero el prototipo tiene límites claros. La captura requiere crear archivos MDX con 11 campos de frontmatter y hacer commit — 15 a 30 minutos por concepto. Los agentes de IA pueden leer el grafo completo vía MCP, pero no pueden escribir en él. El surfacing proactivo se limita a un agente QA semanal que detecta problemas de calidad, no contenido relevante para el usuario. Y la búsqueda semántica falló en producción por el peso del modelo WASM en el navegador.
Estos no son bugs — son las fronteras naturales de un sistema estático. Cruzarlas requiere backend stateful. Y como ingeniero que ha construido sistemas de producción en AWS serverless durante años, esa suite es donde tengo más experiencia, más control y — siendo honesto — más curiosidad por explorar los límites.
Este ensayo no es un tutorial de despliegue. Es el diseño de arquitectura para llevar un segundo cerebro personal a producción — y la exploración de qué pasa cuando ese diseño se aplica a dominios especializados donde el conocimiento estructurado tiene valor real.
El principio que funcionó en el prototipo — separar memoria, cómputo e interfaz — se mantiene. Lo que cambia es que cada capa gana capacidades que el sistema estático no puede ofrecer.
DynamoDB almacena los metadatos estructurados — el equivalente del frontmatter MDX actual más las aristas del grafo y los vectores de embeddings. La tabla principal usa un diseño de tabla única:
| PK | SK | Datos |
|---|---|---|
NODE#serverless | META | Tipo, status, títulos, summaries, tags, timestamps |
NODE#serverless | EDGE#aws-lambda | Tipo de relación, peso, dirección |
NODE#serverless | EDGE#aws-api-gateway | Tipo de relación, peso, dirección |
NODE#serverless | EMBED | Vector de 1,024 dimensiones (Titan Text Embeddings V2) |
AUDIT#2026-03-19T10:30:00Z | NODE#serverless | Acción, autor, diff |
Un GSI invierte PK/SK para consultas inversas: «¿qué nodos apuntan a serverless?». Otro GSI proyecta status para consultas como «todos los seeds sin actualizar en 7 días».
S3 almacena el contenido largo — el cuerpo MDX en español e inglés. DynamoDB tiene un límite de 400KB por item; un concepto evergreen con 1,500 palabras bilingües cabe, pero separar contenido de metadatos mantiene las consultas de grafo rápidas y baratas.
¿Por qué no Aurora Serverless con Postgres? Tres razones:
Cada función Lambda tiene una responsabilidad única:
Estas funciones Lambda sirven como tools tanto para la API REST (consumida por el SPA) como para AgentCore Gateway, que las expone automáticamente como tools MCP — read_node, add_node, connect_nodes, search, flag_stale — sin código de protocolo adicional. Cualquier cliente de IA compatible con MCP puede descubrir e invocar estos tools a través de Gateway.
AgentCore Runtime hospeda el agente de IA en microVMs con aislamiento de sesión. El agente razona con Bedrock Claude e invoca los tools registrados en Gateway para interactuar con el grafo.
Step Functions orquesta los flujos que involucran múltiples pasos — por ejemplo, el pipeline de captura completo: validar input → generar metadatos con Bedrock → computar embeddings → persistir → notificar. Si Bedrock falla por throttling, Step Functions reintenta con backoff exponencial sin código custom.
CloudFront sirve el frontend estático desde S3 — el mismo Next.js exportado que corre hoy en Vercel, pero con control total sobre headers, cache y edge functions. API Gateway REST expone los endpoints de cómputo para el SPA con throttling, API keys y autorización IAM. AgentCore Gateway expone las mismas funciones Lambda como tools MCP con autenticación OAuth, descubrimiento semántico de tools, y traducción automática de protocolo.
Las «dos puertas» — una interfaz para humanos y otra para agentes de IA — se materializan:
La pregunta que todo arquitecto serverless debe responder: ¿cuánto cuesta en reposo y bajo carga?
| Servicio | Reposo (0 req/día) | Uso moderado (100 req/día) | Uso alto (1,000 req/día) |
|---|---|---|---|
| DynamoDB on-demand | $0.00 | ~$0.25 | ~$2.50 |
| Lambda | $0.00 | ~$0.01 | ~$0.10 |
| API Gateway | $0.00 | ~$0.04 | ~$0.35 |
| S3 + CloudFront | ~$0.50 | ~$0.60 | ~$1.00 |
| Bedrock (embeddings) | $0.00 | ~$0.50 | ~$2.00 |
| Bedrock (chat/agent) | $0.00 | ~$1.00 | ~$5.00 |
| EventBridge + SNS | ~$0.01 | ~$0.01 | ~$0.01 |
| Step Functions | $0.00 | ~$0.03 | ~$0.25 |
| Total | ~$0.51 | ~$2.44 | ~$11.21 |
En reposo, el sistema cuesta menos que un café. Bajo uso moderado — el patrón de un segundo cerebro personal — menos de $3/mes. Incluso bajo carga alta, se mantiene por debajo de $12/mes. Estimaciones basadas en precios de AWS para us-east-1, marzo 2026.
La clave es que serverless escala a cero. No hay servidores encendidos esperando requests. No hay bases de datos con mínimos de capacidad. Cada centavo corresponde a trabajo real.
Toda la infraestructura se define con Terraform — el mismo enfoque que ya gestiona la IAM del proyecto actual. Un solo terraform apply levanta el sistema completo:
resource "aws_dynamodb_table" "knowledge_graph" {
name = "SecondBrain-KnowledgeGraph"
billing_mode = "PAY_PER_REQUEST"
hash_key = "PK"
range_key = "SK"
attribute {
name = "PK"
type = "S"
}
attribute {
name = "SK"
type = "S"
}
# GSI para consultas inversas (¿qué apunta a este nodo?)
global_secondary_index {
name = "GSI1"
hash_key = "SK"
range_key = "PK"
projection_type = "ALL"
}
point_in_time_recovery { enabled = true }
}
resource "aws_lambda_function" "capture" {
function_name = "SecondBrain-Capture"
runtime = "nodejs22.x"
handler = "capture.handler"
filename = "lambda.zip"
role = aws_iam_role.lambda_exec.arn
timeout = 30
memory_size = 512
environment {
variables = { TABLE_NAME = aws_dynamodb_table.knowledge_graph.name }
}
}Terraform ofrece ventajas prácticas para este proyecto: state remoto en S3 con locking en DynamoDB, plan/apply explícito que muestra exactamente qué cambia antes de ejecutar, y un ecosistema de providers que cubre todos los servicios AWS incluyendo AgentCore. La infraestructura existente del proyecto — el rol IAM para los agentes de contenido con OIDC de GitHub Actions — ya corre en Terraform.
El prototipo actual es un segundo cerebro de conocimiento técnico general — conceptos de ingeniería de software, cloud, IA. Pero la arquitectura serverless que describí no tiene nada específico de tecnología. Es un sistema de grafo de conocimiento con captura, búsqueda semántica, agentes y surfacing proactivo. Eso abre la puerta a dominios donde el conocimiento estructurado tiene un valor mucho mayor.
El caso base. Un profesional — ingeniero, diseñador, product manager — construye su segundo cerebro público. Comparte lo que aprende, conecta ideas, deja que agentes de IA consuman su grafo. El valor está en la acumulación y las conexiones.
Esto es lo que jonmatum.com hace hoy. La versión serverless agrega captura de baja fricción (un endpoint en lugar de un commit), búsqueda semántica real, y agentes que pueden escribir. El costo se mantiene en centavos.
Un despacho legal maneja miles de documentos — sentencias, contratos, regulaciones, precedentes. Hoy viven en carpetas de SharePoint o sistemas de gestión documental que buscan por texto completo. Un segundo cerebro legal cambiaría el paradigma:
El valor diferencial: las conexiones entre documentos legales son el conocimiento real de un abogado experimentado. Un junior con acceso al grafo puede navegar relaciones que tomaría años de experiencia descubrir.
La arquitectura es idéntica — cambian los tipos de nodos, las relaciones, y el prompt del agente. DynamoDB almacena los metadatos, S3 los documentos completos, Bedrock genera embeddings y respuestas contextuales.
Un equipo de I+D produce papers, prototipos, datasets, resultados experimentales. El conocimiento se fragmenta entre Notion, Google Drive, Slack y la memoria de los investigadores. Un segundo cerebro de I+D:
El valor: en equipos de más de 5 investigadores, el conocimiento tácito — quién trabajó en qué, qué se intentó y falló, qué conexiones existen entre líneas de investigación — se pierde. El grafo lo captura y lo hace navegable.
Una institución educativa o un creador de contenido educativo:
Todos estos casos comparten la misma arquitectura:
Lo que cambia entre dominios:
| Componente | General | Legal | I+D | Educación |
|---|---|---|---|---|
| Tipos de nodo | Concepto, nota, experimento | Sentencia, ley, contrato | Paper, experimento, dataset | Concepto, ejercicio, recurso |
| Relaciones | «relacionado con» | «cita a», «deroga» | «reproduce», «refuta» | «prerequisito de» |
| Prompt del agente | Ingeniero staff+ | Abogado senior | Investigador principal | Tutor personalizado |
| Surfacing | Seeds olvidados | Precedentes contradictorios | Resultados cruzados | Gaps de aprendizaje |
La infraestructura AWS es idéntica. Un terraform apply con variables diferentes.
Este diseño no existe en el vacío. Nace de la intersección entre dos comunidades que me importan: la comunidad AWS y la comunidad de PKM (Personal Knowledge Management).
La comunidad AWS tiene una tradición fuerte de «builders» — ingenieros que construyen en público, comparten arquitecturas, y contribuyen a proyectos open source. Los AWS Community Builders, los User Groups, los re:Invent talks — todos comparten un principio: mostrar lo que construyes, explicar por qué tomaste esas decisiones, y dejar que otros aprendan de tus errores.
Un segundo cerebro serverless en AWS es exactamente ese tipo de proyecto. No es un producto — es un prototipo de referencia. Una arquitectura que otros builders pueden tomar, adaptar a su dominio, y desplegar con terraform apply. El código es open source. Las decisiones de arquitectura están documentadas en ensayos como este. Los costos son transparentes.
Lo que me interesa explorar con la comunidad:
Estas son preguntas que un solo builder no puede responder. Necesitan datos de múltiples implementaciones, en múltiples escalas, con múltiples patrones de uso. Eso es exactamente lo que una comunidad de builders produce.
El prototipo actual — Vercel, MDX, agentes en GitHub Actions — sigue funcionando. No voy a migrarlo mañana. Pero el diseño está listo, y las piezas están claras:
Cada fase es independiente y desplegable por separado. Cada una agrega valor sin requerir las siguientes. Y cada una es un tema para un ensayo futuro — con código, costos reales, y lecciones aprendidas.
El segundo cerebro no es el destino — es el vehículo. Lo que importa es el conocimiento que estructura, las conexiones que revela, y las decisiones que informa. La arquitectura serverless es solo la forma más eficiente que conozco de mantener ese vehículo funcionando — sin servidores que mantener, sin costos fijos, y con la capacidad de escalar desde un ingeniero curioso hasta un equipo de investigación completo.
La brecha entre un segundo cerebro personal y un sistema de conocimiento de producción no es de tecnología — es de arquitectura. Las piezas existen: DynamoDB para grafos, Bedrock para IA, Lambda para cómputo, MCP para interoperabilidad. Lo que falta es el diseño que las conecta con las restricciones correctas: costo cero en reposo, escalamiento automático, y la separación entre memoria, cómputo e interfaz que permite evolucionar cada capa de forma independiente.
Este ensayo es ese diseño. No es definitivo — es un punto de partida para construir, medir, y aprender en público.
Modelo de computación en la nube donde el proveedor gestiona la infraestructura automáticamente, permitiendo ejecutar código sin aprovisionar ni administrar servidores, pagando solo por el uso real.
Servicio de cómputo serverless de AWS que ejecuta código en respuesta a eventos sin necesidad de aprovisionar ni administrar servidores, escalando automáticamente desde cero hasta miles de ejecuciones concurrentes.
Base de datos NoSQL serverless de AWS con latencia de milisegundos a cualquier escala, ideal para aplicaciones que requieren alto rendimiento y escalabilidad automática.
Servicio managed de AWS para crear, publicar y gestionar APIs REST, HTTP y WebSocket que actúan como puerta de entrada a funciones Lambda y otros servicios backend.
Servicio serverless de AWS que proporciona acceso a modelos fundacionales de múltiples proveedores (Anthropic, Meta, Mistral, Amazon) vía API unificada, sin gestionar infraestructura de ML.
Servicio de almacenamiento de objetos de AWS con durabilidad del 99.999999999%, escalabilidad ilimitada y múltiples clases de almacenamiento para optimizar costos.
Servicio de mensajería pub/sub de AWS que distribuye mensajes a múltiples suscriptores simultáneamente, habilitando patrones de fan-out y notificaciones a escala.
Bus de eventos serverless de AWS que conecta aplicaciones usando eventos, permitiendo arquitecturas desacopladas y event-driven con enrutamiento basado en reglas.
Servicio de orquestación serverless de AWS que coordina múltiples servicios en workflows visuales, con manejo de errores, reintentos y ejecución paralela integrados.
Servicio de gestión de identidad y acceso de AWS que controla quién puede hacer qué en tu cuenta, con políticas granulares basadas en el principio de mínimo privilegio.
Estructuras de datos que representan conocimiento como redes de entidades y relaciones, permitiendo razonamiento, descubrimiento de conexiones y consultas semánticas sobre dominios complejos.
Protocolo abierto creado por Anthropic que estandariza cómo las aplicaciones de IA se conectan con herramientas, datos y servicios externos mediante una interfaz universal.
Prácticas y estrategias para minimizar el gasto en cloud sin sacrificar rendimiento, incluyendo right-sizing, reservas, spot instances y eliminación de recursos ociosos.
Framework de AWS con seis pilares de mejores prácticas para diseñar y operar sistemas confiables, seguros, eficientes y rentables en la nube.
Práctica de definir y gestionar infraestructura mediante archivos de configuración versionados en lugar de procesos manuales. Fundamento de la automatización moderna de operaciones.