MODULE 04 OF 12 · RELEASE 1 · OUTLINE

State, Memory & Durable Execution

Work that remembers where it got to, even if the power goes out mid-task.

This module is an outline. The plain-language explanation and the lab specification below are final. The full written lesson and its runnable lab repository are still being prepared, and enrolment is not open.

You are following a recipe with twelve steps. Halfway through, the phone rings and you leave the kitchen for an hour. When you come back, you look at the pan and the ticked-off steps and carry on. You do not start again from the shopping.

So what is this really about?

Long jobs in software need the same thing: a written note of what has already been done. If the program restarts — a crash, a deploy, a server moving — it should read the note and carry on, not start over. Starting over is not just slow; if step two sent an email, starting over sends it twice.

Each step records its result before the next begins, so a restart resumes at the next unfinished step rather than repeating work.

QUICK CHECK

A four-step job crashes after step two. Step two sent a confirmation email. What must resuming NOT do?

The words you will hear

State: The ticked-off steps. What has happened so far, written down where it survives a restart.
Durable: Survives the program stopping. In a database, not in memory.
Resume: Picking up at step seven instead of step one.
Memory (conversation): What was said earlier in a chat. Useful context — but not the official record of what was done.

By the end you will be able to

Write a long job down as steps rather than holding it in memory.
Resume without repeating anything that already happened outside your system.
Keep chat memory separate from the official record.

How it is put together

A run record holds the task, its current step, and the result of every completed step. Each step is a pure function of that state plus its own side effect, recorded before the step advances. Resuming means reading the record and continuing, not replaying. Conversation memory is a separate, size-bounded store — it informs prompts and is never the source of truth for what has happened.

Where you start

A three-step agent flow held entirely in memory, which loses everything if the process restarts.

The lab

Model the flow as a run record with an explicit step and a result per step.
Record each side effect before advancing, so a crash cannot lose it.
Add resume: given a run id, continue from the recorded step.
Add a bounded conversation memory with an explicit eviction rule.
Add a terminal failure state that stops the run rather than looping.

What goes wrong, on purpose

The scenario. The process is restarted between step two and step three.

What should happen. Resuming continues at step three. Steps one and two are not repeated, and their side effects occurred exactly once.

How you prove it works

A test interrupting a run and asserting resumption at the correct step.
A test asserting completed side effects are not repeated on resume.
A test asserting conversation memory stays within its bound under a long exchange.

What you walk away with

An agent flow you can kill at any point and restart without duplicate effects, and a memory store with a stated eviction policy.