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 (1)
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?