Devin de Cognition ahora guarda su memoria en un repositorio Git: qué depura Dreaming y por qué no se comparte con tu equipo (2026)

El anuncio del producto describe Memory como una forma de "llevar aprendizajes útiles sobre cómo te gusta trabajar a lo largo de las sesiones: tus preferencias, las correcciones que has hecho y las lecciones aprendidas sobre tus proyectos y flujos de trabajo". En X, Cognition lo expresó de manera más breve: "A lo largo de las sesiones, Devin construye un gráfico de memoria de cómo te gusta trabajar".

La documentación describe el almacenamiento. "Tus recuerdos viven en una unidad de memoria (memory drive): un repositorio Git persistente de notas en Markdown". Un archivo corto MEMORY.md contiene las preferencias generales y un índice, y otras notas se guardan en carpetas por proyecto o tema.

También describe un bucle de tres partes. En la primera parte, "Cada sesión obtiene su propio checkout de la unidad y recibe MEMORY.md como contexto". Devin busca y lee otras notas solo cuando una tarea las necesita. En la segunda, cuando corriges a Devin o este resuelve algo reutilizable, edita una nota, y cada entrada es un punto de una sola línea que enlaza de vuelta a la sesión donde se aprendió. En la tercera, Devin hace un commit, fusiona los cambios de otras sesiones y guarda. Las sesiones paralelas pueden escribir en la misma unidad, y el blog dice: "Los conflictos de edición se muestran para su resolución en lugar de sobrescribirse silenciosamente".

Un detalle de sincronización es fácil de pasar por alto: "Las nuevas memorias se aplican a sesiones futuras, no a la que las escribió".

Luego está el estándar abierto. La documentación dice que la memoria de Devin "está construida sobre Agent Memory Repo, una especificación abierta que trata la memoria del agente como un repositorio Git con un punto de entrada MEMORY.md", y añade: "Puedes usar el mismo formato en tus propios agentes".

Devin decide qué guardar, dentro de los límites establecidos. La documentación incluye una tabla. Guardado: preferencias, correcciones, decisiones con las razones que diste y advertencias sobre tus repositorios. No guardado: "Resúmenes de sesiones", "Estado de la tarea, como números de PR o estados", "Cualquier cosa fácil de volver a descubrir" y "Secretos y credenciales". El blog expresa la misma idea de otra manera: "Las memorias no son resúmenes de sesiones".

Dreaming agrega, fusiona y elimina. "Dreaming es una sesión en segundo plano que se ejecuta aproximadamente una vez al día cuando has estado usando Devin". Consolida notas superpuestas, agrega lecciones que no se capturaron y reorganiza el índice. También "Elimina detalles transitorios y notas obsoletas que ninguna sesión haya utilizado". El blog enumera el mismo paso como la eliminación de "registros de memoria obsoletos que no fueron utilizados por ninguna sesión". Cognition señala que "Se conservan los enlaces de origen y las preferencias explícitas".

La memoria es personal. Esta es la línea que más importa para los equipos. "La memoria es personal para ti dentro de cada organización. No se comparte con tus compañeros de equipo ni con tu organización". El blog lo enmarca como una elección de diseño: "Es personal para ti, en lugar de convertirse en instrucciones compartidas para tu organización".

Las automatizaciones quedan fuera. "Las sesiones iniciadas por automatizaciones no leen ni escriben en tu memoria". El trabajo que Devin inicia desde una programación, un activador de Slack o un webhook se ejecuta sin tus notas personales.

Tú la gestionas a través de Devin. Puedes explorar los archivos de memoria en Customize, luego Memory, y ver qué cambió en cada sesión de dreaming. Pero "Los archivos de memoria son de solo lectura en la aplicación". Para cambiar algo, le pides a Devin en una sesión, por ejemplo, que olvide una preferencia o recuerde una regla.

Desactivarla conserva las notas. La memoria está activada por defecto. Si desactivas tu memoria personal, "Devin deja de leer y escribir en la memoria; tus notas existentes se conservan si la vuelves a activar". Cuando un administrador la desactiva para una organización, "Dreaming no se ejecuta y la pestaña Memory se oculta. Las notas existentes no se eliminan".

Las pautas de equipo tienen su propio espacio, y se está trasladando. Para instrucciones compartidas, Devin apunta a las skills. "Las skills son procedimientos que escribes deliberadamente", dice la página de skills, y las skills en plugins "se pueden instalar a nivel personal, de organización o de empresa". La función anterior de Knowledge de Devin ahora lleva un banner: "Knowledge está en desuso y se eliminará en una futura actualización". El Knowledge existente se está migrando a skills automáticamente. Si configuraste activadores de la manera descrita en nuestra guía sobre Devin Knowledge, espera que lleguen como skills.

