Cómo mantener el contexto de IA de tu equipo cuando alguien se va (2026)

Los chats se vuelven inaccesibles en el momento en que se elimina la cuenta

Este es el límite más estricto, y Anthropic lo documenta claramente: "Cuando se elimina a un usuario de su organización Team o Enterprise, los miembros restantes ya no podrán acceder a sus chats".

Esto también se aplica a los enlaces compartidos. El centro de ayuda incluso muestra el mensaje con el que se encontrarán los usuarios: "Conversación no encontrada. La conversación solicitada no existe o no tienes permiso para acceder a ella". Un enlace que alguien pegó en un ticket hace seis meses deja de funcionar.

Los datos no han desaparecido —"los datos del usuario eliminado se seguirán incluyendo en cualquier exportación de datos realizada por el Propietario Principal de su organización"— pero una exportación de administrador es un instrumento de cumplimiento, no una forma de responder a una pregunta un martes por la tarde.

Los proyectos privados siguen siendo privados después de que la persona se ha ido

La visibilidad del proyecto se decide cuando se crea, y la eliminación del usuario no la flexibiliza. "Si la visibilidad del proyecto se configuró como privada, otros miembros de la organización no podrán acceder a él una vez que el miembro del equipo haya sido eliminado de la cuenta".

La solución documentada traslada el trabajo a la persona que se va: "Si un miembro del equipo sabe que está trabajando en algo dentro de un proyecto privado que desea transferir, deberá ajustar los permisos del proyecto para que todos en la organización puedan editarlo, o bien invitar a usuarios específicos y otorgarles permisos de 'Puede editar'".

Lo cual es correcto como diseño pero frágil como proceso. Depende de que alguien en su última semana recuerde cuáles de sus proyectos necesitarán los demás.

La memoria personal es personal, a propósito

La memoria de Claude es un almacén por usuario. En los planes Team y Enterprise, un propietario controla si la función está disponible y luego, en palabras de Anthropic, "Los propietarios no pueden ver ni editar las memorias individuales de un usuario".

Eso es una protección de privacidad y debe seguir siéndolo. Pero significa que todo lo que Claude aprendió sobre cómo encaja el trabajo de esa persona —el vocabulario, las limitaciones recurrentes, las personas involucradas— no es conocimiento organizacional en ningún sentido recuperable. No hay ninguna vista desde la cual puedas heredarlo.

Las herramientas de programación se dividen de la misma manera, y la división está en las rutas

El patrón se repite una vez que sabes qué buscar, y generalmente es visible en la ruta del archivo.

Claude Code carga las instrucciones del proyecto desde ./CLAUDE.md, que su propia documentación describe como compartido con los "miembros del equipo a través del control de versiones". Las instrucciones personales viven en ~/.claude/CLAUDE.md, limitadas a "Solo tú (todos los proyectos)". Y la memoria automática —las notas que Claude escribe para sí mismo sobre correcciones y decisiones— se encuentra en ~/.claude/projects/<project>/memory/, con la advertencia explícita de que "es local de la máquina" y que "los archivos no se comparten entre máquinas ni entornos en la nube". El formateo de una laptop es el fin de esta memoria.

Cursor coloca las Reglas del Proyecto (Project Rules) en .cursor/rules y establece que "están bajo control de versiones". Las Reglas de Usuario (User Rules) son personales. Las Reglas de Equipo (Team Rules) se gestionan de forma centralizada y se "incluyen en el contexto del modelo para el Agente (Chat) en todos los repositorios y proyectos de ese equipo". Y Plan Mode tiene un comportamiento predeterminado que vale la pena conocer: "Los planes se guardan por defecto en tu directorio de inicio. Haz clic en 'Save to workspace' para moverlo a tu espacio de trabajo para futuras referencias, uso compartido en equipo y documentación". Cada plan para el cual nadie hizo clic en ese botón es un archivo personal.

Cline es inusualmente directo sobre su intención. Su guía es utilizar la configuración del proyecto "para el comportamiento compartido del equipo que debe viajar con el repositorio" y "Hacer commit de los archivos .cline/ que desees compartir con tu equipo". Las reglas globales se encuentran fuera del repositorio, en ~/.cline/ y ~/Documents/Cline/Rules.

Kiro separa la dirección del espacio de trabajo (steering) en .kiro/steering/ de la dirección global en ~/.kiro/steering/, y sus capas de memoria de Crew viven bajo ~/.kiro/crew/workspace/memory/. La memoria aprendida de Kiro Web está aún más acotada: "Solo tus comentarios, como el usuario que creó la tarea, influyen en lo que aprende el agente".

