Por qué Replit empieza de cero en tu proyecto
La memoria está desactivada hasta que la enciendas
Abre Settings, selecciona Customization y luego la pestaña Memory. Según la documentación, ahí es donde puedes "activar la memoria, desactivarla más tarde, elegir si deseas compartirla con colaboradores y ver o actualizar el Memory file". Se especifican explícitamente dos valores predeterminados: "Las memorias son privadas por defecto y el uso compartido con colaboradores está desactivado por defecto".
Así que, por diseño, un Workspace nuevo no recuerda nada. Vale la pena confirmarlo antes de concluir que algo más está fallando.
Hay tres alcances de memoria y no se superponen
Una vez activada la memoria, lo que se retiene depende del alcance en el que caiga el contenido. La documentación distingue:
User memory captura "preferencias duraderas del espacio de trabajo y estilo de trabajo", y "pertenece a un creador y espacio de trabajo".
Project memory captura "convenciones, advertencias y correcciones". "Permanece en un solo proyecto y se recupera cuando es relevante".
Custom memory es "el contexto que defines con sus propios ajustes de acceso y visibilidad", y "sigue los ajustes de acceso y visibilidad definidos para él".
Si lees esto como una tabla de enrutamiento, muchas cosas quedan claras. Una convención que estableciste mientras trabajabas en un proyecto no te sigue al siguiente: la memoria del proyecto se queda con su proyecto. Una preferencia de estilo de trabajo está vinculada a un creador y a un Workspace. Si esperabas que alguna de las dos fuera universal, la brecha que estás viendo es el límite documentado en lugar de un fallo.
Las memorias contienen contexto, no instrucciones
Esta es la frase que redefine toda la función: "Las memorias retienen contexto útil, no instrucciones ejecutables".
Y también se establece la precedencia: "Tu solicitud explícita y las Custom Instructions tienen prioridad sobre la memoria".
Por lo tanto, la memoria es evidencia que Replit consulta, no una regla que obedece. Si has estado escribiendo directivas en la memoria —"usar siempre el patrón de repositorio", "nunca instalar nuevas dependencias sin preguntar"— has colocado una regla en la capa que no es para reglas. La documentación llama a las memorias "evidencia contextual, no instrucciones ejecutables". Estas pertenecen a las Custom Instructions, que "Replit utiliza en todos los proyectos y sesiones de ese Workspace" y que, notablemente, "tú las escribes y Replit no las modifica".
Los proyectos compartidos se excluyen a menos que vuelvas a activarlos
El valor predeterminado que sorprende a los equipos: "Por defecto, Replit no utiliza tu memoria en proyectos que otros colaboradores pueden editar".
Este es un diseño de privacidad sensato —tu contexto acumulado no se filtra a un espacio en el que trabajan otras personas— y significa que los proyectos que más probablemente necesitan contexto compartido son los que no reciben nada de él. El interruptor documentado está en el mismo lugar: "Actívalo en Settings → Customization → Memory cuando quieras que Replit use la memoria en proyectos que otros colaboradores pueden editar".
Si el proyecto de tu equipo parece tener amnesia mientras que tu proyecto individual funciona bien, casi seguro que esta es la razón.
La memoria excluye deliberadamente algunas categorías
También vale la pena saberlo para no esperar algo que no va a llegar. Según la documentación, "las memorias no retienen información personal", y específicamente no "rasgos sensibles, datos personales de terceros, credenciales o datos confidenciales del proyecto". Replit describe el manejo seguro de la memoria porque se deriva de la actividad del espacio de trabajo.
Esa es la decisión correcta, y significa que cualquier cosa en esas categorías necesita un hogar que tú controles.
Las Custom Instructions y las Skills son capas separadas con tareas separadas
Replit publica una tabla de decisiones, y es la declaración más clara del modelo:
| Quién lo mantiene | Cuándo lo usa Replit | Ideal para | |
|---|---|---|---|
| Custom Instructions | Tú o tu equipo | Siempre, en todas las sesiones | Preferencias estables y reglas que deseas aplicar de manera consistente |
| Skills | Tú o tu equipo | Cuando es relevante para una tarea en particular | Procedimientos repetibles, flujos de trabajo y material de apoyo |
| Memories | Replit, con tu supervisión | Cuando el contexto relevante es útil | Evitar la repetición de preferencias útiles de trabajos anteriores |
Vale la pena tomar la guía que sigue al pie de la letra. Las Custom Instructions son para "una regla que debe mantenerse activa en todo tu Workspace, como una biblioteca aprobada o un requisito de manejo de datos" —se gestionan en Workspace Settings → Customization y se limitan a "un pequeño conjunto de pautas que siempre son verdaderas", lo suficientemente cortas como para que "dejen espacio para el trabajo en curso". Las Skills son para "un enfoque reutilizable para un tipo específico de trabajo", porque "el conocimiento procedimental estable pertenece a las Skills". Y MCP sirve para conectar herramientas externas "en lugar de proporcionar orientación o contexto".
Tres capas, tres mantenedores, tres condiciones de activación. La mayoría de los reportes de "olvidó mi proyecto" se deben a un elemento archivado bajo el encabezado incorrecto.
Lo que la gente intenta
Volver a describir el proyecto al inicio de cada conversación. Funciona, indefinidamente, con el mismo costo: el bucle descrito en cómo dejar de explicar el contexto a la IA una y otra vez.
Escribir reglas en el Memory file. Comprensible, dado que es editable. Sin embargo, las memorias retienen contexto en lugar de instrucciones ejecutables, y tu solicitud explícita y las Custom Instructions tienen prioridad de todos modos.
Poner todo en las Custom Instructions. Están siempre activas en todo el Workspace, que es exactamente la razón por la que la documentación recomienda mantenerlas cortas y específicas. Un bloque de instrucciones largo compite con el trabajo que se tiene enfrente.
Crear un solo proyecto para todo el trabajo. Te permite compartir la memoria del proyecto a costa de perder la separación que deseabas, y el contexto retenido se convierte en una mezcla confusa entre desarrollos no relacionados.
Asumir que los proyectos compartidos heredan tu memoria. No lo hacen por defecto. Esto es una configuración, no un error.
Mantener un documento de decisiones en el repositorio. El instinto correcto pero el contenedor equivocado: nada lo lee a menos que algo apunte allí. Ese es el panorama general en por qué Replit Agent olvida el historial de tareas.
La solución: activa la memoria y luego organiza cada cosa en su propia capa
Quince minutos de organización y la diferencia es enorme.
Activa la memoria. Settings → Customization → Memory. Mientras estés allí, revisa el Memory file —puedes verlo y actualizarlo directamente— y elimina cualquier cosa que ya no sea cierta.
Decide deliberadamente sobre el uso compartido con colaboradores. Si tu equipo trabaja en proyectos que otros pueden editar y quieres que Replit use tu memoria allí, activa el uso compartido. Si no, déjalo desactivado y acepta que esos proyectos deben obtener su contexto de una capa que sí esté compartida.
Mueve las reglas a las Custom Instructions. Bibliotecas aprobadas, requisitos de seguridad, políticas de manejo de datos: las cosas que siempre son verdaderas. Escritas por ti, sin modificaciones de Replit, aplicadas en todos los proyectos y sesiones del Workspace. Mantén la lista pequeña.
Mueve los procedimientos a las Skills. Preparación de lanzamientos, listas de verificación de revisión, cualquier proceso de varios pasos que repitas. El conocimiento procedimental estable pertenece allí, invocado cuando es relevante para la tarea.
Deja que la memoria haga su verdadero trabajo. Preferencias y estilo de trabajo que puede aprender de tareas anteriores, para que dejes de repetirlos. Supervísala en lugar de redactarla tú mismo.
Eso cubre la dirección y el procedimiento. Lo que ninguna capa contiene es el razonamiento detrás de tu proyecto: la restricción que hace que una elección extraña sea la correcta, el enfoque que probaste en la segunda semana y que falló, el dato de dominio que abarca cada proyecto que construyes. Las Custom Instructions están pensadas para ser cortas. La memoria del proyecto se queda con su proyecto. Y las categorías que Replit excluye deliberadamente necesitan otro lugar de todos modos.
Para eso está MemoryLake: tu conocimiento duradero en una capa de la que leen tus herramientas, independiente de un Workspace o de un proyecto. La configuración consta de tres pasos.
Paso 1: Crea una clave API
Inicia sesión en MemoryLake y crea una clave API. Una sola credencial para todas las herramientas que conectes.
Paso 2: Sube tus primeras memorias
Entradas cortas, una afirmación por cada una. Lo que se gana su lugar:
Decisiones con su restricción asociada. "La autenticación se mantiene del lado del servidor porque el paquete del cliente ya supera el presupuesto". Una preferencia no puede soportar eso; una entrada de memoria sí.
Qué falló y por qué. Las advertencias que la memoria del proyecto captura bien, escritas una sola vez en un lugar que no está limitado a un solo proyecto.
Conocimiento que abarca varios proyectos. Vocabulario de dominio, estándares, peculiaridades de integración. La memoria del proyecto se queda con su proyecto por diseño; esto no pertenece a ninguno de ellos en particular.
Requisitos que no puedes poner en la memoria. Las restricciones confidenciales o relacionadas con credenciales que la memoria de Replit excluye deliberadamente aún deben estar en algún lugar donde tus agentes puedan leerlas.
Paso 3: Conecta tu IA y agentes
Conecta las herramientas que utilizas. Se puede acceder a MemoryLake a través de MCP y de una API, por lo que los agentes nativos de MCP —entre ellos 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 Memory file de Replit y no es un sustituto de las Custom Instructions o las Skills (que son la forma en que diriges al agente dentro de Replit). Solo contiene lo que tú o tus agentes escriben en él, por lo que el Paso 2 es manual. Y no es un gestor de secretos: las credenciales pertenecen a un almacén de secretos, no a la memoria de ningún tipo.
Lo que esto cambia en la práctica
Un nuevo proyecto comienza informado. La memoria del proyecto no viaja entre proyectos. El conocimiento guardado fuera de ellos sí lo hace, por lo que el desarrollo número cuatro comienza donde terminó el número tres.
Los proyectos de equipo dejan de ser los amnésicos. Ya sea que actives o no el uso compartido con colaboradores, el conocimiento compartido en una capa externa está disponible para todos los que trabajan allí.
Las Custom Instructions vuelven a ser cortas. Cuando el contenido sustancial vive en otro lugar, la lista siempre activa es un puñado de reglas genuinas en lugar de un documento que compite con tu prompt.
Las categorías excluidas obtienen un hogar. La memoria omite deliberadamente los datos confidenciales del proyecto. Esas restricciones siguen dando forma al trabajo, y ahora están escritas en un lugar donde el agente puede leerlas.
Tu contexto no tiene la forma exclusiva de Replit. El mismo razonamiento es útil en Cursor o Claude Code, el concepto que se aborda en lo que realmente significa la memoria persistente.
Buenas prácticas para el contexto de Replit Agent
Verifica primero el interruptor de Memory. Es opcional (opt-in). Todo lo demás depende de eso.
Organiza por permanencia, no por conveniencia. Siempre verdadero → Custom Instructions. Procedimiento repetible → Skills. Aprendido de trabajos anteriores → Memory.
Nunca escribas reglas en la memoria. Retiene contexto en lugar de instrucciones ejecutables, y tu solicitud explícita y las Custom Instructions tienen prioridad de todos modos.
Mantén las Custom Instructions cortas. La documentación recomienda dejar espacio para el trabajo en curso. El objetivo es un pequeño conjunto de pautas que siempre sean verdaderas.
Decide el uso compartido con colaboradores de manera intencionada. Por defecto está desactivado. Define qué opción prefieres y por qué.
Revisa el Memory file periódicamente. Se puede ver y editar. Una preferencia desactualizada es peor que una inexistente.
Don't put secrets anywhere near memory. Replit excluye credenciales y datos confidenciales deliberadamente; utiliza un almacén de secretos.
Escribe la razón junto a la regla. Una regla sobrevive a un proyecto. La razón sobrevive a los siguientes cuatro: el punto general en por qué RAG no es memoria.
Conclusión
Replit Agent sí retiene el contexto, y la razón por la que parece no hacerlo generalmente se reduce a cuatro hechos documentados: la memoria es opcional (opt-in), las memorias retienen contexto en lugar de instrucciones ejecutables, los tres alcances de la memoria están limitados a un creador, un proyecto o tus propios ajustes de visibilidad, y los proyectos compartidos están excluidos por defecto.
Activa la memoria, archiva las reglas en las Custom Instructions, coloca los procedimientos en las Skills y toma la decisión de compartir con colaboradores de manera consciente. Luego, toma la capa para la cual ninguna de ellas está diseñada —decisiones y sus restricciones, las cosas que fallaron, el conocimiento de dominio que sobrevive a cualquier proyecto individual— y guárdala en un lugar donde tus agentes puedan consultarla. Eso es lo que hace que el quinto proyecto esté tan bien informado al final como lo estuvo el primero.