Cómo estructurar en capas Workspace y Project Knowledge de Lovable para que las sesiones largas sigan las instrucciones (Guía 2026)

Comencemos con el propósito de cada capa.

El Workspace knowledge se "utiliza mejor para reglas y convenciones que deben ser consistentes en múltiples proyectos". Definirlas una vez significa que "evita repetir las mismas instrucciones en el campo de conocimiento de cada proyecto". Solo los propietarios y administradores del espacio de trabajo pueden gestionarlo, lo que lo convierte en el hogar natural para las directrices de seguridad (guardrails): estándares de codificación, requisitos de prueba y reglas arquitectónicas.

El Project knowledge es editable por cualquier persona con permiso para editar el proyecto, y contiene lo que es específico de esa aplicación: su propósito, su esquema, su terminología de dominio y sus integraciones.

Ambos son contexto de fondo en cada mensaje. Lovable "lee su Project knowledge, Workspace knowledge y el código del proyecto para comprender cómo funciona su proyecto antes de generar ediciones", junto con el conocimiento de integración de los servicios conectados y los archivos de instrucciones en el repositorio.

Ahora los límites. Cada capa "admite hasta 10,000 caracteres". Existe exactamente un Workspace knowledge por espacio de trabajo: "no se pueden definir diferentes instrucciones a nivel de espacio de trabajo para subconjuntos de proyectos dentro del mismo espacio de trabajo". Y cuando las dos capas entran en conflicto, la resolución se documenta con una salvedad que vale la pena leer exactamente como está escrita: Lovable "se le anima a priorizar las instrucciones definidas en el Project knowledge, ya que se aplican específicamente al proyecto actual".

Animado, no garantizado. Esa redacción es inusualmente honesta y nos dice algo útil: la resolución de conflictos aquí es una preferencia expresada a un modelo, no una regla de precedencia impuesta por un cargador. Lo que significa que la forma confiable de manejar un conflicto es no tener ninguno.

Al juntar los límites de caracteres, el nivel único de espacio de trabajo, la flexibilidad de la resolución de conflictos y la advertencia sobre las sesiones largas, se obtiene una instrucción clara: el conocimiento es para las cosas que deben estar en segundo plano, ser breves y no superponerse. Todo lo demás necesita un canal diferente. Este es el mismo razonamiento por el cual una ventana de contexto larga es un mal sustituto para la memoria estructurada; la capacidad no es la limitación que realmente afecta.

Llenar ambos campos hasta el límite de caracteres. Este es el enfoque más común y funciona directamente en contra de la advertencia sobre sesiones largas. Más texto de fondo no significa mayor adherencia.

Colocar la misma regla en ambas capas "por si acaso". Esto crea el caso de conflicto sobre el que advierte la documentación, y lo resuelve con una preferencia en lugar de una regla. El consejo que se da es el contrario: "mantenga las reglas compartidas en el Workspace knowledge y los detalles específicos del proyecto en el Project knowledge".

Usar Workspace knowledge para un subconjunto de proyectos. Un espacio de trabajo tiene un único Workspace knowledge, y la documentación no describe ninguna vía para delimitarlo a algunos de los proyectos de un espacio de trabajo. Una regla que solo se aplica a tres de sus doce proyectos, escrita a nivel de espacio de trabajo, se aplicará a los doce.

Tratar el conocimiento como el lugar para las instrucciones de tareas. La documentación los separa claramente: "El conocimiento siempre se incluye como contexto de fondo para Lovable. Las habilidades (skills) se cargan bajo demanda cuando la solicitud coincide con la descripción de la habilidad". La guía es "usar el conocimiento para las reglas que se aplican a cada mensaje, y las habilidades para las instrucciones que solo importan para tipos específicos de tareas".

Asumir que una conversación larga se comporta como una corta. No es así, y eso está explícitamente indicado. El remedio no es un campo de conocimiento más largo.

Reiterar las reglas en el chat cuando el agente se desvía. Esto funciona para un mensaje y no le enseña nada. Si una regla deja de seguirse después de dos horas, la regla está en el canal equivocado.

Tres canales, tres funciones. La regla de clasificación no es la importancia, sino la frecuencia de relevancia y, luego, la durabilidad.

Paso 1: Divida cada regla según la frecuencia con la que se aplica

Tome todo lo que se encuentra actualmente en sus campos de conocimiento y coloque cada línea en uno de tres montones.

Se aplica a cada mensaje, en cada proyecto: estándares de codificación, requisitos de prueba, restricciones arquitectónicas. Esto es Workspace knowledge, y debería ser breve: una página, no diez mil caracteres.

Se aplica a cada mensaje, solo en este proyecto: qué hace la aplicación, la estructura del esquema, el vocabulario del dominio, qué integraciones existen. Esto es Project knowledge.

