An agent is a consumer of its own event log
The reliability problems that make AI agents scary in production were solved years ago, just not by AI people. Stream-processing engineers spent a decade learning how to run long jobs on unreliable machines without losing or duplicating work. Every one of their tricks transfers to agents, because an agent has exactly the shape of a stream consumer: a loop that does work and must remember how far it got.
The shape of the problem
An agent working a multi-step task is a loop: observe the situation, decide a step, act on it, repeat. The naive version keeps all its progress in memory, in the conversation context. Kill the process at step seven of ten and everything evaporates; restart and it begins at step one, redoing work, re-calling tools, re-spending tokens, possibly re-sending things that should never send twice. That is not an AI problem. That is a checkpointing problem, and it has a known answer.
Checkpoint like a consumer commits
Stream consumers survive crashes with a bookmark: after processing a batch, they durably record their position, and on restart they resume from the last recorded place. The agent version: after every completed step, write a small durable record of the step and its outcome, a checkpoint file, a row, anything that survives the process. On startup, read the log, reconstruct where you are, and continue from the first unfinished step. The agent stops being a fragile conversation and becomes a consumer of its own event log, replaying its history to find its place.
Order matters, and it is the same order streaming taught: act first, then record. Crash between the two and the step replays on resume. Which is only safe if the steps can tolerate replaying, and that is the second transplant: idempotence. Design each step so doing it twice equals doing it once. File writes keyed by name, API calls with idempotency keys, database merges instead of inserts. Repeats become harmless, so retrying becomes free.
The kill test
Here is the honesty bar I hold agent code to: run the task, kill the process with no warning midway, restart, and watch. A passing agent resumes from its checkpoint, redoes at most one step, duplicates nothing visible, and finishes. A failing agent starts over or, worse, half-repeats itself into an inconsistent mess. Ten minutes of testing, and it tells you more about production readiness than any demo. If you adopt one practice from this essay, adopt the kill test.
Budgets, because loops are furnaces
One more transplant from systems practice: no loop without limits. Max steps, max tokens, max wall-clock, and a terminal state that reports failure gracefully instead of spinning. Agents fail weirdly; a step that keeps almost-succeeding can burn a budget in minutes. The give-up state is not pessimism. It is the difference between an incident and an invoice.
The takeaway
Treat the agent as a distributed-systems component, because it is one: checkpoint after every step, make steps idempotent, resume from the log, cap everything, and prove it all with a kill test. None of this needs a framework. It needs the habit of asking, at every step, the old streaming question: if we die right here, what happens on restart?