Cómo evitar que las tareas programadas de ChatGPT comiencen desde cero en cada ejecución (2026)

Una ejecución independiente es un nuevo chat, a propósito

La estructura predeterminada de una tarea programada es la independencia. Cada ejecución se abre desde cero, realiza el trabajo descrito en el prompt guardado y reporta en Scheduled, que OpenAI describe como una bandeja de entrada: "Las ejecuciones de tareas programadas con hallazgos aparecen allí, y un indicador de no leído muestra cuándo una ejecución requiere tu atención".

Ese es un buen diseño para cualquier cosa idempotente: un informe semanal, una verificación nocturna, un resumen mensual. También es la razón por la que una tarea de clasificación se repite. Nada en la documentación describe un lugar donde se guarden las conclusiones de una ejecución para la siguiente, aparte de esa bandeja de entrada, que está diseñada para que la leas tú y no la tarea.

Vale la pena ser precisos aquí, porque este es el punto donde la gente saca conclusiones apresuradas. Lo que indica la documentación es que cada ejecución independiente inicia un nuevo chat. Lo que no indica es nada sobre que una ejecución herede los hallazgos de la ejecución anterior, y no existe un almacenamiento documentado entre ejecuciones para las notas de trabajo de una tarea. Si necesitas continuidad, tienes que organizarla tú mismo, que es de lo que trata el resto de este artículo.

Los dos modos son productos diferentes, y el predeterminado es el olvidadizo

Existe un segundo modo, y es la solución directa para el trabajo acumulativo: "Programa una tarea dentro de un chat existente cuando quieras que ChatGPT regrese a ese chat según una programación. La tarea programada utiliza el contexto existente del chat en lugar de comenzar desde un nuevo prompt cada vez".

La documentación es explícita sobre cuándo usar cada uno. Para el trabajo continuo "que debe seguir utilizando el mismo contexto", programa dentro de un chat. Usa el modo independiente "cuando cada ejecución deba ser independiente o cuando los hallazgos deban aparecer como ejecuciones separadas en Scheduled". Su lista de casos de uso dentro del chat incluye "monitorear una operación de larga duración hasta que termine", "recordar a ChatGPT que continúe un ciclo de revisión a un ritmo fijo" y "continuar un chat de investigación o clasificación en curso sin perder su contexto".

La mayoría de las personas nunca ven esta opción, porque crear una tarea desde la barra de prompts produce la variante independiente.

Los disparadores de eventos hacen que el límite sea más nítido, no más suave

La adición del 25 de agosto permite que una tarea se ejecute "cuando ocurre un evento compatible de Gmail, Slack o GitHub". La división del trabajo se establece claramente: "El disparador determina cuándo se ejecuta la tarea; el prompt guardado determina qué hace cada ejecución".

Nada en esa frase se acumula. Un disparador se activa, un prompt guardado se ejecuta. Dos restricciones lo refuerzan: "Una tarea puede usar múltiples disparadores de eventos, pero no puede combinar disparadores de eventos con una programación basada en el tiempo", y "Cuando llegan varios eventos coincidentes muy seguidos, ChatGPT puede combinarlos en una sola ejecución". Las tareas activadas por eventos también están limitadas a la web y a dispositivos móviles: "No están disponibles en la aplicación de escritorio de ChatGPT, Codex CLI o la extensión de IDE".

Así que la versión más reactiva de las tareas programadas es también la que menos estado conserva. Eso no es un defecto; es lo que es un disparador.

El lugar donde ocurre la ejecución decide lo que puede ver

Tres entornos, tres alcances de acceso. En la web, "Las tareas web pueden usar contexto subido y herramientas conectadas, pero no pueden trabajar directamente en una carpeta de tu computadora". En la aplicación de escritorio, las tareas "pueden trabajar con proyectos locales y ejecutarse en el directorio del proyecto o en un worktree aislado", con dos condiciones estrictas: "Mantén la computadora encendida y la aplicación en ejecución cuando una tarea programada necesite archivos locales", y "El proyecto seleccionado debe seguir estando disponible en el disco cuando la tarea esté programada para ejecutarse". La CLI y la extensión de IDE no tienen ninguna interfaz de gestión de tareas programadas.

