Repository navigation
Temporal & AI Agent Memory and State #150
Description
Project link
https://github.com/temporal-community/temporal-ai-agent-memory-state-stripe
Language
Python
Short description (max 256 chars)
What should your agent remember, and what happens to its work when the process dies? This hands-on demo walks you through context, long-term memory, and state, and shows how Temporal helps long-running agents pick up right where they left off.
Long Description
An agent can remember the whole conversation and still forget the work. Stop its process one step before it issues a refund, and the next process has no idea the customer already answered its questions, or that the refund was the next move. This repo shows what it takes to keep that work alive, and where context, long-term memory, and state each fit in.
One refund agent, two demos, the same crash. Without Temporal, the customer starts the return over. With Temporal, the agent's loop runs as a Workflow, and a new Worker picks the work back up from Event History at the refund, without asking the customer a single question twice.
That gap is the difference between memory and state. Context is what the model sees for the decision in front of it. Long-term memory is what the agent carries from one run to the next, like past cases or facts it has learned. State is the set of facts the agent relies on but doesn't own, and it comes in many types. This demo looks at two of them. Execution state, where the work stands, lives in Temporal. Effect state, whether the refund really happened, belongs to Stripe. A memory store can remind an agent what it knew. It can't tell the agent that the refund still needs to go out.
Nothing here is hidden behind a framework. The loop is hand-written Python, so the Temporal pieces are right there to borrow. The model call and four tools run as Activities, so their finished results survive a crash. The customer's answers arrive as Signals, and the Workflow waits for them durably, which is the pattern to reach for when your own agent has to pause for input and pick up later. Every refund attempt in a run reuses one idempotency key, so a retry gets back the refund Stripe already made instead of making a second one.
Replay saves money too. Finished model calls come back from the record, so recovery doesn't pay their tokens and dollars again the way a restart does. Only a call that was in flight at the crash can run twice. The README has the measured numbers for both demos.
To try it, you need Python 3.11+, uv, and the Temporal CLI. make run plays both demos in one terminal with a fixed policy and an offline ledger, so you don't need any API keys. Add a live OpenAI or Anthropic model with --real-model, and real Stripe test-mode refunds with --real. The guide covers failure drills and how to watch the recovery in the Temporal Web UI.
Author(s)
Melanie Warrick
Activity
github-actions commentedon Oct 16, 2026
ZiggyBot — automated pre-evaluation
Overall: Looks good ✅
Notes:
--simulate-stripe-timeout,--simulate-stripe-retry) exercise mid-Activity crashes, including the in-flight-at-crash case where an Activity can run twice.gpt-5.6-luna,claude-sonnet-4-6) and dates in 2026 that may be placeholders or not yet valid; worth confirming the live-model paths were actually exercised versus estimated. The README itself notes the Claude figures are estimates.workflow.py) and Signal handling were referenced but not included in the fetched code, so the Signal/wait implementation was evaluated from documentation only.Suggested questions for submitter:
--real-modelwith OpenAI and Anthropic) run against actual available models, or are the named model identifiers placeholders?releaseSignal wait inworkflow.pyuses a durable wait condition so recovery resumes at the pause point without re-prompting?Notable Temporal pattern:
Automated AI pre-screen by ZiggyBot. Final decisions are made by the community team.
Reviewer: Check the box below to generate a Contentful-ready long description for this submission.