Esto también es independiente de Devin Desktop, el agente local de Cognition, cuyas memorias de la era Cascade se tratan en trasladar las memorias exclusivas de Cascade de Devin a skills. La unidad de memoria descrita aquí pertenece a Devin en devin.ai.

Asumir que Devin ahora recuerda lo que decidió tu equipo. Recuerda lo que aprendió mientras trabajaba contigo. El Devin de tu compañero de equipo tiene su propia unidad. Una decisión que le explicaste a Devin la semana pasada está en tu memoria, no en la de ellos.

Interpretar los casos de uso de equipo de la especificación abierta como una descripción de la memoria de Devin. La especificación sí menciona la memoria de equipo como un caso de uso: "Compartir conocimiento sobre clientes, procesos y herramientas, especialmente para equipos sin un repositorio de código". Eso describe lo que el formato puede soportar. Incluso allí, compartir es opcional: en el ejemplo de la especificación de dos personas en una sesión, "la memoria de Bob se clona solo si él elige compartirla con la sesión", y cada repositorio conserva "su propia propiedad, permisos e historial". La documentación del producto de Devin describe su propia memoria como personal, y las pautas de equipo van a través de las skills.

Asumir que si Devin lo aprendió una vez, estará allí el próximo mes. Dreaming elimina las notas que ninguna sesión ha utilizado. Eso mantiene la memoria enfocada, y significa que una decisión que importa rara vez, como por qué se abandonó una migración o qué requirió una revisión de cumplimiento, puede ser depurada entre los momentos en que se necesita.

Esperar que las ejecuciones programadas se beneficien de lo que Devin aprendió en tus sesiones. Las automatizaciones no leen ni escriben en la memoria personal.

Asumir que el formato Git significa que tu memoria se mueve contigo. Las propias instrucciones de prueba de la especificación señalan que "Las sesiones en la nube u otra máquina necesitan un remoto privado u otro almacenamiento persistente para llevar la memoria a través de las sesiones", y que "El inicio automático y el Dreaming programado no están incluidos" en la versión independiente. El formato es portátil. El comportamiento a su alrededor proviene de cada agente que lo implementa.

Ninguna de estas son críticas. Una memoria personal y autodepurable es un diseño sensato para un agente que trabaja junto a un desarrollador. El punto es saber qué tipo de contexto contiene, para que puedas colocar el resto en otro lugar.

Paso 1: Separa lo que Devin debe aprender sobre ti de lo que el equipo necesita

Haz una lista de lo que sueles decirle a Devin. Luego, divídelo.

El contexto personal pertenece a la memoria de Devin: cómo te gusta que se escriban las actualizaciones, qué herramientas prefieres, las correcciones que reflejan tu propio estilo. Deja que Devin aprenda esto mientras trabajas y corrígelo en la sesión cuando se equivoque.

El contexto de equipo necesita un hogar diferente: comandos de compilación y prueba que todos usan, límites de arquitectura, reglas de lanzamiento y las razones detrás de ellos. Si debe aplicarse a la sesión de un compañero de equipo o a una ejecución automatizada, la memoria personal es el lugar equivocado.

Una prueba útil es preguntarse: si un colega iniciara una sesión mañana en el mismo repositorio, ¿necesitaría esto? Si la respuesta es sí, es contexto de equipo.

Paso 2: Coloca los procedimientos en skills y archivos de repositorio, y mantén las razones junto a ellos

La propia guía de Devin indica que una skill "proporciona el procedimiento, y la memoria suministra el contexto para aplicarlo a tu trabajo". Por lo tanto, escribe procedimientos repetibles como skills, en .agents/skills/ en el repositorio o a nivel de organización a través de plugins. Mantén las convenciones del repositorio en archivos que Devin lea, como AGENTS.md.

Cuando escribas un procedimiento, incluye la razón del mismo. Una skill que le dice a Devin que ejecute la suite de integración antes de fusionar se cumplirá. Una skill que también explica el porqué, y qué salió mal la última vez que se omitió, sobrevivirá a la próxima refactorización. Las skills y la memoria sirven para propósitos diferentes, una distinción que se trata en por qué las skills de los agentes no son memoria.

Luego, revisa tus antiguos elementos de Knowledge a medida que se migren. Asegúrate de que cada uno llegue al alcance que deseabas y de que nada importante haya quedado únicamente en un activador que ya no se ejecuta.

Paso 3: Registra las decisiones que rara vez surgen pero que no deben perderse

