Si ya trabajas con IA en proyectos concretos, conoces el techo: cada asistente que montas es brillante y desmemoriado a la vez.
Ajustas las instrucciones, defines el tono, cargas el contexto. Y a la siguiente sesión larga, el sistema vuelve a comportarse como si no os conocierais.
El problema ya no es el modelo. Es la arquitectura de contexto que le pones alrededor. Y ahí es donde dos archivos lo cambian todo.
🧠 El cuello de botella ya no es el modelo, es el contexto que persiste
Cuando pasas de “usar ChatGPT” a “montar asistentes y agentes para tareas concretas”, el enemigo cambia.
Deja de ser la calidad de la respuesta. Pasa a ser la continuidad: que tu sistema mantenga identidad, criterio y memoria a lo largo de días, proyectos y conversaciones.
Cada sesión vive en una ventana de contexto que, al cerrarse, se lleva todo por delante. Tú lo has notado: el agente que ayer entendía perfectamente tu flujo, hoy “alucina” tu tono o repite un error que ya habías corregido.
La solución no es un prompt más largo. Es separar lo que el sistema es de lo que el sistema recuerda, y guardarlo fuera de la conversación.
🧬 SOUL.md: la capa de identidad de tu asistente
El patrón SOUL.md —popularizado por un asistente de IA llamado Moto, que lo publicó el 21 de febrero de 2026— propone algo que cualquiera que monte agentes agradece: un archivo dedicado a la identidad, separado de todo lo demás.
El SOUL.md responde a “quién soy”, no a “qué sé hacer”. Contiene personalidad, valores, tono, criterios de decisión y límites. Es estable: casi no cambia entre proyectos.
Un SOUL.md de un asistente real, escrito en Markdown plano, se parece a esto:
SOUL.md
Identidad
Asistente editorial de un equipo de formación en IA. Español, tono directo, cero relleno corporativo.
Principios de trabajo
Propón estructura antes de redactar en largo.
Cuando falte contexto, pregunta; no rellenes con supuestos.
Cita solo datos que puedas justificar.
Criterio de decisión
Ante dos opciones, prioriza la que el usuario pueda revisar en menos tiempo.
Límites
No inventes cifras, fuentes ni testimonios.
Lo potente para tu caso: esto es versionable. Va a un repositorio, se revisa en un diff, evoluciona con control de cambios. Tu asistente deja de ser un prompt volátil y pasa a ser un artefacto mantenible.
🗂️ MEMORY.md: la capa de memoria curada (no un vertedero de logs)
Si SOUL.md es la identidad, MEMORY.md es el conocimiento acumulado y curado. Y esa palabra, “curado”, es la clave que separa un sistema que funciona de uno que se ahoga en su propio contexto.
MEMORY.md no guarda todo lo que pasa. Guarda decisiones, preferencias e insights que deben sobrevivir a la sesión. Es la diferencia entre memoria a largo plazo y transcripción bruta.
La distinción, para que no la confundas nunca:
SOUL.md → quién es el asistente. Cambia poco.
MEMORY.md → qué ha aprendido contigo. Crece, pero seleccionando.
Logs de sesión (
2026-09-02.md) → el registro crudo del día. De ahí destilas al MEMORY, no al revés.
Ejemplo de entrada en un MEMORY.md:
Decisiones del proyecto “Clínica Norte”
2026-08-19 · El cliente rechaza el término “paciente-cliente”. Usar “paciente”.
2026-08-26 · Aprobado tono cercano pero sin emojis en comunicaciones a seguros.
Preferencia estable: entregar siempre esquema + borrador, nunca solo el final.
Un colega nuestro que gestiona varios agentes para clientes distintos montó exactamente esto: un SOUL.md por cliente y un MEMORY.md que actualiza al cierre de cada sprint. Dice que el salto de calidad no vino de cambiar de modelo, sino de dejar de recargar el mismo contexto a mano cada lunes.
No es magia. Es arquitectura bien separada.
🔗 SOUL y MEMORY no van solos: la familia de archivos de contexto
Si ya estás en este nivel, te interesa el sistema completo, no dos archivos sueltos. El patrón suele venir acompañado de una pequeña familia de ficheros, cada uno con un trabajo:
SOUL.md→ identidad del asistente (”quién soy”).MEMORY.md→ memoria curada a largo plazo (”qué he aprendido”).USER.md→ contexto de la relación: quién eres tú, cómo trabajas, qué esperas.AGENTS.md→ instrucciones operativas del proyecto para un agente (convención que ya usan muchas herramientas; su primoCLAUDE.mdcumple el mismo papel en el ecosistema de Claude).Logs diarios (
YYYY-MM-DD.md) y unstate.jsonpara memoria de trabajo entre pasos.
¿Ves la lógica? Separas identidad (SOUL), memoria (MEMORY), usuario (USER) y operativa (AGENTS). Cada uno se edita y se versiona por su cuenta.
No hace falta que adoptes los cinco de golpe. Empieza por SOUL + MEMORY, que es donde está el 80% del valor, y añade el resto cuando tu flujo lo pida.
Si ya montas agentes: ¿estás metiendo identidad, memoria y operativa en un mismo prompt gigante, o los tienes separados?
🧪 Dónde vive esto en las herramientas que ya usas
Lo mejor es que no necesitas un framework nuevo. Puedes implementar el patrón hoy sobre lo que ya tienes:
Proyectos de Claude / ChatGPT: las instrucciones del proyecto son tu SOUL.md + USER.md. Pega ahí la identidad y el contexto del usuario, y usa los archivos del proyecto o la memoria para el MEMORY.
CLAUDE.md / AGENTS.md en el repositorio: si trabajas con agentes de código, ese fichero ya es tu capa de identidad y operativa. Añádele una sección de memoria curada.
Custom GPTs / asistentes con “instructions”: el campo de instrucciones es el SOUL; el “knowledge” cargado hace de MEMORY estable.
Memoria nativa (la de ChatGPT, por ejemplo): útil, pero la gestiona la herramienta por ti. Un MEMORY.md propio te da control, portabilidad entre modelos y trazabilidad.
La regla mental: lo que define al asistente va en instrucciones; lo que aprende contigo va en un archivo que tú controlas.
🚀 Cómo montarlo hoy en tu flujo
Para alguien que ya trabaja con IA en proyectos, esto son 20 minutos bien invertidos:
Crea un
SOUL.mdpara tu asistente principal: identidad, 3-4 principios de trabajo, criterio de decisión y límites. Nada de tareas.Crea un
MEMORY.mdvacío con secciones por proyecto o cliente. Solo decisiones e insights, con fecha.Añade un
USER.mdcon tu contexto: rol, cómo revisas, qué odias, qué esperas por defecto.Cárgalos donde persistan: instrucciones del Proyecto,
CLAUDE.md/AGENTS.mddel repo, o el campo de instrucciones de tu GPT.Automatiza la destilación: al cerrar una sesión larga, pídele al propio asistente que te proponga qué añadir al MEMORY. Tú apruebas, él no escribe solo.
Versiona los cambios: si puedes, mételos en git. Un SOUL.md con historial es un asistente que puedes auditar.
Revisa el MEMORY cada sprint: poda lo que ya no aplica. Una memoria sin curar envenena el contexto.
Copia y pega este prompt para arrancar la destilación al final de una sesión:
Repasa nuestra conversación y propón entradas nuevas para mi MEMORY.md. Formato: una línea por entrada, con fecha, agrupadas por proyecto, solo decisiones o preferencias estables (no tareas puntuales). No las des por guardadas: dámelas para que yo las apruebe.
Y este para generar el esqueleto de un SOUL.md coherente:
Actúa como arquitecto de asistentes de IA. Hazme preguntas, de una en una, sobre la identidad, los principios de trabajo, el criterio de decisión y los límites del asistente que quiero montar. Al terminar, entrégame un SOUL.md en Markdown limpio, sin tareas ni conocimiento concreto, solo identidad.
No necesitas un stack de agentes de última generación. Necesitas separar identidad y memoria, y mantenerlas vivas.
❓ Preguntas frecuentes
¿Sustituye esto a saber diseñar prompts y agentes?
No. Cambia la forma en que gestionas el contexto. El prompting sigue importando; simplemente dejas de recargar identidad y memoria a mano en cada sesión.
¿Funciona para mi caso si gestiono varios clientes o proyectos?
Sí, y es donde más brilla. Un SOUL.md por asistente y un MEMORY.md segmentado por cliente evita que se mezclen contextos y decisiones.
¿No basta con la memoria automática que ya traen algunas herramientas?
Para casos simples, sí. Pero un archivo propio te da control, portabilidad entre modelos y un historial auditable. La memoria nativa decide por ti; el archivo lo decides tú.
¿Qué otras herramientas o convenciones hacen algo parecido?
Los Proyectos de Claude y ChatGPT, los Custom GPTs, y ficheros de contexto como CLAUDE.md, AGENTS.md o USER.md. Todos apuntan a lo mismo: identidad y memoria persistentes fuera de la conversación.
¿Cada cuánto actualizo cada archivo?
SOUL.md casi nunca. USER.md cuando cambie tu forma de trabajar. MEMORY.md, una poda por sprint. Los logs, a diario si los usas.
💌 Para terminar
El salto de nivel con la IA ya no está en encontrar el prompt perfecto. Está en construir el sistema que rodea al modelo: identidad estable, memoria curada, contexto separado y versionable.
SOUL.md y MEMORY.md son la forma más sencilla de empezar a pensar así. Dos archivos, y tu asistente deja de nacer de cero cada mañana.
En Paratodosia trabajamos justo esto en los bootcamps: cómo diseñar asistentes y agentes con arquitectura de contexto que aguante en el mundo real, no solo en la demo. Si quieres que te avisemos de la próxima edición, responde a este correo con la palabra “SOUL”.
Si este post te ha sido útil, compártelo con alguien que esté montando sus propios asistentes.
Fuentes: The SOUL.md Pattern — Moto’s Blog · soul.py: memoria e identidad persistente para agentes LLM (GitHub) · A Practical Guide to Memory for Autonomous LLM Agents — Towards Data Science
Gracias, esto ya es bastante avanzado para los no techos. Duda: habkais de GPT y Claude... ¿como aplica algo así para Gems de Gemini? Se pueden hacer archivos de memoria... o completar las instrucciones?. Solo deja subir 10 archivos PDF como base de conocimiento.
Gracias