1.2 The six ways it dies

The loop from 1.1 works. You could demo it tomorrow and it would look like magic. Then you’d ship it, and it would fail — not in exotic ways, but in six very ordinary ones. Every serious piece of the harness exists to fix exactly one of them.

Let’s make the first one visceral, then name all six.

Failure #1, live: the crash

Here is the naive agent doing a real task — emailing a client. It sends a genuine email partway through. Watch the two panels: the agent’s memory (which lives only in RAM) and the outside world (which is real and permanent).

Run it forward until the email is sent. Then kill the process mid-task. Then restart and run it again.

Agent memory volatile · in RAM

step 0/4

lives only while the process runs

The outside world real · irreversible

0 emails sent

a crash cannot un-send this

Process started. Agent memory is empty.

Try this: press Next step until you see "📧 Email actually sent," then press 💥 Kill process, then ↻ Restart and run it forward again.

What you just saw is the defining problem of production agents:

The agent’s memory is in RAM. A crash — a deploy, an out-of-memory, a rate-limit that throws — wipes it instantly. On restart, the agent has no idea what it already did.
The outside world is not in RAM. The email really went out. Restarting doesn’t un-send it — it sends a second one.

So a naive agent that crashes doesn’t just lose progress. It repeats side effects: double emails, double charges, double tickets. And if the model call is expensive, you just paid for all of it twice, too.

The fix has a name — durable execution — and we build it in 2.1: write down every step before doing the next one, so a restart resumes exactly where it left off and never repeats a side effect.

All six failure modes

The crash is the most dramatic, but it has five siblings. Here is the whole family — and the lesson where each one gets fixed.

#	It dies when…	The consequence	The fix
1	The process crashes mid-task	Lost progress; the same email/charge/ticket fires twice	2.1 Durable execution
2	A tool can do anything	Model-written code deletes data or leaks secrets — nothing stops it	2.2 Sandboxed tools
3	The context grows forever	Every step re-sends the whole history → slower, pricier, and dumber over time	2.3 Memory & context
4	One agent does everything	It picks the wrong tool and conflates unrelated goals	2.4 Routing & handoffs
5	Sub-tasks run one at a time	Slow when they’re independent; one failure sinks the whole run	2.5 Supervision
6	It must wait for a human	Blocking a server for hours breaks it — and a restart loses the wait entirely	2.6 Human-in-the-loop

Look at that table for a second, because it is the rest of the course. Part 2 is literally these six rows, one lesson each: name the failure, feel it, then build the piece of harness that fixes it.

The pattern behind all six

Every one of these failures comes from the same root cause:

The naive loop treats a long-running, side-effecting, multi-party process as if it were a simple function call.

It isn’t. Real agent work crashes, costs money, touches the outside world, and sometimes has to wait days for a person. A plain while loop has no answer for any of that. The harness is the set of answers — and now you’re ready to build it.