Algunos contextos son demasiado importantes como para depender del uso reciente. Por qué se dividió un servicio. Qué proveedor fue rechazado y por qué. Qué requiere un contrato de cliente. Estos temas surgen pocas veces al año, que es exactamente el patrón que un proceso de depuración está diseñado para limpiar.

Consérvalos en un registro que mantengas deliberadamente, con una fecha y una fuente para cada uno. Las entradas de Devin ya enlazan de vuelta a la sesión de la que provinieron, un buen hábito que la procedencia de la memoria explica con más detalle. Aplica el mismo hábito a las decisiones que guardas tú mismo.

Cuando una decisión poco utilizada se vuelva relevante, tráela a la sesión de forma explícita. Devin podrá usarla y, si te importa personalmente, guardarla en la memoria nuevamente.

El Paso 3 describe una capa de contexto de equipo y de larga duración que no debería depender del agente de una sola persona. MemoryLake está diseñado para eso: memoria a largo plazo que escribes una vez y compartes entre las personas y los agentes que la necesitan.

Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de la unidad de memoria de Devin, de tus skills ni del almacenamiento de ningún proveedor.

Paso 1: Crea una clave API

Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake, de forma independiente a cualquier organización de Devin.

Paso 2: Sube tus primeras memorias

Comienza con las decisiones del Paso 3: las raras pero importantes, cada una con una fecha y una razón. Agrega el contexto de equipo del Paso 1 que no encaja de forma natural en una skill.

Paso 3: Conecta tu IA y agentes

Conecta a Devin y los demás agentes que usa tu equipo. Las mismas decisiones estarán disponibles para cada compañero de equipo y cada herramienta, incluidas las ejecuciones que se inician sin la memoria personal de nadie.

La primera diferencia es que la memoria de Devin puede hacer aquello para lo que es buena. Las preferencias personales y las correcciones se acumulan sin que nadie tenga que mantenerlas, y Dreaming las mantiene ordenadas.

La segunda es que el contexto de equipo deja de depender de quién ejecutó la sesión. Los procedimientos viven en las skills, las convenciones viven en el repositorio y las decisiones de larga duración viven en un registro compartido. La sesión de un compañero de equipo y una ejecución automatizada parten de la misma base. Para una configuración más amplia, consulta cómo configurar la memoria de IA compartida para tu equipo.

La tercera es que la depuración deja de ser un riesgo. Cuando las decisiones que importan rara vez se escriben en otro lugar, el hecho de que Dreaming elimine una nota no utilizada es una tarea de mantenimiento, no una pérdida.

La cuarta es la claridad sobre lo que se mueve. El formato de memoria es abierto, pero el conocimiento de tu equipo no debería tener que moverse con el agente de una sola persona. Los equipos que ejecutan varios agentes en paralelo se enfrentan a la misma pregunta a mayor escala, como se analiza en soluciones de memoria compartida para sistemas multiagente.

Deja que Devin aprenda tus preferencias personales. Para eso sirve la memoria.

Corrige la memoria en la sesión. La aplicación muestra los archivos de memoria como de solo lectura; pídele a Devin que olvide o recuerde.

Coloca los procedimientos de equipo en las skills. La memoria es personal; las skills se pueden configurar a nivel de organización.

Revisa el Knowledge migrado. Confirma que cada elemento haya llegado como una skill en el alcance correcto.

Informa a las automatizaciones de forma explícita. Las ejecuciones programadas y activadas no utilizan la memoria personal.

Conserva las decisiones poco comunes en un lugar duradero. Dreaming elimina las notas que ninguna sesión ha utilizado.

Compara diseños antes de asumir. Otros asistentes ahora también consolidan la memoria en segundo plano, como muestra el almacén de memoria dreaming de Claude, y cada uno define sus límites de manera diferente.

La nueva memoria de Devin está bien diseñada para lo que se propone hacer. Guarda preferencias, correcciones y lecciones como notas cortas en un repositorio Git, enlaza cada una a su origen y ejecuta un proceso diario de Dreaming que consolida, agrega y elimina. Cognition ha abierto el formato para que otros agentes puedan usarlo.

La documentación es clara sobre el alcance. La memoria es "personal para ti dentro de cada organización", las automatizaciones no la leen ni escriben en ella, y Dreaming elimina las notas que ninguna sesión ha utilizado. Las pautas de equipo pertenecen a las skills, y la función anterior de Knowledge de Devin se está migrando allí.

Así que deja que Devin aprenda sobre ti, coloca los procedimientos de equipo en skills y archivos de repositorio, y mantén las decisiones que rara vez surgen pero que no deben perderse en un registro al que todo tu equipo pueda acceder.