Se aplica solo cuando surge un tipo de tarea en particular: cómo agregar una migración, la lista de verificación de lanzamiento, cómo conectar un nuevo conector. Esto es una habilidad (skill). La prueba documentada es si la instrucción "es relevante en cada mensaje"; si no lo es, es una habilidad.

La mayoría de los equipos descubren que el tercer montón es el más grande y que la mayor parte estaba en un campo de conocimiento, desplazando a las reglas que realmente se aplican siempre. Sacarlo de ahí es la mayor mejora disponible aquí, y es el mismo tipo de organización que convierte la documentación del proyecto en algo que un agente realmente puede usar en lugar de un muro de texto.

Paso 2: Mueva al repositorio cualquier cosa que deba mantenerse en una sesión larga

Ahora revise lo que queda en los dos campos de conocimiento y hágase una pregunta más difícil para cada línea: ¿es necesario que esto se mantenga en la tercera hora de una sesión?

La mayoría no lo necesita. Una nota de vocabulario que se aplica de manera inconsistente al final de una conversación larga le costará un cambio de nombre. Algunas sí. Una restricción que evita la pérdida de datos, un requisito de seguridad, una regla sobre lo que nunca se debe confirmar (commit): estas son aquellas en las que una adherencia inconsistente resulta costosa.

Esas pertenecen a un archivo AGENTS.md en el nivel raíz, que las preguntas frecuentes describen como "siempre leído por el agente de Lovable independientemente de la duración de la sesión". La documentación también señala que los archivos de instrucciones como AGENTS.md o CLAUDE.md "también pueden proporcionar orientación al agente de Lovable", y enumera los archivos de instrucciones del repositorio entre las fuentes de contexto leídas en cada mensaje.

No se trata de abandonar los campos de conocimiento. Se trata de reconocer que un canal conlleva una advertencia documentada y otro conlleva una garantía documentada, y colocar sus pocas reglas no negociables en el que tiene la garantía.

Paso 3: Elimine cualquier superposición, luego pruebe las uniones

Con los montones clasificados, lea los tres canales uno al lado del otro y elimine cada duplicado. Si una regla está en el Workspace knowledge, no debería estar también en el Project knowledge. Si está en AGENTS.md, no debería estar en ninguno de los dos campos.

Este es el paso que hace que la resolución flexible de conflictos sea irrelevante. No necesita saber si el Project knowledge gana de manera confiable si nada en el Project knowledge contradice la capa de espacio de trabajo.

Luego, pruebe las uniones deliberadamente. Inicie un proyecto y solicite algo que rija la regla del espacio de trabajo, y verifique el resultado. Solicite algo que rija la regla del proyecto, y verifique. Luego, ejecute una sesión genuinamente larga (una hora de trabajo real) y vuelva a verificar la regla que movió a AGENTS.md. La advertencia se refiere específicamente a las conversaciones largas, por lo que una prueba de dos minutos no puede decirle nada al respecto.

Una nota práctica de la misma página: si actualiza el Workspace knowledge a mitad de la conversación, "Lovable utilizará las instrucciones actualizadas en los mensajes de seguimiento". Puede corregir una regla sin reiniciar, lo que hace que esta prueba sea económica.

La clasificación produce un pequeño conjunto de decisiones que son válidas independientemente de la herramienta en la que construya: la restricción arquitectónica, el vocabulario del dominio, la razón detrás de cada estándar. MemoryLake es un lugar para mantener ese conjunto de modo que no esté limitado al presupuesto de caracteres de un solo espacio de trabajo.

Usted mismo escribe las entradas, con sus propias palabras. No se lee, escribe ni elimina nada del Workspace knowledge de Lovable, del Project knowledge ni del almacenamiento de ningún proveedor.

Paso 1: Crear una clave API

Inicie sesión y genere una clave desde el panel de control. La clave es lo que permite a un agente leer las entradas que ha escrito, tanto en Lovable como en cualquier otra herramienta que utilice su equipo.

Paso 2: Subir sus primeras memorias

Agregue las decisiones y sus razones, un dato por entrada. Los campos de conocimiento contienen la instrucción; la entrada contiene el porqué de su existencia. Esa división es importante porque un presupuesto de diez mil caracteres le obliga a descartar el razonamiento, y el razonamiento es lo que hace que una regla sea revisable un año después.

Paso 3: Conectar su IA y agentes

Apunte sus agentes al espacio de trabajo. Las mismas decisiones establecidas estarán disponibles para un compañero de equipo que trabaje en una herramienta diferente, que es exactamente lo que desea cuando el administrador del espacio de trabajo es la única persona que puede editar el Workspace knowledge.

El primer cambio es que sus campos de conocimiento se vuelven más cortos, y la brevedad es el objetivo. La advertencia sobre las sesiones largas se debe a un exceso de contexto, por lo que una capa de fondo ligera es el remedio directo en lugar de una solución temporal.

