Cómo hacer que los Cloud Agents de Warp recuerden ejecuciones anteriores (2026)

Una sesión limpia es el contrato, no un fallo

Warp establece la garantía dos veces, una en la referencia y otra en la guía de inicio rápido, donde la redacción es aún más explícita: "Cada ejecución inicia una sesión limpia y aislada sin transferencia de estado de ejecuciones anteriores, y cada ejecución es rastreable y revisable en la aplicación web Oz".

El resto del modelo de ejecución explica por qué esto es deseable en lugar de simplemente conveniente. "Las ejecuciones se realizan automáticamente sin intervención humana". Y "Si una ejecución programada falla, no bloquea las ejecuciones futuras. Cada ejecución es independiente". La independencia es la propiedad que hace que la programación desatendida sea segura: una ejecución que heredara un estado corrupto de la semana pasada lo propagaría silenciosamente, para siempre, sin que nadie lo vigilara.

Así que el aislamiento es deliberado. Lo que falta no es el aislamiento, sino un canal: un lugar donde una ejecución pueda depositar una conclusión que la siguiente ejecución tenga permitido leer.

El entorno es repetibilidad, no recuerdo

El lugar obvio para buscar es el entorno, y aquí es donde la mayoría de los equipos pierden un día. La definición de Warp lo descarta en una sola frase: "Los entornos describen cómo ejecuta un agente una tarea, no qué hace".

Un entorno agrupa una imagen de Docker, uno o más repositorios que el agente clona, comandos de configuración, variables de entorno y Agent Secrets. Su propósito es la mismidad: "Ofrecen a los agentes en la nube el mismo contenedor, repositorios y configuración cada vez que se ejecutan". Y luego la línea que cierra la puerta: "Juntos, estos ajustes crean un espacio de trabajo limpio para cada ejecución".

Ese es exactamente el diseño correcto para un entorno de compilación y exactamente el incorrecto para una memoria. El mismo punto de partida cada vez es lo opuesto al conocimiento acumulado. La cláusula "a menos que tu entorno persista los datos explícitamente" es real, pero significa que estás configurando tu propia persistencia (una base de datos, un repositorio en el que el agente realiza commits, un almacenamiento externo), no que el entorno recuerde algo por sí mismo.

Warp enumera un espacio adyacente, el contexto por ejecución, que "Suministra datos específicos de la tarea, como un hilo de Slack, metadatos de PR o registros de CI". Ese es el payload del disparador, no un almacenamiento, y está limitado a la ejecución que lo recibió.

El traspaso (handoff) reanuda una ejecución, con tres condiciones previas

Handoff es el mecanismo que la gente encuentra a continuación, y es realmente bueno en lo que hace. El traspaso de nube a nube te permite enviar un seguimiento a una ejecución finalizada, y Warp es preciso sobre lo que viene con él: "Handoff preserva suficiente estado para que el agente receptor pueda reanudar el trabajo, no solo leer sobre él". El seguimiento aterriza en "La misma conversación", y "Los cambios en el repositorio de la sesión anterior (rastreados y no rastreados) se restauran antes de que el agente responda a tu seguimiento". La identidad de la ejecución también sobrevive: el ID, la tarea, el creador, el entorno, el disparador de programación y la fuente de integración se conservan.

Pero es una continuación manual de una ejecución específica, con tres condiciones que importan en la práctica:

La ejecución debe haber terminado de forma lo suficientemente limpia. "La ejecución debe estar en un estado terminal, como completada con éxito, fallida o cancelada", y "Las ejecuciones bloqueadas que están esperando la entrada o aprobación del usuario no se pueden continuar mediante el traspaso de nube a nube". Las ejecuciones muy antiguas "que son anteriores al modelo de conversación del agente" tampoco se pueden continuar.

Debe haber una instantánea (snapshot). Las ejecuciones "capturan una instantánea del espacio de trabajo al final de cada sesión", y si no se capturó ninguna (Warp pone como ejemplo un error de almacenamiento transitorio), "la ejecución continúa pero sin el estado del espacio de trabajo restaurado". La advertencia es más contundente: "Las ejecuciones en la nube más antiguas que no tienen una instantánea registrada no se pueden traspasar; inicia una nueva ejecución en su lugar".

Y la propiedad puede restringirlo: "Las ejecuciones en la nube que se originaron a partir de un traspaso de local a nube solo pueden ser continuadas por el usuario que las creó, no por otros miembros del equipo". Warp también señala que el traspaso "se realiza con el mejor esfuerzo posible" (best-effort): cuando los cambios no se pueden aplicar limpiamente, el agente informa cuáles fallaron y continúa con el resto.

Nada de eso es una crítica al handoff. Es simplemente una forma diferente: un humano que decide extender una ejecución, no una programación que aprende.

La propia respuesta de Warp existe, y está en vista previa de investigación (research preview)

