Welcome to AIEdTalks' Newsletter!
In today's edition:
Why long agent runs break where web requests don't
What durable execution is: journal, replay, resume
Idempotency: how to stop a retry from double-charging
The 2026 landscape — pick an engine by your stack
Video of the week.
Let's dive in.
Today’s Edition
In partnership with
Talk to your AI tools the way you'd talk to a colleague.
You don't send a colleague a three-word brief. You explain the context, the constraints, what you've already tried. But typing all that into ChatGPT takes forever — so you don't.
Wispr Flow lets you speak your prompts instead. Talk through your thinking naturally and get clean, paste-ready text. No filler words. No cleanup. Just detailed prompts that actually get you useful answers on the first try.
Millions of users worldwide. Works system-wide on Mac, Windows, and iPhone.
AI SYSTEMS
Durable Execution for Agents
Here's a failure every backend engineer has met before, now wearing an AI costume. You build an agent that plans with an LLM, charges a customer, waits for a manager to approve, then sends a confirmation email. It works in testing. In production, the server redeploys — a routine thing — right after the charge goes through but before the run records that it happened. The agent restarts from the top. It charges the customer again. Or you catch the error and bail, and now the card is charged but the email never sends and nobody knows.
That's not an AI problem. It's the oldest problem in distributed systems: a long job that touches the outside world, interrupted halfway. We solved it for payments and pipelines years ago with durable queues, sagas, and workflow engines. Agents just make it sharp again, because their runs are long, expensive, and full of irreversible actions. This primer explains the fix — durable execution — from zero. It assumes you know retries, crashes, databases, and idempotency, and nothing about AI.
1. Why long-running agents break
A normal web request lives for milliseconds. If it dies, the client retries, and almost nothing is lost. An agent run is the opposite. It can take minutes to hours and span dozens of LLM calls, tool calls, and maybe a human approval. All the progress — the plan, the intermediate results, the loop position — lives in the process's memory. So when the process crashes, the server redeploys, or an API times out at step 47 of 60, that memory is gone. You're left with two bad options, both familiar:
Restart from scratch. Expensive (you re-pay for every token and tool call) and dangerous, because you re-run side effects. If step 30 already charged a card, starting over charges it again — the duplicate side-effect failure.
Leave it half-done. A tool already charged the card or sent the email, but the run died before recording it. Now your database and the real world disagree, and no human knows — the half-completed workflow failure.
2. What durable execution is
Durable execution is a way to run code so its progress is saved step by step — so if the process dies, it resumes from the last completed step instead of starting over. The mechanism is simpler than it sounds, and you already know the pieces:
The engine keeps a durable log — the journal (or event history) — of every completed step and its result.
When a step finishes ("charge card → success, charge_id=abc"), that result is written to the journal before moving on.
If the process dies and restarts, the engine replays the journal: it re-runs your coordinator code, but every time it reaches a step already in the journal, it does not run it again — it hands back the recorded result. Execution fast-forwards to the first unfinished step and continues.
That replay trick only works if your coordinator is deterministic — same inputs, same decisions, every time. So durable execution splits your code into two kinds: a workflow (the deterministic coordinator that decides what happens next; it gets replayed, so it must be predictable) and activities, a.k.a. steps (the parts that touch the outside world — LLM calls, HTTP, DB writes, payments; their results get journaled and reused on replay). The rule to burn in: anything unpredictable or side-effecting goes in an activity, never in the workflow.
3. Why agents need this specifically
The agent loop — think → act → observe — is a long-lived workflow. Each LLM call and each tool call is a step. Agents pause for human approval. They run a long time. And a retried model call must not corrupt state. Durable execution gives an agent five things a plain while-loop can't:
Crash-proof resumption — restart and pick up mid-run instead of losing everything.
Exactly-once effects — idempotency keys stop retries from double-charging.
Free long waits — a durable timer lets an agent wait for a human for days without holding a process open.
Automatic retries with backoff — a rate-limited or flaky tool retries on its own, without corrupting state.
A full replay history — pull a misbehaving run's journal, replay it against new code, and watch the decision change.
4. One idea that does the heavy lifting: idempotency
Durable execution guarantees a step runs at least once on retry. The thing that upgrades "at least once" to "exactly-once effect" is an idempotency key: a unique token attached to a side-effecting action so that repeating it does nothing extra.
def charge_customer(order, idempotency_key):
existing = payments.lookup(idempotency_key) # did we already do this?
if existing:
return existing # no-op: return the prior result
return payments.charge(order.card, order.amount,
idempotency_key=idempotency_key) # provider dedupes tooThe key is deterministic and unique per logical action — here, one per order (charge:{order.id}). Your code checks it, and the payment provider checks it too, so the charge happens at most once even if the step retries ten times. No durable engine can save you from a double charge if you skip this.
5. A worked example
The agent: (a) plan with an LLM, (b) charge the customer, (c) wait for manager approval, (d) send a confirmation email.
Naive version — breaks:
def run_agent(order):
plan = llm("plan how to fulfill", order) # non-deterministic
charge = payments.charge(order.card, order.amount) # money moves
approved = wait_for_manager() # holds the process open
email.send(order.email, "You're all set!") # side effectCrash after charge but before the email is recorded → restart re-runs from the top → double charge. Or the run dies after charging and the email never sends. And holding the process open at wait_for_manager for hours is fragile.
Durable version — survives:
@workflow # deterministic coordinator; replayable
def run_agent(order):
plan = step(llm_plan, order) # result journaled
charge = step(charge_customer, order,
idempotency_key=f"charge:{order.id}") # journaled + idempotent
approved = wait_for_signal("manager_approval") # durable wait
if approved:
step(send_email, order,
idempotency_key=f"email:{order.id}") # journaled + idempotentOn a crash-and-restart, the engine replays: llm_plan and charge_customer are already in the journal, so it reuses their recorded results — without re-charging — and resumes at the wait. The workflow can sleep for days at wait_for_signal without holding a process. Notice what changed: not the model, not the prompt — the architecture.
6. The 2026 landscape (pick by your stack)
You don't build this yourself. Reach for an engine, and choose by what you already run:
Temporal — the heavyweight for cross-service orchestration at scale. Open-source engine plus a managed cloud; you run (or pay for) a cluster. It raised a $300M round in February 2026 and shipped an OpenAI Agents SDK integration where model calls run as durable activities.
DBOS — the lightest footprint if your state already lives in Postgres. It's a library you import, not a server to operate.
Restate — a lightweight, self-hostable single-binary engine; elegant and low-latency.
Inngest — serverless-friendly durable functions with strong flow control and no queue to manage.
AWS Lambda durable functions (launched Dec 2025) — durable execution inside the Lambda model; can pause for up to a year on external events, unbilled while paused.
Cloudflare Workflows — lowest-ops if you're already on Cloudflare, with first-class Agents-SDK support.
LangGraph / OpenAI Agents SDK — framework-native persistence. Useful, but honest caveat: LangGraph's own docs note that on resume, nodes after the checkpoint re-execute, including LLM and API calls — so wrap side-effecting nodes as tasks and make them idempotent yourself. The OpenAI SDK's "sessions" are conversation memory, not crash recovery.
Rule of thumb: a library (DBOS, LangGraph) for the lightest start; a service (Temporal, Restate) when you outgrow a single process.
7. Common beginner mistakes
Putting non-deterministic code in the workflow. An LLM call, random(), datetime.now(), or a raw HTTP client in the coordinator breaks replay. Wrap them in steps.
Thinking durable execution makes the LLM deterministic. It doesn't. It journals the result and reuses it on replay; the first run is still non-deterministic.
Forgetting idempotency keys. Then retries double-charge. At-least-once execution + idempotency = exactly-once effect.
Using it for everything. Overkill for a single quick, read-only call. Reach for it when runs are long, multi-step, or touch money.
Confusing it with "just saving to a database." Manual saving still leaves you writing resume logic; the point is automatic step-level resume and replay.
Confusing it with a message queue. A queue gives at-least-once delivery; it doesn't remember where a multi-step run got to.
Key terms
Durable execution — running code so its step-by-step progress is saved and can resume after a crash.
Workflow — the deterministic coordinator that decides the next step.
Activity / step — a non-deterministic or side-effecting unit whose result is journaled.
Journal (event history) — the durable, ordered log of completed steps and results.
Replay — re-running the workflow against the journal, skipping completed steps.
Idempotency key — a unique token so repeating an action has no extra effect.
At-least-once vs exactly-once — retries may run twice; idempotency turns that into one real effect.
Durable timer — a crash-surviving wait the engine resumes later.
Signal / human-in-the-loop — an external event (like "approved") a paused workflow waits for.
Saga / compensation — a multi-step flow where each step has an "undo" if a later step fails.
The one idea to remember
An agent run isn't a request — it's a long-lived workflow that touches the real world, so build it like one. Keep the coordinator deterministic, make every side-effecting action a journaled, idempotent step, and let the engine handle crashes and waits. Then a redeploy at step 47 stops being a double charge and becomes a shrug.
Notes on the facts: the definition and workflow/activity/replay mechanics are drawn from the docs of durable-execution engines (Restate, Temporal, DBOS). Temporal's $300M February 2026 raise and its OpenAI Agents SDK integration are from its own announcements; AWS Lambda durable functions launched at re:Invent in December 2025; Cloudflare Workflows and LangGraph persistence are from their official docs. Adoption figures cited in trade coverage (e.g., a jump to ~81% daily agent use) come from a vendor survey and are directional, not independent. Durable execution does not make an LLM deterministic — it journals and reuses the result — and it gives exactly-once effects only when you supply idempotency keys.
AI VIDEO
Agent observability:
Rate today's Newsletter
👋 That’s All Folks!
Before you go, just a few public service announcements:
See you soon,
AIEdTalks’ Newsletter Team
