Cómo evitar que Devin pierda el contexto de las tareas entre ejecuciones (2026)

Knowledge está limitado a la base de código, no a la tarea

Vale la pena reiterarlo porque determina todo lo que viene después. Knowledge es "una colección de instrucciones y consejos que Devin puede consultar en todas las sesiones". Los ejemplos documentados son todos materiales duraderos a nivel de repositorio: "prácticas de conformidad de código, flujos de trabajo de despliegue, convenciones de nomenclatura de PR, flujos de trabajo de pruebas, cómo interactuar con herramientas propietarias y más".

Ninguno de ellos es "lo que descubrimos sobre este error el martes pasado". Los hallazgos a nivel de tarea no entran en el alcance de este almacenamiento, lo que significa que solo persisten si los promueves deliberadamente, o si los escribes en otro lugar.

El Knowledge no anclado solo se usa cuando se activa

La segunda causa más importante, y es un detalle de configuración que la gente suele pasar por alto. "Knowledge se recupera en función del disparador (Trigger) que configures. Cuanto más específico sea el disparador (por ejemplo, a qué archivo, repositorio o tipo de tarea se aplica el Knowledge), mejor será la recuperación".

Y de la lista de mejores prácticas: "Si deseas que Devin recupere la nota de Knowledge en cualquier momento que esté trabajando en una sesión, asegúrate de anclarla (pin) a todos los repositorios. De lo contrario, puedes anclarla a un repositorio específico si la información solo es relevante en ese contexto. Si Knowledge no está anclado, solo se usará cuando se active, así que asegúrate de que la descripción del disparador (Trigger Description) sea clara."

Por lo tanto, una nota de Knowledge que escribiste y nunca anclaste se queda detrás de una descripción de disparador. Si esa descripción es vaga, es posible que simplemente nunca se active. La nota existe, pero no llega a la sesión. Esta es la misma familia de fallos descrita en por qué los agentes ignoran los archivos de instrucciones que escribiste.

Hay una funcionalidad genuinamente útil aquí, y no se aprovecha lo suficiente: "Devin te dirá en una sesión qué Knowledge utilizó; puedes ver esto bajo 'Accessed Knowledge' en el chat de la sesión". Esa es una respuesta directa a "¿realmente leyó mi nota?" — compruébalo antes de asumir cualquier cosa.

El Knowledge autogenerado es un punto de partida, no un registro

Devin se inicializa por ti: "Devin generará automáticamente el conocimiento del repositorio basándose en los README existentes, la estructura de archivos y el contenido de los repositorios conectados".

Esto es útil, y significa que tu base de Knowledge comienza describiendo lo que dice tu README, el cual, en la mayoría de los repositorios, está parcialmente desactualizado. La primera mejor práctica documentada es exactamente esta: "Revisa cualquier Knowledge autogenerado y verifica su (a) integridad y (b) precisión".

Omitir ese paso te deja con un contexto seguro, recuperable y ligeramente incorrecto. Eso es peor que un almacenamiento vacío, porque se termina utilizando.

Devin lee archivos especializados y omite los .md normales

Una regla precisa y fácil de pasar por alto: "Devin extraerá y actualizará automáticamente el Knowledge basándose en archivos especializados en tu base de código, incluyendo .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md y AGENTS.md. Ten en cuenta que Devin no extraerá automáticamente tipos de archivos más generales como .md."

Esto tiene dos consecuencias. Primero, si tus convenciones viven en docs/engineering-standards.md, Devin no las extraerá automáticamente. La recomendación documentada es solucionar esto: "Si no tienes un archivo de documentación especializado centralizado en tu base de código, definitivamente recomendamos configurar uno con una extensión de archivo especializada".

Segundo —y esta es la sorpresa agradable—, si tu repositorio ya tiene CLAUDE.md, AGENTS.md o .cursorrules de otra herramienta, Devin los detectará. Los archivos de instrucciones que escribiste para un agente diferente ya están haciendo su trabajo aquí.

Sin acceso al repositorio no hay Knowledge

