Sunny es mi asistente personal de IA. Corre sobre OpenClaw (una capa open-source de orquestación de agentes que maneja el ruteo y el fan-out multi-agente para no tener que armarlo desde cero). Encima de OpenClaw construí la capa de seguridad y observabilidad: identidad por capas (modos de comportamiento entre los que va cambiando), tres pilares en cada decisión (cada acción pasa por tres criterios: calidad, seguridad, eficiencia), tres tiers en cada tarea ruteada, cada delegación visible (ves exactamente cómo se divide el trabajo, a diferencia de un chatbot normal, así nada de lo que hace pasa fuera de vista). Hoy corre sobre GPT-5.4, con modelos Ollama de respaldo local (Ollama corre los modelos en mi propia computadora, así nada tiene que salir de la máquina cuando la red se pone fea o cuando el cálculo de costo cambia). Estoy pensando moverla a Opus o GPT-5.5 después. La construí para quitarme las partes repetitivas del día de encima. Leer el correo entrante, pasarme el brief de la mañana, armar el calendario, dar seguimiento a lo que prometí ayer. No es un reemplazo de Claude. Un orquestador que decide qué modelo maneja qué tipo de tarea, corre el loop administrativo diario sin que yo esté en la silla, y mantiene el cálculo de costo honesto enrutando el trabajo barato-y-rápido a un tier barato en vez de pagar tarifas de frontera por cada tap. La arquitectura de memoria salió de construirla. Si está haciendo el mismo tipo de cosas cada mañana, debería recordar qué importó ayer, qué decidí la semana pasada, cuál versión de mi agenda es la viva. Eficiencia y personalización, ambas como efecto colateral del trabajo que en verdad hace. ## La semana que se salió del guión La versión floja de una IA personal es una interfaz de chat conectada a un modelo con herramientas. Le tiras un system prompt (las instrucciones que el modelo lee antes de cada conversación), le das algunas integraciones MCP (los cables que dejan a una IA hablar con otras apps), lo subes a producción. Funciona bien hasta que le entregás algo que de verdad importa y te responde con la voz de otro, o se le olvida un dato que le contaste la semana pasada, o calladita hace algo afuera que no podés ver. La corrí así por una semana. Ahí empecé a cacharla haciendo cosas que yo no había autorizado. Mandando un mensaje que no debió haber mandado. Citando contexto de una sesión anterior que debió quedarse privado. Respondiendo con las opiniones por defecto del modelo en lugar de las que con paciencia le había estado enseñando durante meses. Nada de eso era un bug. Era la arquitectura. Un solo system prompt, un solo modelo, sin registro de auditoría, sin política de tiers. Así que tiré esa versión y me fui por el otro camino. El otro camino es una identidad por capas, una doctrina operativa explícita, una política de ruteo de subagentes por tiers (como tener mini expertos a la mano, ordenados por dificultad de la tarea), y un tablero de mission control para poder ver qué está haciendo en realidad. Ninguna de esas piezas es exótica. El punto es componerlas en un solo sistema que corra localmente y me muestre su trabajo. Una directora con una partitura, no un chatbot con herramientas. Sunny conoce la orquesta, lee la doctrina, da las entradas, escucha la calidad y escribe notas después de cada ensayo. ## La doctrina de cinco pasos Cada tarea, ya sea un mensaje de Discord o un comando del tablero, pasa por la misma doctrina de cinco pasos. La forma de la tarea cambia. El camino no. La disciplina vive en las restricciones. El paso 03 es el de forma IE. El trabajo de alto riesgo y alta ambigüedad no se puede degradar. El trabajo de cara externa no se puede mandar al modelo más barato. El preprocesamiento interno prefiere agresivamente el modelo más barato. El modelo caro sólo dispara cuando de verdad gana su costo. El paso 04 es el de forma de confianza. Si un sub-agente manda un mensaje en mi nombre, veo qué se mandó, dónde y por qué. Si se está escribiendo memoria, veo qué se agregó y por qué. El tablero de mission control convierte el registro de auditoría de un archivo de log en una superficie navegable: agentes, automatización, diagnósticos, governance, memoria, overview, cada uno su propia página. ## Cómo está construida El stack técnico es intencionalmente angosto. Un gateway local de FastAPI maneja los mensajes entrantes y las llamadas a herramientas. GPT-5.4 es su cerebro principal. Los modelos Ollama están de respaldo local cuando la red se pone fea o cuando quiero mantener algo fuera del cable. Un pequeño tablero Next.js, mission control, visualiza el sistema corriendo. Ninguna de sus rutas es abstracta; cada una superficia lo que Sunny está haciendo justo ahora. ### Los siete archivos en capas El stack no técnico es donde vive el gusto de diseño. Siete archivos markdown se cargan al arranque de la sesión, agrupados por lo que gobiernan. La capa de identidad sostiene tres archivos. IDENTITY dice quién es Sunny: nombre, vibra, los tres pilares. SOUL dice cómo opera: la doctrina de orquestación, la política de ruteo por tiers, la defensa contra inyección de prompts, los límites. USER dice a quién sirve: perfil del dueño, prioridades actuales, el roster de agentes. La deriva de persona, la deriva de doctrina y la deriva de roster son modos de falla independientes; separar sus archivos hace a cada uno inspeccionable y reversible por sí solo. La capa de memoria sostiene dos archivos. MEMORY es el conocimiento canónico de largo plazo, mantenido bajo mil tokens, sabiduría destilada en lugar de logs crudos. HEARTBEAT carga las reglas de mantenimiento: procedimientos de destilación calendarizados, disciplina de respaldo antes de editar, el paso previo consciente de correlación que corre antes de cualquier actualización de memoria. La capa operativa sostiene los últimos dos. AGENTS define la disciplina de arranque (qué cargar, qué no cargar), reglas de privacidad para chats grupales, y la convención de tagging post-sesión. TOOLS es el registro de capacidades: qué skills, plugins e integraciones están disponibles y cuándo recurrir a cada uno. La elección de diseño debajo de todo esto es tratar la capa durable como archivos que puedo leer y editar, no como vectores embebidos que sólo puedo consultar. Cuando quiero cambiar el comportamiento de Sunny, edito sus archivos y hago commit. Cuando ella aprende algo nuevo, el cambio es un diff que puedo revisar. El costo es que el recall semántico es más difícil que un vector store. La ganancia es que el sistema es auditable como texto ordinario. ### La memoria como grafo, no documento La memoria misma es más que MEMORY.md. Cinco superficies componen lo que el tablero de mission control llama el segundo cerebro. Las notas crudas son captura verbatim de sesión, aún sin curar. Los tags son compresión semántica post-sesión de lo que importó. Los distills son la agregación diaria que refuerza conceptos existentes y sólo reforma cuando la evidencia es fuerte. Los conceptos son abstracciones durables, wiki-linked desde MEMORY.md y entre sí. Las entradas de diario son registros reflexivos que narran lo aprendido a lo largo de sesiones. El paso de destilación consciente de correlación es la disciplina que mantiene este grafo esparcido en lugar de dejarlo desbordar. Antes de cualquier actualización a MEMORY.md o a la capa de conceptos, el paso cruza las entradas nuevas contra los conceptos existentes, refuerza lo que ya existe en lugar de crear duplicados, y sólo agrega conceptos nuevos cuando la evidencia repetida a través de fuentes o fechas es fuerte. Sin esta disciplina, una memoria basada en markdown se convierte en notas obsoletas en cuestión de semanas. Con ella, el grafo se mantiene esparcido conforme la agente madura y el recall sigue siendo útil. ### Enlaces sobre vectores Después de unos días de Sunny corriendo de verdad, el segundo cerebro deja de ser abstracto. Los tags se acumulan. Los destilados refuerzan conceptos. Las sesiones escriben sus post-tags. Abrís Obsidian y la vista de grafo muestra lo que la arquitectura produce en la práctica. Vista de grafo en Obsidian de la memoria de Sunny: nodos que representan conceptos, sesiones y entradas de journal conectados por backlinks explícitos.

