Cómo activar el Devin Knowledge adecuado en las sesiones que lo necesitan (Guía 2026)

Comencemos con el modelo de recuperación, porque es lo opuesto a cómo suelen funcionar los archivos de instrucciones. El propio consejo de Cognition lo dice directamente: "Devin recupera Knowledge cuando es relevante, no todo a la vez ni todo al principio. Asegúrate de que tu activador de recuperación sea muy relevante para el contenido".

Por lo tanto, la descripción del activador no es metadato. Es la puerta de acceso. La guía de inicio repite este punto detallando cómo debe ser un buen activador: "Knowledge se recupera en función del activador (Trigger) que configures. Cuanto más específico sea el activador (por ejemplo, a qué archivo, repositorio o tipo de tarea se aplica el Knowledge), mejor será la recuperación".

Este es un diseño genuinamente diferente al de un archivo de reglas que se concatena en cada prompt, y tiene una superficie de fallo distinta. Un archivo de reglas demasiado largo se diluye. Un elemento de Knowledge cuyo activador es vago se omite. La razón por la que los archivos de instrucciones se pasan por alto silenciosamente en toda la categoría es un problema relacionado, uno que abordamos en por qué los agentes ignoran tus archivos de instrucciones.

Hay tres razones más por las que un elemento puede no llegar a una sesión, todas documentadas.

No está fijado a nada. Cognition describe el fijado (pinning) como la anulación de la regla: "Sin fijar a ningún repositorio: el Knowledge solo se recupera cuando Devin decide que es relevante para tu contexto actual". Fíjalo a un repositorio específico y el comportamiento cambia por completo: "El Knowledge siempre se utiliza cuando Devin está trabajando en ese repositorio específico". Fíjalo a todos los repositorios y "El Knowledge se aplica automáticamente a cada repositorio en el que Devin esté trabajando en cualquier sesión". La guía de inicio hace explícita la regla de decisión: "Si deseas que Devin recupere la nota de Knowledge en cualquier momento que esté trabajando en una sesión, asegúrate de fijarla a todos los repositorios".

Está deshabilitado, posiblemente por una carpeta. Los elementos se pueden desactivar por persona: "Cada elemento de Knowledge se puede habilitar o deshabilitar individualmente por usuario. Deshabilitar un elemento de Knowledge evita que Devin lo recupere en tus sesiones, sin eliminarlo de la organización". Las carpetas heredan ese interruptor: "Cuando una carpeta está deshabilitada, todos los elementos de Knowledge dentro de ella se deshabilitan para tus sesiones". Un colega que ve que el elemento funciona no te está contradiciendo; simplemente tiene un conjunto de elementos habilitados diferente.

Está en un alcance diferente al que crees. Los nuevos elementos tienen un nivel por defecto: los elementos de Knowledge de la organización "son visibles para todos los miembros de la organización y son el alcance predeterminado para los nuevos elementos de Knowledge". Los elementos de Knowledge de la empresa "se aplican a todas las organizaciones de tu empresa", y subir de nivel requiere permisos: "La promoción requiere permisos de gestión de Knowledge de la empresa y solo está disponible para elementos de Knowledge creados por usuarios en organizaciones que pertenecen a una empresa".

Una cosa más que vale la pena saber antes de escribir nada: parte de tu Knowledge llegó sin ti. "Devin generará automáticamente Knowledge del repositorio basado en los README existentes, la estructura de archivos y el contenido de los repositorios conectados", con la advertencia de acceso adjunta: "si no le das acceso a Devin al repositorio, no generará ningún Knowledge asociado". El primer paso de inicio de Cognition es revisar ese material: "Revisa cualquier Knowledge autogenerado y verifica su (a) integridad y (b) precisión".

Y Devin sigue proponiendo más. "Devin sugerirá automáticamente Knowledge para recordar en función de tus comentarios en el chat", con la opción de editarlo o descartarlo en tus manos, y "también puede sugerir actualizaciones para elementos de Knowledge existentes, además de sugerir nuevos elementos de Knowledge".

Escribir un único elemento de Knowledge largo que lo cubra todo. Es comprensible, pero va en contra del modelo de recuperación por partida doble. La guía de Cognition dice lo contrario: "Crea Knowledge específico que esté dirigido a un flujo de trabajo o acción. Devin leerá todo el contenido de Knowledge, ¡así que mantén todo relevante y actualizado!" y "Divide tu Knowledge en elementos más pequeños siempre que sea posible". Un único elemento general necesita una descripción de activador que de alguna manera describa todo lo que contiene.