Indicado como una advertencia clara: "Ten en cuenta que si no le das acceso a Devin al repositorio, no generará ningún Knowledge asociado". Si un repositorio en particular se siente como un lienzo en blanco para Devin, verifica el acceso antes de comprobar cualquier otra cosa.

Volver a informar (re-briefing) a Devin al inicio de cada sesión. Funciona, y es pagar el costo total del problema de nuevo cada vez — el bucle descrito en cómo dejar de volver a explicar el contexto a la IA.

Escribir cada hallazgo de tarea en Knowledge. Comprensible, pero llena un almacenamiento a nivel de base de código con ruido a nivel de tarea, lo que degrada la recuperación del material que realmente pertenece allí.

Anclar todo a todos los repositorios. Garantiza la recuperación pero introduce contexto no relacionado en cada sesión. Es la solución tosca para un control que tiene un ajuste más fino.

Dejar el Knowledge autogenerado sin revisar. El atajo más común, que convierte un README obsoleto en una guía que parece autoritativa.

Mantener un documento continuo de decisiones en el repositorio como notes.md. Instinto razonable, extensión incorrecta — Devin no extraerá automáticamente archivos .md generales.

Asumir que las preferencias de codificación se mantienen solas entre ejecuciones. Se mantienen si están en Knowledge y son accesibles. Ese es el caso detrás de por qué Devin olvida el estilo de codificación.

Dos tareas. Hacer que Knowledge funcione correctamente para el material a nivel de base de código y dar al razonamiento a nivel de tarea un hogar que no sea una sesión.

Revisa el Knowledge autogenerado hoy mismo. Integridad y precisión, tal como indican las instrucciones. Elimina cualquier cosa que describa un sistema que hayas retirado. Las entradas obsoletas se recuperan con la misma confianza que las correctas.

Decide entre anclar o usar disparadores para cada nota. ¿Debería aplicarse siempre? Anclala a todos los repositorios. ¿Solo es relevante en un repositorio? Anclala allí. ¿Es genuinamente situacional? Déjala con disparador — y luego escribe una descripción de disparador lo suficientemente específica como para que se active, nombrando el archivo, repositorio o tipo de tarea al que se aplica.

Crea un archivo de documentación especializado si no tienes uno. AGENTS.md es una buena opción predeterminada: Devin lo extrae automáticamente y otros agentes también lo leen. Si ya mantienes CLAUDE.md o .cursorrules, ya estás cubierto — esos están en la lista.

Usa "Accessed Knowledge" como tu bucle de retroalimentación. Después de una sesión, observa qué utilizó realmente Devin. Si una nota que esperabas no aparece en la lista, el problema es el disparador o el anclaje, no la redacción.

Verifica el acceso al repositorio en cualquier cosa que parezca vacía. Sin acceso, no hay Knowledge generado.

Eso hace que el contexto a nivel de base de código sea confiable. Sin embargo, todavía queda la categoría que la documentación sitúa explícitamente fuera de Knowledge: el razonamiento a nivel de tarea. Lo que intentaste en la última ejecución y por qué falló. La restricción que descubriste a mitad de camino. El enfoque que evaluaste y rechazaste. Promover todo eso a Knowledge es un error: no es a nivel de base de código y diluye la recuperación de lo que sí lo es.

Ahí es donde entra MemoryLake: mantiene el razonamiento de tareas y proyectos en una capa que tus agentes pueden consultar, separada del almacenamiento a nivel de repositorio. La configuración consta de tres pasos.

Paso 1: Crear una clave de API

Inicia sesión en MemoryLake y crea una clave de API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. Las categorías que se amortizan más rápido con un agente autónomo:

Qué se intentó y se rechazó, con el motivo. El tipo de entrada de mayor valor cuando el agente trabaja sin supervisión. Sin ella, la ejecución tres vuelve a deducir lo que la ejecución uno ya desmintió — y gasta tiempo real haciéndolo.

Hallazgos de una ejecución que sobreviven a la misma. "Los datos semilla de staging no tienen filas después de 2024, por lo que las pruebas de rango de fechas pasan localmente pero fallan allí". Eso no es un consejo a nivel de base de código y tampoco es algo de una sola vez.