La regla, en las cuatro herramientas: en el repositorio, sobrevive. En un directorio de inicio o en una cuenta, se va.

Una entrevista de salida más larga. Útil, y captura lo que la persona piensa decir. No captura las cuarenta pequeñas limitaciones que dejó de notar hace años.

Exportar todo antes del último día. Esto te da un archivo, no un recurso. Anthropic señala que los datos del usuario eliminado permanecen en las exportaciones de la organización, y la mayoría de las herramientas tienen alguna ruta de exportación. Pero un archivo zip de conversaciones no es algo que nadie consulte cuando surge una duda.

Pedirles que compartan sus proyectos. Correcto, y es la solución documentada. También requiere que predigan cuál de sus proyectos privados necesitará alguien el próximo trimestre, durante su quincena más ocupada.

Mantener la cuenta abierta "por si acaso". Común y costoso, y por lo general crea un inicio de sesión sin propietario que ninguna lista de verificación de salida cubre.

Volver a agregarlos temporalmente. Esto sí funciona en Claude: "Si un miembro del equipo es eliminado y luego se vuelve a agregar a la misma organización usando la misma dirección de correo electrónico, se restaurarán los chats, proyectos y habilidades anteriores". Es una ruta de recuperación real para una emergencia. No es un plan, y es algo extraño de pedir a alguien que ya ha comenzado a trabajar en otro lugar.

Escribir más documentación. El instinto correcto con el objetivo equivocado. Los documentos responden a una página; una pregunta necesita una respuesta. La brecha entre ambos se cubre en cómo convertir los documentos de un proyecto en memoria de IA.

El replanteamiento que hace que esto sea manejable: no estás intentando recuperar el contexto de alguien después de que se va. Estás intentando asegurarte de que la parte que siempre fue organizacional estuviera viviendo en un lugar organizacional todo el tiempo.

Esa distinción también te mantiene del lado correcto de una línea que vale la pena respetar. La memoria personal, los proyectos privados y las habilidades no compartidas de un colega que se va son suyos —Anthropic es explícito en que las habilidades no compartidas "permanecen en su cuenta y siguen siendo recuperables", y que los propietarios no pueden leer las memorias individuales. Nada de eso debería ser un objetivo. Lo que quieres es el conocimiento del equipo: las decisiones, las limitaciones, las razones, las cosas que eran ciertas sobre el proyecto y no sobre la persona.

Eso es lo que almacena MemoryLake: una capa de memoria compartida que tus herramientas consultan, propiedad del espacio de trabajo en lugar de una cuenta individual. La configuración consta de tres pasos.

Paso 1: Crear una clave API

Inicia sesión y crea una clave API para el espacio de trabajo. La credencial pertenece al equipo, por lo que no se va con la persona.

Paso 2: Subir tus primeras memorias

Entradas cortas, una afirmación cada una. El paso de mayor valor es sentarse con una persona y escribir lo que solo ella sabe. Qué capturar:

Decisiones con la razón adjunta. "Hacemos fragmentación (sharding) por inquilino, no por región, porque la revisión de cumplimiento en el primer trimestre descartó la replicación entre regiones". La decisión está en el código; la razón está en la cabeza de una persona.

Enfoques ya rechazados aquí. La categoría más debatida una y otra vez, y la que no aparece en ningún documento ni mensaje de commit.

Hechos del entorno que nada anuncia. El trabajo que debe ejecutarse antes que el otro. El límite del proveedor que nadie documentó. La prueba que solo falla en la integración continua (CI).

Quién y qué, en términos sencillos. Qué equipo es propietario de lo que se rompe. Para qué cliente existe esa solución alternativa extraña. A qué se refiere realmente el nombre interno de ese servicio.

Las soluciones alternativas que son de soporte vital (load-bearing). Cada equipo tiene dos o tres. Son invisibles hasta que la persona que las mantiene se va.

Paso 3: Conectar tu IA y agentes

Conecta las herramientas que utiliza tu equipo. MemoryLake es accesible a través de MCP y de una API, por lo que los agentes nativos de MCP —entre ellos Claude Code, Cursor, Cline, Codex y OpenClaw— se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API. Lo que significa que la primera semana de una nueva contratación comienza con las mismas respuestas que tenía la persona que se fue, sin que nadie necesite acceder a su cuenta. Esa estructura de herramientas cruzadas es el tema de memoria entre herramientas para trabajadores del conocimiento.