Una tarea que lee tu repositorio cada mañana y una tarea que lee tu bandeja de entrada cada mañana no son el mismo tipo de tarea, y fallan de maneras diferentes.

Pegar los hallazgos de la semana pasada en el prompt. Funciona durante una semana. Luego, el prompt se convierte en un registro de cambios, crece cada vez que lo editas y nadie puede distinguir qué línea es una instrucción y cuál es una nota.

Programar dentro de un chat y no depurarlo nunca. El modo correcto, aplicado sin mantenimiento. El hilo se acumula en cada ejecución y, eventualmente, el estado útil queda enterrado bajo veinte turnos rutinarios de "nada que reportar".

Acortar el intervalo. Las tareas dentro del chat admiten intervalos basados en minutos para "ciclos de seguimiento activo", y es de lo más tentador tratar la frecuencia como un sustituto de la continuidad. No lo es, y consume cuota de uso en ejecuciones que no tienen nada que hacer.

Asumir que un proyecto guarda el estado de la tarea. Los proyectos mantienen juntos los chats, archivos y fuentes relacionados. Eso es organización, no un lugar donde una tarea escribe; y lo que un proyecto comparte y no comparte se cubre en por qué los proyectos de ChatGPT no comparten memoria.

Concluir que las tareas programadas no pueden realizar trabajo acumulativo. Sí pueden. El modo existe, la documentación lo menciona y la pieza que falta es un lugar duradero desde el cual leer, no una característica ausente.

Comienza por clasificar la tarea, porque el modo es una decisión real y elegir el incorrecto es la causa de la mayoría de los problemas.

Si cada ejecución realmente se sostiene por sí sola (un informe, una verificación, un resumen), mantenla como independiente y deja que Scheduled sea tu bandeja de entrada. Si la ejecución necesita saber qué sucedió la última vez, prográmala dentro de un chat y tómate en serio el consejo de OpenAI sobre el prompt: "haz que el prompt sea duradero. Debe describir qué debe hacer ChatGPT en cada ejecución programada, cómo decidir si hay algo importante que reportar y cuándo detenerse o pedirte tu intervención". Esa última cláusula es la que la gente suele omitir, y es lo que evita que un ciclo reporte indefinidamente.

Hay una segunda palanca que vale la pena usar. La documentación recomienda empaquetar la acción en sí: "Para mantener las tareas programadas mantenibles y compartibles entre equipos, usa skills para definir la acción y proporcionar herramientas y contexto. Selecciona o invoca una skill específica en el prompt de la tarea cuando el flujo de trabajo no deba depender de la selección automática de herramientas". Una skill mantiene el procedimiento de manera estable entre ejecuciones. No guarda lo que cambió desde ayer.

Lo que nos deja con la parte que ni el modo ni la skill cubren: el estado acumulado. MemoryLake es una capa de memoria que reside fuera de cualquier herramienta individual, de modo que una nueva ejecución tiene algo que leer antes de decidir qué es nuevo. La configuración consta de tres pasos.

Paso 1: Crear una clave de API

Inicia sesión y crea una clave de API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Subir tus primeras memorias

Entradas cortas, una afirmación cada una. Para una tarea recurrente, las entradas útiles son aquellas que permiten responder a la pregunta "¿es esto nuevo?":

Lo que ya se ha gestionado. El problema que clasificaste, la alerta que descartaste y por qué, la pregunta del cliente que ya fue respondida. Esta es la entrada que detiene la repetición del cuarto día.

Decisiones permanentes que la tarea debe respetar. Qué etiquetas significan ignorar, qué repositorios están congelados, quién es el propietario de cada servicio. Datos que, de otro modo, tendrías que volver a pegar en el prompt cada vez que lo edites.

Umbrales y definiciones. Qué se considera urgente, qué se considera ruido. Una ejecución no puede aplicar tu criterio a menos que tu criterio esté escrito en alguna parte.

Enlaces externos. El panel de control, el runbook, el rastreador; las cosas que una tarea no puede encontrar en una bandeja de entrada o en una carpeta.

Paso 3: Conectar tu IA y agentes

Conecta lo que utilices. Se puede acceder a MemoryLake a través de MCP y de una API, y dado que ChatGPT admite herramientas conectadas, una tarea programada puede consultar la misma memoria en cada ejecución. Codex, Claude Code, Cursor y Cline también leen la misma memoria, lo cual es importante cuando la tarea es solo un paso de algo que una persona termina en otro lugar.