Mover el contenido a un playbook. Un playbook es una herramienta diferente, y Cognition es inusualmente directa sobre la división: "La mayoría de las mejores prácticas, guías de estilo u otras instrucciones específicas del proyecto deben compartirse con Devin utilizando Knowledge. Recomendamos leer la documentación sobre Knowledge antes de crear Playbooks, para comprender qué método se adapta mejor a tus necesidades". Un playbook, en sus palabras, "es como un prompt de sistema personalizado para una tarea repetitiva"; lo adjuntas cuando inicias una sesión. También señalan que no es la opción fácil: los playbooks "hoy en día requieren habilidad para escribirse".

Poner todo en un archivo Markdown en el repositorio. Es un instinto razonable, pero se topa con una barrera de extensión de archivo. Devin "extraerá y actualizará automáticamente el Knowledge basándose en archivos especializados en tu base de código, incluidos .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md y AGENTS.md", seguido del límite: "Ten en cuenta que Devin no extraerá automáticamente tipos de archivos más generales como .md". Un archivo nombrado según la convención que contiene se comporta de manera diferente a un archivo llamado notas.

Repetir la instrucción en el prompt cada vez. Este es el parche que oculta el problema. Funciona, por lo que nadie arregla el activador y la repetición nunca termina. El propio consejo de Cognition sobre lo que pertenece a Knowledge es el reflejo de esto: "Recomendamos incluir los aspectos de tus prompts o playbooks que te encuentres repitiendo regularmente".

Asumir que la sesión simplemente perdió el contexto. A veces es así, y ese es un problema diferente con una forma distinta, descrito en cuando Devin olvida el contexto de la tarea. Un elemento de Knowledge que nunca se recuperó nunca estuvo en la sesión para poder perderse.

Reemplazar Knowledge con habilidades (skills). También es una opción real con ventajas y desventajas reales, y una que mapeamos en mover las memorias de Devin a habilidades. No elimina la cuestión de la recuperación; la traslada.

Tres pasos. Los dos primeros toman diez minutos y convierten toda la función de probabilística a predecible.

Paso 1: Clasifica tus elementos en activados y siempre activos

Revisa lo que tienes y hazte una pregunta por elemento: ¿esto se aplica a un tipo específico de tarea o a cada sesión en un repositorio?

Los elementos específicos de tareas conservan su activador y obtienen una descripción más precisa. Sigue la propia sugerencia de Cognition sobre lo que nombra un buen activador: qué archivo, qué repositorio o qué tipo de tarea. "Despliegue" es una categoría. "Cualquier cosa que toque el pipeline de lanzamiento o los scripts de despliegue bajo el repositorio infra" es un activador.

En su lugar, los elementos para todo el repositorio se fijan. Fijar a un repositorio específico hace que el elemento se use siempre que Devin trabaje en ese repositorio, lo que elimina el activador de la ecuación. Reserva la opción de fijar a todos los repositorios para el pequeño conjunto de cosas que realmente se aplican en todas partes, ya que cada elemento fijado allí se lee en cada sesión.

Para el puñado de elementos que deseas invocar manualmente, asigna una macro: "un identificador corto que comienza con !" que escribes en el prompt. Cognition señala que las macros "solo pueden contener letras, números y guiones, y deben ser únicas dentro de tu organización".

Paso 2: Ejecuta una sesión y lee Accessed Knowledge

Este es el paso de verificación, y existe. Cognition lo documenta: "Devin te dirá en una sesión qué Knowledge utilizó", visible bajo el encabezado Accessed Knowledge en el chat de la sesión.

Elige una tarea para la que hayas escrito un elemento, ejecútala y observa. Si el elemento aparece en la lista, el activador funciona. Si no es así, ahora conoces la diferencia entre un problema de Knowledge y un problema de activador, que es la distinción que hace que todo lo demás sea solucionable. Luego verifica los factores de confusión obvios: ¿el elemento está habilitado para ti?, ¿está habilitada su carpeta?, ¿está en el alcance que esperabas?

Los modos de activación por reglas se están convirtiendo en una pieza estándar de la configuración de agentes en lugar de una peculiaridad, y comparar cómo otro proveedor modela la misma opción es una forma rápida de desarrollar la intuición; detallamos una en elegir modos de activación de reglas.

Paso 3: Mantén el razonamiento donde la recuperación no pueda decidir su destino

Knowledge es una capa de recuperación para un agente de programación, y es bueno en eso. Las decisiones detrás de las convenciones (lo que intentaste primero, lo que falló, por qué existe la regla en primer lugar) no se activan por tareas. Son las cosas que querrás leer tú mismo dentro de seis meses, posiblemente en una herramienta diferente.

Mantén eso en un lugar que las reglas de recuperación no gobiernen. Una convención cuya razón de ser solo está implícita en el contenido de un elemento es una convención que la siguiente persona revertirá.

La parte duradera necesita un hogar que no esté limitado por una descripción de activador. MemoryLake es un almacén en el que escribes esas decisiones a propósito, mantenido al margen de las reglas de recuperación de cualquier agente individual y legible desde cada asistente que conectes. Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de los sistemas de Cognition ni del almacén de ningún otro proveedor; tus elementos de Knowledge, playbooks y repositorios permanecen completamente bajo sus propios controles.

