Memory is what the agent knows: the context the model sees right now, plus anything you carry across runs in a store you own. Execution state is what the system knows: where the work stood when something went wrong. A memory store can bring back what the agent knew, but it can't tell a new process where to pick up.
In this first episode of Temporal & AI, I built a customer support refund agent in plain Python. It asks the customer two questions, looks up the order and decides to issue the refund. Then I kill its Worker one step before it calls Stripe.
Without Temporal: the loop loses its place, the answers are gone, and the customer has to start the return over.
With Temporal: the same loop runs as a Workflow. A new Worker picks up the same Workflow and resumes right at "issue refund" without asking a single question twice.
🎥 Watch the episode: https://youtu.be/cXKQkrgn-TE
🧪 Run it yourself (offline by default, no keys needed): https://github.com/temporal-community/agent-memory-and-state
The full write up, with architecture and gotchas, lives in the Temporal docs.
Top comments (2)
The memory-vs-execution-state distinction deserves more airtime than it usually gets — people reach for a vector store or a memory framework thinking it'll make their agent crash-safe, and it won't. A memory store can tell a fresh process what the agent knew; it can't tell it where the half-finished workflow stopped. Those are different jobs and conflating them is how you end up asking the customer the same two questions twice.
The refund-before-Stripe example is well chosen because it isolates the exact seam that hurts: the side effect and the record-that-it-happened are two operations, and any crash between them is a double-charge or a lost action waiting to happen. Durable execution basically turns "where was I?" into a framework guarantee instead of something you reconstruct from logs.
One thing I'd love to see in a follow-up: how you handle a step that's non-deterministic and non-idempotent when it re-runs — an LLM tool call that isn't the same on replay. Pinning those behind an activity so the result gets recorded once and replayed, rather than re-generated, is the subtlety that trips people up the first time they wire an agent into a durable workflow.
The split between memory and execution state is a useful one. Building a memory layer for coding agents, the main thing I learned is that what's worth carrying across is small: what was decided, what was tried and failed, and what's still open. Raw transcripts mostly add noise. The harder part was staleness, where a decision that got reversed last week keeps getting retrieved. Do you version memory alongside the workflow history in Temporal, or keep it as a separate store with its own expiry?