Tres límites honestos. Esto no cambia la forma en que se ejecutan las tareas programadas: una ejecución independiente sigue abriendo un nuevo chat y los disparadores de eventos se siguen activando por evento. No es un reemplazo para el modo dentro del chat cuando lo que necesitas es una continuidad conversacional real. Y la memoria es contexto, no imposición: cualquier cosa que deba cumplirse estrictamente en cada ocasión pertenece a una verificación que falle, no a una nota sobre la cual un agente puede decidir actuar o no.

La repetición deja de ser el comportamiento predeterminado. Una ejecución puede verificar qué se ha gestionado ya antes de reportar.

El prompt deja de ser un bloc de notas. Las instrucciones siguen siendo instrucciones; el estado vive en un lugar donde se puede actualizar sin necesidad de editar la tarea.

Las tareas activadas por eventos se vuelven utilizables para flujos de trabajo reales. Un disparador que se activa por cada comentario de un pull request aún puede saber qué decidió tu equipo la semana pasada.

Puedes elegir el modo de manera deliberada. Las ejecuciones independientes se mantienen limpias; las ejecuciones acumulativas obtienen un prompt duradero y un lugar desde el cual leer.

Elige el modo antes de escribir el prompt. Independiente para ejecuciones autónomas, dentro del chat para cualquier cosa acumulativa. La documentación indica cuál es cuál; el predeterminado es el independiente.

Haz que los prompts dentro del chat sean duraderos. Qué hacer en cada ejecución, cómo decidir si vale la pena reportar algo y cuándo detenerse o preguntar. Las tres cosas, en el prompt.

No utilices la frecuencia como sustituto del estado. Los intervalos basados en minutos son para un seguimiento activo, no para la continuidad.

Anticipa la acumulación en los disparadores de eventos. Varios eventos coincidentes que lleguen juntos "pueden" combinarse en una sola ejecución, así que escribe el prompt para manejar un lote en lugar de un solo elemento.

Completa la lista de verificación de conexión. Para Slack, @ChatGPT debe estar en cada canal que la tarea monitorea; no se admiten reacciones, ediciones, eliminaciones ni mensajes directos. Para GitHub, la aplicación conectada necesita acceso al repositorio.

Verifica los permisos de administración antes de depurar. En espacios de trabajo administrados, el acceso está controlado por el permiso Permitir tareas programadas activadas por eventos. Una tarea que nunca se activa puede deberse a una política, no a un error.

Ten en cuenta las condiciones locales en las tareas de escritorio. La máquina debe estar encendida, la aplicación en ejecución y el proyecto aún en el disco. Los worktrees mantienen los cambios de la tarea alejados del trabajo en progreso.

Coloca el procedimiento en una skill y el estado en la memoria. Son cosas diferentes; la distinción se detalla en por qué las habilidades de los agentes no son memoria.

La repetición no es un mal funcionamiento. Las tareas programadas independientes "inician un nuevo chat para cada ejecución programada", y esa independencia es una característica documentada diseñada para trabajos donde cada ejecución debe sostenerse por sí sola. El problema comienza cuando la tarea es acumulativa y el modo no lo es.

OpenAI documenta la alternativa en la misma página: programa dentro de un chat existente y "la tarea programada utiliza el contexto existente del chat en lugar de comenzar desde un nuevo prompt cada vez", con un prompt duradero que indica qué hacer, cómo juzgar qué vale la pena reportar y cuándo detenerse. Empaqueta el procedimiento como una skill para que se mantenga estable entre ejecuciones. Y para las tareas activadas por eventos —la forma más nueva y con menos estado— acepta que un disparador más un prompt guardado es toda la continuidad que el propio mecanismo proporciona.

Lo que queda es el estado: qué se ha gestionado, qué se considera urgente, qué decidió ya el equipo. Mantén eso fuera del prompt de la tarea, en una capa que una nueva ejecución pueda leer, y la cuarta ejecución dejará de repetir la segunda. La versión general de este argumento, aplicada a agentes cuyas ejecuciones son sin estado por diseño, se encuentra en por qué OpenClaw olvida las ejecuciones anteriores y memoria para servidores MCP sin estado.