El segundo es que la estructura de permisos comienza a trabajar a su favor. Solo los propietarios y administradores pueden editar el Workspace knowledge, lo que es adecuado para las directrices de seguridad (guardrails) pero inadecuado para la iteración. Cuando el montón de "cada mensaje en cada proyecto" es realmente pequeño, el cuello de botella del administrador deja de serlo, porque esa capa cambia raramente por diseño.

El tercero es que las reglas no negociables obtienen un canal con una garantía documentada. Eso es una mejora significativa en comparación con esperar que se mantenga una instrucción de fondo, y solo cuesta un archivo en el repositorio.

Hay un cuarto efecto que aparece después de un mes. Una vez que las habilidades contienen las instrucciones específicas de la tarea, se pueden revisar individualmente: puede leer la de las migraciones sin tener que leer todo lo demás. Nadie revisa un campo de conocimiento de diez mil caracteres, que es como sobreviven las reglas obsoletas. La misma dinámica explica por qué el conocimiento que un equipo realmente puede mantener supera a un montón más grande que nadie lee, y por qué vale la pena ser explícito sobre los activadores que deciden cuándo se aplica el conocimiento.

También vale la pena saber qué no está contemplado aquí. Los conectores de chat aportan contexto en tiempo real de las herramientas conectadas, y los conectores personalizados llevan sus propios archivos de conocimiento; ambos son fuentes de contexto adicionales en lugar de reemplazos para los dos campos. Agregar más fuentes no ayuda con una advertencia sobre sesiones largas relacionada con tener mucho contexto.

Trate el límite de caracteres como un techo al que no debe acercarse. Diez mil caracteres por campo es el máximo, no el objetivo. Una capa de espacio de trabajo que cabe en una sola pantalla se sigue de manera más confiable que una que llena todo el cuadro.

Un solo hogar por regla, garantizado al leer los tres canales juntos. La duplicación es lo que convierte una instrucción clara en un conflicto que se resuelve por preferencia.

Coloque las reglas a nivel de espacio de trabajo solo si se aplican a todos los proyectos. Un espacio de trabajo tiene un único Workspace knowledge, y la documentación no describe ningún mecanismo de delimitación por debajo de este. Una regla para tres proyectos pertenece a esos tres proyectos.

Reserve AGENTS.md para las reglas donde la inconsistencia sea costosa. Es el canal con la garantía documentada de duración de la sesión, y sigue siendo útil precisamente porque es corto.

Haga de la frecuencia el criterio de clasificación, no de la importancia. Lo importante pero ocasional pertenece a una habilidad. Colocarlo en el conocimiento solo porque es importante es la forma en que se llenan los campos de conocimiento.

Pruebe después de una sesión larga, no después de una corta. La advertencia documentada es específica para conversaciones largas. Una verificación rápida no confirma nada al respecto.

Escriba la razón en algún lugar donde el campo no pueda contenerla. Una regla sin una razón registrada se sigue hasta que alguien la cuestiona y luego se elimina, que es como los equipos pierden restricciones que aún necesitaban; el mismo fallo que un proyecto que pierde el conocimiento que nunca se escribió.

Vuelva a revisar después de un cambio de esquema. El Project knowledge que describe un esquema se vuelve obsoleto de forma silenciosa, y un dato obsoleto es peor que uno ausente porque es erróneo con total seguridad. Mantener el conocimiento del dominio en sí duradero y revisable es lo que hace que la actualización sea una tarea sencilla.

Lovable documenta dos capas de conocimiento, un límite de caracteres en cada una, un nivel único de espacio de trabajo, una preferencia de conflicto redactada de manera flexible y una advertencia de que las instrucciones pueden no seguirse de manera consistente en conversaciones muy largas. En la misma página, documenta un archivo de repositorio que siempre se lee independientemente de la duración de la sesión.

Tomados en conjunto, esos hechos describen un sistema de archivo en lugar de una limitación. Clasifique sus reglas según la frecuencia con la que se aplican: todo lo que va en cada mensaje en todas partes va en el Workspace knowledge, cada mensaje aquí va en el Project knowledge, y lo que ocurre a veces va en una habilidad. Luego, tome las pocas reglas donde la inconsistencia sería costosa y muévalas a un archivo AGENTS.md en el nivel raíz.

Elimine las superposiciones, pruebe las uniones y vuelva a probar después de una sesión lo suficientemente larga como para que sea relevante. Mantenga el razonamiento detrás de cada regla en algún lugar que sobreviva a un cambio de herramienta, porque la instrucción es configuración y la decisión es el activo; que es lo que los equipos descubren cuando mueven un proyecto de Lovable a otro lugar y descubren que las reglas se copian fácilmente pero el razonamiento no.