Paso 1: Crea una clave API

Genera una clave desde el panel de control. Es lo que permite que un agente en la nube, un asistente de terminal y un cliente de chat accedan al mismo conjunto de datos sin que cada uno tenga que mantener su propia versión.

Paso 2: Sube tus primeras memorias

Comienza con las razones en lugar de las reglas: por qué el orden de despliegue es el que es, qué enfoque se descartó y bajo qué argumentos, quién es el propietario del servicio y qué necesita que se le diga. Los elementos de Knowledge contienen la instrucción; rara vez contienen el argumento, y el argumento es lo que evita que la instrucción sea sobrescrita.

Paso 3: Conecta tu IA y agentes

Apunta tus herramientas a la capa para que esos datos se carguen al inicio del trabajo en lugar de depender de si una descripción coincidió. Luego pruébalo de la única manera que tiene sentido: pídele a un asistente diferente que te devuelva una de las decisiones. Si responde, tu razonamiento ya no estará dentro de la ruta de recuperación de un solo proveedor.

El primer cambio es que "Devin ignoró mi Knowledge" se convierte en una afirmación comprobable. Accessed Knowledge te dice qué se utilizó. O bien el elemento se recuperó o no, y la solución es diferente.

El segundo es que el fijado se convierte en una elección deliberada en lugar de un campo que omitiste. Fíjalo a un repositorio y la recuperación dejará de ser una decisión subjetiva para cualquier cosa que siempre se aplique allí.

El tercero es que tus elementos se vuelven más cortos. Una vez que la recuperación depende de un activador que describa el contenido, un elemento por flujo de trabajo es la forma natural, y Cognition recomienda exactamente eso.

El cuarto es que el Knowledge autogenerado y autosugerido deja de ser ruido de fondo. Devin genera Knowledge del repositorio a partir de READMEs, la estructura de archivos y el contenido del repositorio, y sugiere nuevos elementos a partir de tus comentarios en el chat. Revisar ambos es una tarea de mantenimiento, y la alternativa es un banco de elementos que nadie ha leído.

El quinto es que tu razonamiento duradero deja de depender de las extensiones de archivo y los niveles de alcance. El material que importa en todas las herramientas pertenece a una capa que te sigue, que es el argumento que presentamos en convertir documentos de proyectos en memoria de IA.

Escribe el activador antes del contenido. Si no puedes describir cuándo se debe recuperar un elemento, probablemente ese elemento deba dividirse en dos.

Un flujo de trabajo por elemento. La guía de Cognition es apuntar a un flujo de trabajo o acción y dividir siempre que sea posible, porque todo el elemento se lee una vez recuperado.

Fija lo que sea incondicional. Una convención para todo el repositorio no debería competir por la relevancia en cada sesión.

Usa una extensión de archivo especializada para el contexto dentro del repositorio. Devin extrae información de una lista específica de archivos especializados y no extrae automáticamente Markdown general, por lo que la extensión es parte del diseño.

Verifica la habilitación antes de reescribir nada. La deshabilitación por usuario y los interruptores a nivel de carpeta son la explicación más sencilla para un elemento que funciona para otra persona.

Revisa las sugerencias, no las aceptes en silencio. Devin propone tanto nuevos elementos como actualizaciones de los existentes, y son editables antes de guardarse por una razón.

Mantén el argumento fuera del elemento. La instrucción vive en Knowledge; la razón por la que existe debería vivir en un lugar que todas las herramientas puedan leer.

El sistema Knowledge de Devin está bien documentado y es ligeramente contraintuitivo. Los elementos no se cargan al inicio de una sesión; se recuperan cuando el trabajo está relacionado con sus activadores, y cada elemento requiere una descripción de activador. Esa única decisión de diseño explica la mayoría de los casos en los que un elemento bien escrito parece haber sido ignorado.

Cognition también documenta las formas de dejar de depender de la recuperación. Fija un elemento a un repositorio específico y siempre se utilizará cuando Devin trabaje allí. Fíjalo a todos los repositorios y se aplicará en cada sesión. Asigna una macro y podrás invocarlo por su nombre. And la vista Accessed Knowledge en el chat de la sesión te dice lo que Devin realmente utilizó, lo que convierte una sospecha en una comprobación.

Vale la pena recordar dos límites: Devin extrae Knowledge automáticamente de una lista específica de archivos especializados y no de Markdown general, y la deshabilitación por usuario o por carpeta significa que la sesión de tu colega y la tuya no están ejecutando el mismo conjunto.

Clasifica tus elementos en activados y siempre activos, verifica uno de cada uno con Accessed Knowledge y mantén el razonamiento detrás de las reglas en un lugar donde un activador de recuperación no pueda decidir si puedes verlo.