Free forever, no credit card.Get Started for Free →
← All posts
October 2, 2026 · 5 min read

Temporal Replays Your Workflow. It Doesn't Remember Your Agent.

Temporal Replays Your Workflow. It Doesn't Remember Your Agent. You put your support-triage agent inside a Temporal workflow because you wanted reliability. Good instinct. The workflow pulls the overnight tickets, the agent reads them, drafts responses, routes the tricky ones to a human for approval, then the workflow sleeps until the next signal. One night the worker dies at 2 AM mid-approval. A new worker picks up, replays the event history, and the workflow resumes exactly where it stopped.

Temporal Replays Your Workflow. It Doesn't Remember Your Agent.

You put your support-triage agent inside a Temporal workflow because you wanted reliability. Good instinct. The workflow pulls the overnight tickets, the agent reads them, drafts responses, routes the tricky ones to a human for approval, then the workflow sleeps until the next signal. One night the worker dies at 2 AM mid-approval. A new worker picks up, replays the event history, and the workflow resumes exactly where it stopped. You watch this happen and think: great, the agent remembers.

It doesn't. You just watched durable execution doing its job, which is remembering the run, not the agent. The distinction stays invisible until the failure that reveals it, and the failure always looks like this: months later, the same agent escalates the same customer for the same reason it escalated them three months ago, and the person who resolved it last time has to re-explain the whole context in the ticket. The workflow remembered every step of every run. Nobody remembered what was learned.

Replay is about this run, not the next one

Temporal's event history is a superb piece of infrastructure. Every activity, signal, and timer is recorded, and any worker can rebuild the workflow's exact state by replaying that record. Crashes, deploys, restarts: the run survives them all.

But the unit of remembering is the run. When the workflow completes, its history becomes a finished record. When a long workflow has to continue as new, only the inputs you explicitly pass forward carry over. Scheduled workflows start each execution fresh. The system remembers everything about what happened and nothing about what it meant. An audit trail is not a brain.

The gap is most visible where agents do multi-turn work. Temporal's own integration with the OpenAI Agents SDK is honest about it. The upstream conversation session cannot be used as-is because it depends on host process state that replay will not reproduce, so the integration provides a replay-safe session that stores its history on the workflow heap. That history gets rebuilt by replay within a single run. Cross into continueAsNew and it is gone: the continued run starts with an empty session unless you write the plumbing to capture the session items and feed them back in through the constructor's initial items.

That is a workaround, not a feature. And the workaround has a ceiling.

The ceiling of carried transcripts

Once you carry the transcript across run boundaries by hand, you own a new set of problems that Temporal was never built to solve.

First, the plumbing never stops needing attention. Every new agent you add to a workflow needs the same capture-and-reseed code. Every workflow that should share what an agent learned needs its own version of it. What started as "just carry the items forward" becomes a bespoke persistence layer with your company's name on it.

Second, the transcript keeps everything and understands nothing. Six months of runs means six months of turns, and the only operation available is reading them in order. There is no asking "what did we decide about refund policy escalation" and getting an answer; there is only reading. Retrieval by meaning is not something a longer transcript grows into.

Third, nothing crosses between systems. The triage agent's transcripts live in that workflow's runs. The sales agent in another workflow cannot see them. The version of you chatting with the agent interactively on Tuesday afternoon cannot see them either. Your operators run one brain across many surfaces, and the workflow heap is not shared infrastructure.

What memory actually means for a scheduled agent

It helps to name what the agent was missing all along, because "memory" has been stretched to cover everything from event histories to vector databases. For a scheduled agent, memory has to do three things that durable execution does not.

It has to answer questions by meaning. "Why did we stop auto-refunding orders over $200?" is a semantic question, and the answer should arrive before the agent acts, not after six pages of transcript.

It has to distill. Decisions, corrections, and incidents are the durable part; the routine noise of each run is not. A memory system keeps the first and sheds the second. A transcript keeps both.

It has to follow the agent. Memory belongs to the operator's stack, not to one workflow. An agent that learns something on Monday's schedule run should still know it when it runs in a different workflow, or when it runs somewhere else entirely.

Temporal does durable execution better than anything in its class. Memory is simply a different job, and bolting it onto replay is the same project every orchestrator's users keep rediscovering: XComs, static data, session transcripts. The tool you already run is never the memory system you need.

A memory layer that follows the agent

Vilix AI exists for exactly this gap. It is a cloud-hosted memory layer that connects to your agents over MCP, so the same context is available whether the agent runs inside a Temporal workflow, in a chat tool, or anywhere else. Full conversation history, not just extracted facts, with semantic retrieval so the agent finds things by meaning. You can export your data in a portable format or delete it anytime, and there is a free plan that stays free, with a 7-day Pro trial that asks for no credit card. Be honest with yourself about the tradeoff: it is hosted in the cloud, which rules it out if your context is not allowed to leave your own infrastructure.

Don't confuse the flight recorder with the pilot

Run this test on your own setup sometime: find a decision your agent made two months ago that got corrected, and ask this month's run about it. If the answer is a confident re-invention of the original mistake, your workflow remembered every step and your agent remembered nothing. That is not a Temporal failure. It is a missing layer, and it is fixable.


Keep reading:

Get Started for Free

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Get Started for Free

Free forever, no credit card.

Keep reading
Your Codex Session Remembers the Project, Not the Conversation

Your Codex Session Remembers the Project, Not the Conversation Picture a Codex scheduled task that runs every weekday morning: review open PRs, check CI, flag problems. Monday's run learns your team's conventions, the flaky test everyone ignores, the reviewer who wants summaries up top. Tuesday's run wakes up and re-learns all of it, because Monday's run never wrote any of it down where Tuesday's run could find it. That is the honest shape of Codex memory today. It remembers the project. It do

Does OpenClaw Remember Between Sessions? What Actually Persists

Does OpenClaw Remember Between Sessions? What Actually Persists The short answer: No, not out of the box. Every OpenClaw session starts fresh, and nothing carries over unless the agent explicitly wrote it somewhere that gets loaded again. The built-in file-based memory is a setup project you configure and maintain, not a default. Scheduled cron jobs are the leakiest part: they often run without the memory files your chat session relies on. Why does OpenClaw forget everything between sessions?

Your AI Agent Forgets Everything Between Sessions. Here Are the 4 Fixes That Actually Work

Quick answer: AI agents forget everything between sessions because language models are stateless. Every run starts with an empty context window, and when the session ends that window is destroyed. Nothing carries over unless you deliberately stored it somewhere else. The fix is a persistent memory layer the agent reads when it starts and writes to before it stops. Four honest ways to do that: your provider's built-in memory, instruction files, a self-hosted memory layer, or a hosted shared memor