Restricciones que solo se hicieron visibles a mitad de la tarea. Límites de velocidad, una dependencia que se comporta de manera diferente a la documentada, un requisito de orden que nadie escribió.

Decisiones y la restricción detrás de ellas. Una convención puede ir en Knowledge. El argumento a favor de ella pertenece a un lugar donde pueda ser recuperado y analizado.

Paso 3: Conecta tu IA y agentes

Conecta las herramientas que utilizas. MemoryLake es accesible a través de MCP y de una API, por lo que los agentes nativos de MCP —incluidos Claude Code, Codex y OpenClaw— se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API.

Tres límites honestos. MemoryLake no escribe en el Knowledge de Devin y no lo reemplaza — Knowledge es el lugar adecuado para el contexto a nivel de base de código y debes configurarlo correctamente. Solo contiene lo que tú o tus agentes escriben en él, por lo que el Paso 2 requiere trabajo real. Y no garantiza el cumplimiento: el contexto recuperable no es una configuración obligatoria.

La ejecución tres deja de repetir la ejecución uno. Los enfoques rechazados quedan registrados, por lo que un agente sin supervisión no pasa una sesión redescubriéndolos.

Knowledge se mantiene limpio y la recuperación sigue siendo precisa. El material a nivel de base de código en el almacenamiento a nivel de base de código significa que las descripciones de los disparadores coinciden con menos elementos, pero más relevantes.

"Accessed Knowledge" se vuelve informativo. Cuando el almacenamiento no es un vertedero, ver qué se utilizó realmente te dice algo.

Los archivos de instrucciones hacen doble trabajo. AGENTS.md y CLAUDE.md alimentan el Knowledge de Devin automáticamente y son leídos por otros agentes, por lo que un solo archivo sirve para varias herramientas.

El razonamiento de la tarea sobrevive a un cambio de herramienta. Lo que aprendiste sobre tu propio sistema no es específico de Devin — el concepto cubierto en memoria episódica para agentes de IA.

Mantén Knowledge a nivel de base de código. Es su propósito documentado. Los hallazgos de las tareas van a otra parte o degradarán el almacenamiento.

Ancla lo que siempre deba aplicarse. El Knowledge no anclado solo se usa cuando se activa — ese es el comportamiento documentado, no un error que debas evitar.

Escribe descripciones de disparadores que nombren algo específico. Archivo, repositorio o tipo de tarea. Los disparadores específicos recuperan mejor; la documentación lo dice directamente.

Revisa el Knowledge autogenerado antes de confiar en él. Se deriva de los README, la estructura de archivos y el contenido del repositorio, y estos envejecen. Verifica su integridad y precisión.

Usa una extensión de archivo especializada. .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md o AGENTS.md — no un .md normal, que no se extrae automáticamente.

Revisa "Accessed Knowledge" después de sesiones importantes. Es el diagnóstico más económico disponible y la mayoría de la gente nunca lo abre.

Registra los rechazos de inmediato. El momento en que se descarta un enfoque es el único momento en que el motivo está completamente en tu cabeza.

Pon fecha a cualquier aspecto del entorno. Las peculiaridades de staging y los límites de velocidad cambian. Una entrada sin fecha se convierte en una respuesta incorrecta en el futuro — el problema general descrito en qué es y qué no es la memoria de la IA.

El sistema de Knowledge de Devin sí hace persistir el contexto entre sesiones, y su documentación es precisa sobre el límite: es para el contexto a nivel de base de código en lugar de a nivel de tarea, se recupera mediante el disparador que configures a menos que lo ancles, se genera automáticamente a partir de material que se espera que revises y se extrae de archivos especializados en lugar de archivos .md generales.

Configura eso correctamente y la mitad correspondiente al nivel de repositorio dejará de ser un problema. Luego, trata el razonamiento a nivel de tarea como su propia categoría —rechazos, descubrimientos a mitad de la tarea, restricciones del entorno, el argumento detrás de cada decisión— y mantenlo en una capa que tus agentes puedan consultar. Esa es la diferencia entre un agente que comienza cada ejecución como un nuevo empleado competente y uno que comienza cada ejecución como el mismo nuevo empleado en su primer día.