Warp está construyendo la capa que falta, y vale la pena saber exactamente dónde se encuentra para no descartarla ni planificar en torno a ella prematuramente.

Agent Memory se describe como "un sistema de memoria persistente que vive en Warp y se comparte entre todos los entornos de agentes compatibles, incluidos el Warp Agent integrado, Claude Code, Codex y otros a medida que se agreguen". Incluye explícitamente el trabajo en segundo plano: "Tanto agentes locales como en la nube: admite agentes locales interactivos en Warp y agentes en la nube en segundo plano". Las memorias se extraen automáticamente: "Cuando termina una conversación, Warp extrae hechos duraderos, aprendizajes y resultados y los escribe como memorias", y "El nuevo conocimiento se fusiona con las memorias existentes o las reemplaza en caso de conflicto". Se organiza en almacenamientos personales, de agente y de equipo, cada memoria "registra de dónde proviene" y "Cada cambio en una memoria se registra para que los equipos puedan inspeccionar cómo ha cambiado una memoria a lo largo del tiempo". La creación y la recuperación se ejecutan en segundo plano, por lo que "no consumen tokens ni añaden latencia a la tarea activa".

Ese es un diseño bien estructurado, y la procedencia más la auditabilidad no son comunes; consulta why memory provenance matters para entender por qué estas dos propiedades hacen gran parte del trabajo.

El estado actual es la limitación: "Agent Memory está en vista previa de investigación (research preview) y se habilita por equipo para socios de diseño (design partners)", con una lista de espera para solicitar acceso. También hay un límite de cobertura que vale la pena leer detenidamente si ejecutas entornos de terceros: "Los entornos de terceros están cubiertos cuando se ejecutan como agentes en la nube", y "(La ejecución local de entornos de terceros no es compatible durante la vista previa de investigación)". El acceso programático a la API y el autoalojamiento se enumeran como características futuras, no presentes.

Por lo tanto, el resumen correcto no es que Warp carezca de una capa de memoria. Es que Warp tiene una, se dirige exactamente a este problema, y hoy en día depende de ser un socio de diseño.

Hacer commits del estado en el repositorio. Funciona, y para algunos trabajos es la respuesta correcta: un registro registrado en el que el agente añade información es duradero, revisable y permite ver diferencias (diffs). También significa que cada ejecución abre un pull request contra un archivo que no es código, y no ayuda entre diferentes repositorios.

Hacer la programación más específica. "Omite cualquier cosa que ya hayas gestionado" suena bien pero no se puede ejecutar, porque una sesión limpia no tiene registro de lo que gestionó.

Encadenar seguimientos manualmente. Traspasar la ejecución de cada semana a la siguiente. Esto sí transfiere el estado del espacio de trabajo, pero requiere un humano en cada ciclo, lo que anula el propósito de la programación, y choca con las condiciones de instantánea y propiedad mencionadas anteriormente.

Asumir que el entorno retiene algo. Cubierto anteriormente. El entorno se define como el cómo, no el qué, y construye un espacio de trabajo limpio por ejecución.

Concluir que los agentes en la nube de Warp no tienen memoria en absoluto. Comprensible si solo lees el modelo de ejecución, pero incorrecto: Agent Memory cubre los agentes en la nube por diseño. La afirmación precisa es que está en vista previa de investigación y restringido a equipos de socios de diseño hoy en día.

Desactivar la programación. El resultado más común, y el que desperdicia más trabajo.

La costura que Warp identifica es exacta: el estado cruza el límite de una ejecución solo si algo fuera de la sesión lo retiene. Así que coloca una capa de memoria fuera de la sesión y permite que cada ejecución lea de ella al principio y escriba en ella al final.

MemoryLake es esa capa: un almacenamiento de tu propiedad, accesible a través de una API, de modo que el mismo conocimiento esté disponible tanto si la ejecución fue activada por una programación, una mención en Slack o una persona frente al teclado. Tres pasos.

Paso 1: Crear una clave de API

Inicia sesión y crea una clave de API desde la configuración de tu espacio de trabajo. Almacénala como un Agent Secret para que se inyecte en tiempo de ejecución en lugar de integrarse en una imagen, que es para lo que sirve el mecanismo de secretos de Warp.

Paso 2: Subir tus primeras memorias

Sembrarla con las conclusiones que tus ejecuciones siguen deduciendo una y otra vez. Para la clasificación de incidencias: qué incidencias ya se consideraron duplicadas y por qué, qué reporteros necesitan una pregunta de seguimiento específica, qué etiquetas trata tu equipo como terminales. Para el trabajo con dependencias: las actualizaciones ya intentadas y abandonadas, y el motivo. Para tareas de limpieza: los archivos que parecen inactivos pero no lo están. Los archivos se suben tal como están, incluidos los multimodales, por lo que un diagrama de manual de procedimientos (runbook) o una hoja de cálculo de propiedad pueden ir directamente.

Paso 3: Conectar tu IA y agentes

