Most prompt advice is about getting a better answer out of a model on the first try. Prompting for reliability is a different problem: getting the same acceptable answer out of the model on the thousandth try, including the tries where the input is malformed, the API call times out, or the data is just missing. Clever prompts optimize for the demo. Reliable prompts optimize for the Tuesday afternoon six weeks from now when nobody is watching.
I have stopped writing prompts with personality. No “you are a world-class analyst,” no tone instructions, no enthusiasm. Personality is a surface feature that has nothing to do with whether the agent behaves the same way twice. What actually moves reliability is naming agent failure modes before they happen, and telling the model exactly what to do when one occurs.
Prompting for reliability means naming failure modes first
A prompt that only describes the happy path has described half the job. Before I write the instructions for what the agent should do, I write the list of ways the input or the environment can go wrong: a field is empty, a tool returns an error, a lookup returns three matches instead of one, the user’s request is ambiguous between two valid interpretations. Each of those gets an explicit line in the prompt: not “use your judgment,” but a specific instruction: flag it, ask once, default to the conservative option, stop and return a reason. Failure mode handling is the part of the prompt that does the actual work; the rest is formatting.
This matters more in agent workflows than in single-shot prompting because failures compound. A model that guesses politely on a bad input in a chatbot produces one bad answer. The same guess inside a multi-step agent produces a bad answer that then gets passed as input to the next step, and the next, until the thing that finally breaks is three steps removed from the actual cause. That unattributed failure pattern is most of how agent pilots die in production: a quiet wrong guess nobody told the model not to make, rather than one dramatic error.
Structured output prompts remove ambiguity the model would otherwise fill
If you don’t specify the shape of the output, the model will invent one, and it will invent a different one under slightly different inputs. Structured output prompts (a fixed schema, explicit field names, explicit types, explicit handling for fields that cannot be filled) turn “describe what you found” into something a downstream system can parse without a human checking it first. This is not about making the output more precise in a general sense. It is about making it the same shape every time, so that a parsing failure is loud and immediate instead of silent and three steps downstream.
The boring version of this looks like a form. That is the point. A form has no room for the model to be creative about structure, which is exactly where llm reliability problems usually originate: not in the reasoning, but in the model deciding on its own that this particular case deserves a different format.
System prompt design should assume someone else will read it at 2am
Write the system prompt for the person debugging it under pressure, not for the model. Good system prompt design states assumptions plainly: what counts as success, what counts as a failure that should stop execution, what the agent is explicitly not allowed to decide on its own. If a non-engineer on the team can read the prompt and tell you what the agent will do with a blank field, the prompt is doing its job. If they can’t, neither can the model, most of the time.
This overlaps with a distinction worth checking before you invest further: whether what you’re building is actually an agent making decisions, or a fixed pipeline with a model bolted into one step. That ten-minute test matters here because the failure-mode list you need is completely different depending on the answer. A workflow needs validation at each handoff. An agent making its own calls needs those calls bounded, with an explicit list of what it is not permitted to decide.
Where the discipline actually pays off
The five workflows that show up in nearly every engagement (the ones I rebuild for almost every client) are boring for the same reason reliable prompts are boring. They have been stripped of anything that only works when the input looks like the demo. Those five workflows succeed because someone already wrote down, explicitly, what happens when a record is missing a field, and never left it to the model to decide.
Cleverness in a prompt is a cost you pay once, at the demo. Reliability is a cost you pay once, in the prompt, and collect on every run after that.