Claude Code no tiene memoria entre sesiones. Cada vez que abres una conversación nueva, empiezas de cero. Tu asistente no recuerda que la última vez le dijiste que no usara mocks en los tests, que Supabase necesita RLS obligatorio, o que tu equipo sigue una convención específica para los commits.
Puedes escribir todo en un archivo de instrucciones. Pero eso requiere que tú sepas qué escribir, que lo mantengas actualizado, y que no se te olvide nada. En la práctica, acabas repitiendo las mismas correcciones cada pocas sesiones.
Llevo dos semanas construyendo un sistema que resuelve esto. Se llama Sinapsis y acaba de llegar a la versión 4.3.
Qué es Sinapsis
Sinapsis es un sistema de aprendizaje continuo embebido en Claude Code. Observa cómo trabajo, detecta patrones recurrentes y los convierte en "instincts" — reglas atómicas que se inyectan automáticamente en las sesiones siguientes.
No es un plugin. No es un chatbot con memoria. Es un pipeline cerrado con cuatro fases:
- Observar — Un hook registra cada interacción relevante: errores corregidos, decisiones tomadas, correcciones del usuario
- Aprender — Al cerrar sesión, un script analiza las observaciones y propone nuevos patrones
- Indexar — Los patrones se almacenan en un índice ligero con niveles de confianza
- Activar — Antes de cada acción, otro hook inyecta los instincts relevantes según el contexto
El ciclo completo es determinista. No depende de que Claude "decida" aplicar una regla. Los hooks se ejecutan el 100% de las veces.
Por qué hooks y no skills
Esta fue una de las primeras decisiones de arquitectura y probablemente la más importante.
Claude Code tiene dos mecanismos para extender su comportamiento: skills (archivos markdown que Claude lee cuando le parece relevante) y hooks (scripts que se ejecutan en eventos específicos del sistema).
Las skills son probabilísticas. Claude las aplica entre el 50% y el 80% de las veces, dependiendo del contexto. Para contenido o documentación, eso es aceptable. Para un sistema de aprendizaje, no.
Si tu sistema pierde el 30% de las observaciones porque Claude decidió que no eran relevantes, tu modelo de aprendizaje tiene agujeros. Hooks se ejecutan siempre. Cero patrones perdidos.
El coste en tokens es cero. Los hooks son scripts de shell que se ejecutan fuera del contexto de Claude. Solo inyectan información cuando es necesario, y lo hacen como mensaje de sistema — no como parte de la conversación.
El sistema de confianza
No todos los instincts son iguales. Sinapsis usa tres niveles:
| Nivel | Comportamiento |
|---|---|
| Draft | Solo visible en el dashboard. No se inyecta. Está en cuarentena |
| Confirmed | Se inyecta automáticamente cuando el contexto coincide |
| Permanent | Máxima prioridad. Reglas validadas en producción |
Lo interesante es cómo sube de nivel. Cada vez que un instinct coincide con el contexto de una sesión, se incrementa un contador. Cuando un draft alcanza 5 coincidencias, se promueve automáticamente a confirmed.
No hay intervención humana. El sistema decide solo qué patrones son recurrentes y cuáles fueron ruido.
A la inversa: un instinct confirmed que no se activa en 60 días baja a draft. Un draft que no se activa en 90 días se archiva. Nunca se borra — siempre es recuperable — pero deja de ocupar espacio en el índice activo.
Esto es lo que llamo el "dream cycle": higiene automática del conocimiento.
De v3.5 a v4.3 en dos semanas
La primera versión funcional de Sinapsis era un archivo de texto que Claude leía al inicio de cada sesión. Funcionaba, pero era manual, frágil y no escalaba.
La evolución fue rápida:
v3.5 fusionó dos sistemas separados (aprendizaje + auto-reparación) en uno solo. Redujo el consumo de tokens un 57%.
v4.0 introdujo el pipeline cerrado. Cuatro scripts, cada uno con un escritor y un lector, sin datos huérfanos. La migración de 38 instincts en YAML a un índice JSON redujo otro 41% el overhead.
v4.2 añadió occurrence tracking: cada instinct sabe cuántas veces se ha activado, cuándo fue la primera vez y cuándo la última. Aquí es donde el auto-promote se volvió real.
También añadí un "linting Karpathy" — una tarea programada que analiza las observaciones diarias y genera un grafo de conocimiento. Es como un resumen de lo que el sistema ha aprendido, que sirve de contexto para detectar huecos.
v4.3 pasó una auditoría de seguridad externa. 22 bugs corregidos, 6 vulnerabilidades parcheadas. El sistema se hizo portable entre macOS y Windows. 78 tests cubren el pipeline completo.
Lo que quité fue más importante que lo que añadí
En la v4.4 integré herramientas de ingeniería dentro de Sinapsis: auditorías de seguridad, revisiones de código con especialistas, depuración sistemática. Parecía lógico — si el sistema aprende de tu trabajo, debería también ayudarte a trabajar mejor.
Error.
Un colega lo resumió bien: "Sinapsis debería ser una herramienta de aprendizaje, no un Frankenstein."
Las herramientas de ingeniería no participan en el ciclo observar-aprender-indexar-activar. Son ortogonales al aprendizaje. Mezclarlas diluía el enfoque y complicaba el mantenimiento.
En la v4.3.2 separé todo lo que no fuera aprendizaje puro. Cinco componentes movidos a herramientas independientes. El core quedó limpio: observación, aprendizaje, indexación, activación, y la higiene del conocimiento.
A veces la mejor decisión de producto es quitar funcionalidades.
Qué hay ahora
39 instincts activos. El 64% son permanentes — reglas validadas en producción real a lo largo de cuatro proyectos distintos. Cubren desde convenciones técnicas (cómo autenticar con Supabase, cómo estructurar pagos con Stripe) hasta decisiones de negocio (tarifas, delegación de tareas, formato de entregables).
78 tests automáticos: unitarios, TDD, end-to-end y de seguridad.
El sistema no consume tokens extra en ejecución. Los hooks son scripts de shell — no pasan por Claude. Solo el contenido que se inyecta como contexto tiene coste, y está optimizado para ser mínimo.
Por qué importa esto
La mayoría de las personas que usan asistentes de IA repiten las mismas instrucciones sesión tras sesión. Los más organizados escriben archivos de configuración estáticos. Pero casi nadie tiene un sistema que aprenda de sus correcciones y las aplique automáticamente.
Esto no es ciencia ficción. Son scripts de shell, archivos JSON y una arquitectura deliberada. Lo que hace que funcione no es la tecnología — es la disciplina de separar observación de acción, de tener niveles de confianza explícitos, y de limpiar automáticamente lo que deja de ser útil.
Si usas Claude Code de forma regular, hay dos cosas que puedes hacer hoy:
-
Documenta tus correcciones recurrentes. Cada vez que le dices a Claude "no, así no", es un instinct potencial. Si lo escribes en un archivo de instrucciones, ya tienes la versión manual de Sinapsis.
-
Revisa qué reglas sigues aplicando manualmente. Si llevas semanas diciendo lo mismo, esa regla debería estar automatizada. No necesitas un sistema complejo — un hook básico que inyecte contexto ya es un salto.
Sinapsis es open source. Si quieres ver cómo funciona por dentro o adaptarlo a tu flujo de trabajo, el repositorio está en GitHub.
Si la memoria es lo que Sinapsis da a Claude, la cognición es lo que le da Cognito: el sistema que decide cómo piensa Claude en cada fase del proyecto, con siete modos de pensamiento que corrigen los sesgos conocidos de los LLMs.
Este artículo forma parte de la serie "Diario de Automatización" donde documento cómo estoy automatizando mi empresa con IA. Ver todos los artículos de la serie.