Conecta Warp junto con cualquier otra cosa que ejecutes. Luego, haz que la lectura y la escritura sean explícitas en el prompt: comienza verificando qué concluyeron las ejecuciones anteriores sobre esta tarea y termina registrando cualquier cosa que una ejecución futura no deba tener que resolver de nuevo. Dado que el prompt de la programación es lo único que persiste entre ejecuciones, esa instrucción es la parte duradera.

Tres límites honestos. Esto no cambia el modelo de aislamiento de Warp: cada ejecución sigue iniciando una sesión limpia, y eso es algo bueno. No restaura el estado del espacio de trabajo; los cambios en el repositorio son tarea del handoff y MemoryLake almacena conocimiento, no diffs. Y no es un sustituto de un entorno: la imagen, los repositorios y los comandos de configuración se quedan donde están.

El primer cambio es que un agente programado deja de repetirse. La segunda ejecución lee lo que la primera concluyó y actúa sobre la diferencia en lugar de sobre toda la superficie.

El segundo cambio es que el historial de ejecuciones se vuelve útil en lugar de simplemente estar disponible. Warp lo conserva todo: "Eliminar una programación detiene inmediatamente todas las ejecuciones futuras. Las ejecuciones anteriores y su historial de sesiones siguen siendo accesibles para su inspección y revisión", y "Los cambios se aplican solo a las ejecuciones futuras. Las ejecuciones pasadas y su historial de sesiones permanecen sin cambios". Ese es un buen registro de auditoría y un mecanismo de búsqueda deficiente, porque nada lo lee en nombre de la siguiente ejecución. Una capa de memoria es la parte que convierte un archivo de transcripciones en algo que un agente consulta.

El tercer cambio aparece cuando ejecutas más de un agente. El propio diseño de Warp apunta a esto con almacenamientos de equipo vinculados a agentes compartidos, y la misma lógica se aplica a una capa externa: un agente de clasificación y un agente de revisión que leen del mismo almacenamiento dejan de contradecirse entre sí. Ese es el caso general descrito en shared memory for multi-agent systems.

Escribe el prompt como si fuera a ejecutarse durante un año sin supervisión. El prompt es lo único que sobrevive a cada ejecución, por lo que debe indicar qué leer primero, cómo decidir si vale la pena informar de algo y cuándo detenerse.

Mantén el conocimiento y el estado del espacio de trabajo separados. Los cambios en el repositorio son dominio del handoff. Las conclusiones, decisiones y exclusiones pertenecen a un almacenamiento de memoria. Mezclarlos produce un registro que nadie puede revisar.

No dejes que el almacenamiento crezca sin una estructura. El modelo de Warp de extraer "hechos duraderos, aprendizajes y resultados" es un buen filtro para copiar: registra decisiones y sus motivos, no transcripciones. How much memory to give an agent profundiza más en dónde se encuentra el límite.

Registra la procedencia. Warp requiere instrucciones por almacenamiento en cada archivo adjunto precisamente para que un agente sepa para qué sirve un almacenamiento: "Se requieren instrucciones en cada archivo adjunto para que el agente conozca el propósito de cada almacenamiento". Aplica la misma disciplina externamente: anota qué ejecución produjo una conclusión, de modo que una errónea pueda ser rastreada y eliminada.

Elige la identidad de ejecución deliberadamente. Por defecto, Warp ejecuta las ejecuciones con la identidad del creador de la programación, mientras que una identidad de agente en la nube se autentica como la aplicación. Esa decisión afecta a quién puede revisar los pull requests del agente, y es independiente de la memoria pero fácil de equivocar al mismo tiempo.

Vigila el radio de impacto de la programación antes de escalarla. Las ejecuciones se facturan al saldo de créditos compartidos del equipo y se ejecutan sin intervención. Una capa de memoria hace que cada ejecución sea más barata al reducir lo que tiene que examinar, lo cual es un beneficio secundario que vale la pena medir.

Únete a la lista de espera de Agent Memory si se adapta a tu pila tecnológica. Si tu equipo cumple los requisitos, un almacenamiento nativo compatible con múltiples entornos es algo bueno. Simplemente no bases el plan de este trimestre en una vista previa de investigación.

Warp te indicó la regla desde el principio: cada ejecución inicia una sesión limpia, y nada cruza el límite a menos que algo fuera de la sesión lo retenga. Ese es el diseño correcto para la automatización desatendida, y deja un vacío: un lugar para que una ejecución deje una conclusión para la siguiente.

Warp está llenando ese vacío con Agent Memory, que cubre los agentes en la nube y está en vista previa de investigación para equipos de socios de diseño. Hasta que esté disponible de forma general, el mecanismo es el mismo que describe la propia frase de Warp: un almacenamiento externo, que se lee al principio de cada ejecución y se escribe al final. Sesión limpia, conocimiento acumulado. Esas dos cosas solo entran en conflicto si el conocimiento vive dentro de la sesión.