Tres límites honestos. MemoryLake no puede leer, recuperar ni importar la memoria, los chats o los proyectos privados de nadie en el lado del proveedor —estos viven en el producto de cada proveedor bajo sus controles de acceso, y así debe ser. Solo contiene lo que tú o tus agentes introducen en él, por lo que el Paso 2 es un trabajo deliberado de una persona. Y no es una herramienta de cumplimiento de salida (offboarding): si necesitas un registro formal de la actividad de un empleado que se va, eso es una exportación de administrador bajo tu política de retención, no una capa de memoria.

La desvinculación (offboarding) deja de ser un ejercicio de extracción. El conocimiento ya estaba escrito en algún lugar propiedad del equipo.

Una laptop formateada deja de importar. La memoria automática local de la máquina nunca fue la única copia.

"¿Por qué lo hicimos de esta manera?" tiene una respuesta. Disponible para quien pregunte, no para quien supiera a quién preguntar.

La incorporación (onboarding) se acorta por una razón real. Una persona nueva consulta la misma capa, en lugar de interrumpir a cuatro personas.

Lo privado por defecto deja de ser una mina terrestre. No dependes de que alguien se acuerde de cambiar los permisos en su última semana.

La memoria del proveedor sigue siendo personal, y eso está bien. Dejaste de necesitar que fuera organizacional —la distinción general en lo que realmente significa la memoria persistente.

Audita dónde cae la línea en tu stack, una sola vez. Para cada herramienta, identifica qué está en el repositorio y qué está en un directorio de inicio o en una cuenta. Toma una hora y es todo el diagnóstico.

Establece la visibilidad del proyecto por defecto para la organización. Privado debería ser una decisión que alguien toma por una razón, no lo que sucede cuando nadie elige.

Haz de "Save to workspace" un hábito, no un rescate. Los planes de Cursor se guardan por defecto en un directorio de inicio. Al igual que muchas otras cosas.

Haz commit de la capa compartida. .cursor/rules, .cline/, .kiro/steering/, ./CLAUDE.md — todos estos están diseñados para estar dentro del repositorio. Úsalos de esa manera.

Escribe razones, no solo reglas. Una regla sobrevive en el control de versiones. La razón por la que existe generalmente no, y eso es lo que evita que la regla sea revertida el próximo año.

Haz el traspaso de conocimientos al inicio del período de preaviso, no al final. La última semana es para la logística.

Pregunta qué dejaron de notar. "¿Qué sabes que no esté escrito en ningún lado?" obtiene un encogimiento de hombros. "¿Qué tuviste que explicarle a la última persona nueva?" obtiene una lista.

Respeta lo que es suyo. La memoria personal, las habilidades no compartidas y los proyectos privados pertenecen al individuo. Pídeles que compartan lo que el equipo necesita; no trates su cuenta como un activo.

La razón por la que una partida cuesta tanto contexto no es la eliminación. Es el acceso. Los chats se vuelven inaccesibles en el momento en que se elimina la cuenta —Anthropic lo afirma directamente e incluso documenta el mensaje de error que la gente verá. Los proyectos privados siguen siendo privados, y la solución documentada requiere que la persona que se va cambie los permisos por sí misma. La memoria personal sigue siendo personal, y los propietarios no pueden leerla explícitamente. La memoria automática de Claude Code es local de la máquina y no sobrevive a una laptop. Los planes de Cursor se guardan por defecto en un directorio de inicio. La memoria de Crew de Kiro se encuentra bajo la ruta de inicio del usuario. Kiro Web solo aprende de los comentarios del propio creador de la tarea.

Cada uno de ellos es un diseño defendible, y varios son protecciones de privacidad que no querrías que se eliminaran. Juntos significan lo mismo: las partes del contexto de tu equipo que viven en el repositorio sobreviven a una partida, y las partes que viven en una cuenta o en una laptop no.

Así que haz que la división sea deliberada. Audita dónde cae la línea en cada herramienta que utilizas, establece por defecto la visibilidad de los proyectos para la organización, haz commit de la capa compartida y coloca las decisiones, razones y enfoques rechazados en una capa de memoria propiedad del espacio de trabajo. Hazlo mientras la gente todavía está allí —no porque alguien se vaya, sino porque ese es el único momento en que es fácil.