1. Agent reliability

Picture an agent that handles refunds for an online store. Each night it works through about 300 return-and-refund tickets in a background run lasting about 2.5 hours, with no one watching. In the demo, on 5 tickets, it was flawless. In production it refunds a customer twice, emails the wrong person, and loses its place when a worker crashes. Agent reliability is the engineering that closes that gap: the controls that keep an LLM agent finishing its tasks correctly and safely when model steps are sometimes wrong, tools sometimes fail, and the machines running it sometimes die.

The basic principle is that every step can go wrong, and the chance of a clean run shrinks with every step. So instead of hoping for a better model, you put a control around each kind of failure. Tool errors go back to the model as information. Actions are checked before and after they run. Side effects are made safe to repeat. Progress is saved so a crash does not restart the run, and risky actions go to a person.

You need this when the agent takes actions with real side effects, such as refunds, emails, or writes to a system of record, or when runs are long and unattended. You do not need most of it for a read-only assistant that answers one question with a few tool calls while the user watches. There, a step cap, a timeout, and showing the error to the user are enough. And if the task is a fixed sequence with no model choice in it, write it as an ordinary workflow instead of an agent.

"It works in the demo, how do you make it production-ready?" is the most common senior follow-up in agent design rounds. A mid-level answer names retries, idempotency keys, and human approval for risky actions. A senior answer explains why errors compound, places validation and verification around each action, makes the run survive a crash, and debugs a bad run from its trace. The chapters follow the order you would use in the interview, from why runs fail to the controls around one call, one run, and the people watching it.