Does Trigger.dev Remember Between Runs?
If you run scheduled AI work, you have probably looked at Trigger.dev. It is the background-jobs platform a lot of AI teams reach for: cron triggers, long-running tasks, durable execution, and now a whole AI chat stack with chat.agent. One question comes up constantly from automation operators: does Trigger.dev remember between runs? The short answer is layered: yes within a run, yes within a chat session, and no everywhere else. That last part is where scheduled agents quietly lose everything
If you run scheduled AI work, you have probably looked at Trigger.dev. It is the background-jobs platform a lot of AI teams reach for: cron triggers, long-running tasks, durable execution, and now a whole AI chat stack with chat.agent. One question comes up constantly from automation operators: does Trigger.dev remember between runs?
The short answer is layered: yes within a run, yes within a chat session, and no everywhere else. That last part is where scheduled agents quietly lose everything they learned.
What Trigger.dev actually remembers
Trigger.dev has two different persistence stories, and they solve two different problems.
Inside a single run: durable execution. Every step your task completes is checkpointed. If the run crashes, retries resume from the last finished step instead of starting over. Your LLM call results, tool outputs, and intermediate state survive a crash mid-run. This is genuinely good engineering, and it is the reason people pick Trigger.dev for long agent loops.
Inside a chat session: Sessions and transcript storage. Trigger.dev's newer chat.agent stack is built on Sessions. A Session is keyed on a stable id (your chatId), and it owns whatever run is currently processing the conversation. When a run ends — a version upgrade, a turn limit, a crash, an idle timeout — the next message boots a fresh run with nothing in memory. That fresh run then reads the conversation back from transcript storage: the list of messages, a state blob holding things like the compaction summary, and the stream cursors it resumes from. The default storage is a platform snapshot in object storage; you can also bring your own database.
So if a user is chatting with your agent on Tuesday and comes back on Friday, the agent still has the conversation. That is real persistence, and it is more than most agent setups get out of the box.
What it does not remember
Here is where scheduled-agent operators get surprised. Everything Trigger.dev persists is scoped to either one run or one chat session:
A new chat starts blank. Transcript storage is keyed by chatId. A new conversation id means a new, empty transcript. The agent cannot look across sessions and recall that this user prefers terse summaries, or that last month's onboarding call established a specific reporting format. Each chat is an island.
Scheduled runs are separate runs. A cron-triggered agent that runs every night does not run inside a chat session. Each execution is its own run, in a fresh process, with nothing carried over. Anything the agent figured out last night — which data sources were flaky, which alert patterns turned out to be noise, what the on-call engineer actually wanted in the summary — is gone by morning. Durable execution protects you against crashes within a run. It does nothing for knowledge across runs.
Transcripts are conversations, not memory. Transcript storage keeps what was said. It does not keep what was learned. The default storage also compacts long conversations, keeping roughly the last hundred messages and dropping the rest. So even within one long-lived chat, older knowledge quietly falls away.
There is no cross-run recall. No mechanism in Trigger.dev answers "what did my agent learn about this client across the last 40 runs?" The platform remembers the mechanics of execution. It does not remember the substance of the work.
Why this bites scheduled agents
Picture the classic operator setup: a nightly agent on a Trigger.dev schedule that triages support tickets, enriches new leads, or summarizes the day's deploys. On night one it makes reasonable guesses. On night thirty it is still making the same guesses, because every run is night one. It re-learns which ticket labels are meaningless. It re-discovers that the staging deploy failures are always the flaky test. It asks for the same preferences it was given weeks ago, in a different chat, that it cannot see.
This is the re-briefing tax: every run pays full price for context the agent already earned. It costs tokens, it costs latency, and it costs correctness, because an agent working from scratch invents details when it cannot find them. Scheduled agents do not just need crash recovery. They need a memory that outlives the run.
The fix: give every run its own memory
The pattern that works is simple and boring: at the start of each run, the agent reads the memories relevant to this run. At the end, it writes down what it learned. Read at boot, write at shutdown, every run, forever.
You have three ways to get there:
Roll your own store. A database table, a retrieval function, pruning logic, and prompt plumbing in every agent. Full control, real engineering cost, and you will rebuild the boring parts (what to keep, what to forget, how to search it) that every operator rebuilds.
Stretch Trigger.dev's own storage. Transcript storage is built for chat history inside one conversation, not for learned knowledge across runs. You can abuse it, but you will be fighting the grain: it is keyed by chat, it compacts, and it was designed to render a UI, not to be an agent's long-term memory.
Use a hosted memory layer over MCP (this is the Vilix AI-shaped option). This is the option that keeps the agent code dumb and the memory smart. The agent connects once, over MCP, and gets tools to save and recall memories. Nothing to host, no schema to design, no retrieval pipeline to tune.
One memory for every run, on every tool
That last option is what Vilix AI is built for. It is a cloud-hosted memory layer, so there is no infrastructure to manage: no database to provision, no vector index to babysit. Your Trigger.dev agent connects over MCP (headless agents can also hit https://api.vilix.ai/mcp directly with an API key) and the same memory follows it everywhere else too — the same account, the same memories, whether the agent runs in Trigger.dev, n8n, Claude Code, or a cron job on a VPS.
Crucially, it stores full conversation history, not just extracted facts. When your nightly agent wakes up, it does not get a lossy summary of last night; it can pull the actual context of what happened, what was decided, and what to do differently. And it is shared state, not a chat log: learnings from run 40 are there for run 41, even though Trigger.dev itself treats them as strangers.
Getting started costs nothing to try: there is a free plan that never expires, and a 7-day Pro trial with no credit card required. Your data stays portable — export everything or delete individual memories (or wipe the whole account) anytime.
The bottom line
Trigger.dev remembers how your run executed and, inside a chat session, what was said. It does not remember what your agent learned, and it does not carry anything across the separate runs of a scheduled task. If your agent runs on a schedule, that gap is where your context goes to die.
Close it the simple way: read memory at the start of every run, write memory at the end. Do it once, and night thirty of your agent is smarter than night one.
Free forever, no credit card.