Vista de grafo en Obsidian de la memoria de Sunny: nodos que representan conceptos, sesiones y entradas de journal conectados por backlinks explícitos.

La movida por defecto cuando le das memoria de largo plazo a un LLM es RAG (retrieval-augmented generation: al modelo le pasan los pedazos de contexto más relevantes para cada pregunta, como un examen a libro abierto). La mayoría de implementaciones de RAG se apoyan en similitud vectorial, donde dos notas cuentan como "relacionadas" si sus embeddings matemáticos quedan cerca. El recall vectorial encuentra cosas cercanas. No sabe POR QUÉ dos notas están relacionadas, solo que están cerca en algún espacio de alta dimensión. Andrej Karpathy (cofundador de OpenAI, ex-líder de IA en Tesla) formalizó este mismo patrón en su [gist LLM Wiki de abril de 2026](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f): un wiki en markdown mantenido por un LLM que destila, enlaza y se actualiza solo, en lugar de tirar documentos a un vector store. Su punto empata con lo que Sunny ya venía corriendo: el cuello de botella de los agentes no es la inteligencia bruta, es la recuperación de contexto. El modelo es brillante en el momento y amnésico entre sesiones. Lo que aterrice en su ventana de contexto antes del primer token le da forma a todo lo que viene después. Sunny trata la recuperación como un problema de grafo explícito en su lugar. Los enlaces SON la verdad de fondo. Cuando necesita contestar "qué decidí sobre X el mes pasado", camina el grafo de enlaces desde X a través de los backlinks estilo Obsidian, juntando conceptos y sesiones conectadas, ponderados por recencia. La tasa de aciertos le gana al recall vectorial porque los ENLACES los escribió un paso de destilación que ya entendía la relación, no se infirieron de la distancia entre palabras después del hecho. El costo: el paso de destilación tiene que hacer su trabajo en serio. Cada actualización de memoria corre por un pre-paso consciente de correlación (pensá en editor antes de publicar: ¿esta entrada ya empata con un concepto existente, o de verdad es nueva?) antes de que se escriba algún enlace. Sin esa disciplina, una memoria basada en grafo se desparrama en millones de nodos conectados por ruido. Con ella, el grafo se mantiene esparcido y la búsqueda se mantiene rápida. ### Lo que ella puede hacer La superficie de capacidades llega por tres canales. Las skills son capacidades durables catalogadas en TOOLS.md y superficiadas a través de los pasos Descomponer y Rutear de la doctrina. La skill `coding-agent` toma trabajo de programación no trivial. `skill-creator` es la meta-skill para autorar skills nuevas. Los SOPs basados en directivas cubren brainstorming, creación de agentes y trabajo de memoria bajo demanda. Cada skill carga su propio contrato: qué espera, qué regresa, cuándo es la herramienta correcta. La doctrina consulta el registro en lugar de improvisar. Los subagentes extienden el roster (especialistas que ella llama para un tipo de trabajo, como contratistas). Oracle es el ejemplo actual, un sentinel de sólo lectura que monitorea todos los workspaces de agentes en busca de cambios, deriva y anomalías, publicando reportes a un canal dedicado. Oracle nunca se rutea como worker; eso es explícito. Los workers ruteados por tier (barato y rápido para preprocesamiento interno, caballo de batalla para complejidad moderada, alto riesgo para ambigüedad y externalidad) son los blancos regulares de delegación, cada tier cargando sus propias reglas de sesgo. Las integraciones atan a Sunny al exterior. Discord maneja mensajería: chats grupales, DMs, envío de archivos, reacciones a mensajes, todo bajo allowlists de canal. Ollama sirve la flota local de modelos para cuando GPT-5.4 no está alcanzable o no es apropiado. Un plugin `consent-layer` se sienta entre Sunny y operaciones seleccionadas que son riesgosas o cambian estado, abriéndolas detrás de prompts breves de aprobación. Los cambios riesgosos escriben respaldos primero; las rutas de rollback se preservan para que cualquier error siga siendo recuperable. La recuperación de emergencia es su propia ruta abierta que requiere aprobación explícita fresca más una frase privada de autenticación, en lugar de depender de permiso permanente. El punto de catalogar capacidades en TOOLS.md y superficiarlas a través de la doctrina es que la agente nunca improvisa el uso de herramientas. Cada acción que toma mapea a una capacidad conocida con un contrato conocido. Esa es la precondición para que el registro de auditoría signifique algo en lugar de ser superficial. La mayoría de asistentes meten persona, procedimiento operativo y contexto de usuario en un solo system prompt (las instrucciones base que un modelo lee antes de cada conversación, como una descripción de puesto de una página). Sunny los separa en archivos. IDENTITY rara vez cambia. SOUL evoluciona conforme la doctrina se refina. USER es un documento vivo que crece conforme el roster de agentes se expande. La deriva de persona, la deriva de doctrina y la deriva de roster son modos de falla independientes. Separar sus archivos hace a cada uno inspeccionable y reversible por sí solo. La doctrina de cinco pasos y la política de ruteo en tres tiers de subagentes no son detalles de implementación. Son el contrato. Cada delegación aparece en el registro de auditoría (más transparente que un chatbot normal: ves cómo se divide el trabajo en tiempo real). El trabajo de alto riesgo no se puede degradar. El tier caro sólo dispara cuando la tarea gana el costo. El tablero de mission control hace el contrato verificable en lugar de aseverado: puedo ver qué corrió Sunny, con qué modelo, a qué clase de riesgo, y qué regresó. La memoria de largo plazo es curada, no apenada. El paso de destilación consciente de correlación corre antes de cualquier actualización a MEMORY.md. Cruza las entradas nuevas contra los conceptos existentes, refuerza lo que ya existe en lugar de crear duplicados, y mantiene el grafo esparcido a menos que la evidencia repetida sea fuerte. Sin esta disciplina, una memoria basada en markdown se convierte en notas obsoletas en cuestión de semanas. Oracle es el sub-agente actual en el roster: un sentinel de sólo lectura que monitorea todos los workspaces de agentes en busca de cambios, deriva y anomalías, publicando reportes a un canal dedicado. Nunca se rutea como worker; eso es explícito. La regla de diseño es que los agentes de monitoreo y los agentes de trabajo son preocupaciones separadas, y juntarlas crea un loop de retroalimentación donde el watcher se vuelve otra cosa que vigilar. Los subagentes worker rutean por tier según complejidad y riesgo; el sentinel observa a los workers sin participar en su trabajo. ## Lo que sigo reaprendiendo La movida por defecto cuando construís una IA personal es soltar el modelo más grande disponible en una interfaz de chat y darlo por terminado. Eso es automatización commodity con una voz encima. Funciona una semana. Después empezás a cacharla haciendo cosas que no autorizaste. Sunny es el proyecto opuesto. Elegí un modelo fuerte por defecto para los casos difíciles (GPT-5.4 hoy, quizá Opus o 5.5 después), lo rodeé de doctrina operativa explícita, ruteé los casos baratos a un tier barato para que la cuenta siga honesta, le di una identidad por capas que persiste entre sesiones, caigo a modelos locales cuando se justifica, y superficié cada acción para que el sistema se mantenga inspeccionable. Tres pilares son la puerta de calidad. Cinco pasos son el flujo de proceso. Tres tiers son el ruteo basado en restricciones. Siete archivos son el diseño por capas que previene la deriva entre persona, disciplina operativa y memoria. Ninguna de esas piezas es exótica por sí sola. Lo distintivo es componerlas en un solo sistema que corre en mis propias máquinas y me muestra lo que está haciendo. Este es un sistema personal, no un producto. Más cerca de un Jarvis a la medida que de una suscripción SaaS. Algunas superficies de implementación (red Docker en Hyper-V, empaquetado de plugins, límites de tasa de integraciones) siguen siendo rugosas. La arquitectura es lo estable. Estoy publicando el caso de estudio antes de que la implementación esté completamente lisa porque la arquitectura misma es la lección, y la lección es que el gusto de diseño es más importante que la elección de modelo.