The most common failure mode in agent work is not a broken model. It is a broken prompt. The agent produces the wrong output, goes off track, ignores a constraint, or gives a answer that is plausible but not what was asked for. In each case, the instinct is to blame the model. The actual cause is usually the prompt.

This matters because prompts are fixable. Model behavior is partly outside the operator's control. Prompt design is entirely within it. Learning to see failures as prompt failures — and to know what a good prompt looks like — is the core craft skill in agent work.

This piece is the catalog. It names the patterns that work reliably, describes why they work, and pairs each pattern with the anti-pattern that looks similar but fails. The goal is a reference that can be consulted when a prompt is not working and the operator needs to know what to change.

The ReAct pattern

ReAct stands for Reason, Act, Observe. The agent thinks about what to do, takes an action (usually a tool call), observes the result, and loops. The pattern is the backbone of most working agent loops.

The basic shape: the prompt tells the agent to reason step by step, to take an action, to observe the result, and to decide whether to continue or stop. The agent produces a thought, takes an action, and the action's output becomes the next input. This continues until the agent decides it has enough to answer.

The ReAct pattern is the foundation of the working agent loop. Without it, the agent produces a single response without observing whether it is correct. With it, the agent can try, check, and try again.

Variations worth knowing: ReAct with planning adds a planning step before the first action — the agent lays out its approach before executing it. ReAct with reflection adds a self-check at the end of each loop — the agent asks whether its current answer is actually correct. ReAct with retrieval adds a retrieval step — the agent fetches relevant context before acting.

The piece on inside the agent loop covers where ReAct lives in the six-stage model and what can go wrong at each stage.

The role, task, constraints, and examples pattern

The four-part prompt is the most reliable general-purpose prompting structure. It has four components: role (who the agent is), task (what to do), constraints (what not to do), and examples (what success looks like).

Role sets the agent's identity and perspective. "You are a senior software engineer reviewing a pull request" produces different output than "you are a helpful assistant." The role shapes what the agent assumes about its own knowledge, its audience, and what counts as good work.

Task describes what to produce, in what format, and by what criteria. A good task statement is specific. "Summarize this document in three sentences" is specific. "Summarize this document" is not — three sentences is the specificity that prevents the agent from producing a two-paragraph summary when a three-sentence summary was wanted.

Constraints bound the output. "Do not use jargon" is a constraint. "Do not mention price" is a constraint. "Stay under 200 words" is a constraint. Constraints prevent the agent from doing things that are technically correct but unwanted.

Examples are demonstrations of the right output. Two to five examples of the right answer, in the right format, with the right style, teach the agent more than a paragraph of description. The agent infers the pattern from the examples rather than having to parse a rule.

The piece on best ways to ask an agent covers the four-part structure in more detail.

The chain-of-thought pattern

Chain-of-thought asks the agent to reason step by step before producing the final answer. The instruction is simple: "think step by step." The effect is significant on complex reasoning tasks.

Chain-of-thought helps when the task has multiple steps, when the answer depends on an intermediate result, when the task involves math or logic, or when the task requires the agent to catch its own errors before delivering the answer. Asking the agent to show its work produces better work than asking for the answer directly.

Chain-of-thought does not help on simple retrieval tasks — asking "what is the capital of France?" with chain-of-thought produces verbose output for no benefit. It does not help when the operator does not have time to read the reasoning. And it does not help when the agent is being used as a tool by another agent that only wants the final answer.

The signal for when to use chain-of-thought: the task has a wrong answer that looks right, the task has multiple steps, or the operator needs to verify the reasoning before trusting the answer.

The few-shot pattern

Few-shot prompting shows the agent two to five examples of the right output for a given input. The examples teach the agent the format, style, edge cases, and conventions the operator wants without requiring a long description.

Few-shot helps most when the output format is specific and non-obvious — a JSON structure, a markdown table, a particular style of response. It also helps when the task has edge cases that are easier to show than to describe. "When the date is missing, return null" is clearer as an example than as a rule.

Few-shot is often overkill when the task is well-defined and the model already handles it. Showing the agent five examples of "normal" summaries when the model already produces good summaries is a waste of the prompt's example budget. Save few-shot for the cases where the model's default behavior is wrong and a description of the correction would be longer than the examples.

Anti-pattern: the kitchen-sink prompt

The kitchen-sink prompt puts every requirement, every constraint, every example, and every piece of context into a single long message. The theory is that more information produces more accurate output. The practice is that more information produces more confused output.

The failure mechanism is attention distribution. The model attends to all of the prompt equally, but not all of the prompt is equally important. When everything is labeled as important, nothing is. The agent responds to the wrong cue, ignores a critical constraint, or produces output that technically satisfies everything but is not useful.

The fix is bounded prompts. Each prompt has one job. If the task is multi-step, decompose it into steps and run them separately, with the output of each step feeding into the next. A prompt that fits in a screen is more debuggable than a prompt that requires scrolling.

Anti-pattern: the inconsistent prompt

The same task described differently across sessions produces different outputs. The agent is not being stubborn or random — it is responding to the different prompt. When the prompt changes, the output changes.

The inconsistency problem shows up most clearly when the operator wants a consistent recurring output — a daily report, a weekly summary, a standard-format response. If the prompt that generates it changes every time, the output changes every time. The operator then has to edit the output to match the desired format, which defeats the purpose of having the agent produce it.

The fix is a prompt library: a standardized prompt for each recurring output, stored in a file, reviewed and improved over time. The prompt is stable; only the input data changes. This produces consistent output without requiring the operator to reconstruct the prompt from memory every time.

Anti-pattern: the vague prompt

"Help me with the website" is a prompt the agent cannot act on. It is not specific enough to determine what kind of help is needed, what the deliverable is, or what the constraints are. The agent responds with a reasonable-sounding but directionless overview. The operator is not helped.

The fix is specificity. "Help me" is not a task — it is a request for a task. The operator's job is to name the task. "Review the copy on the /about page for clarity and rewrite the three weakest paragraphs" is a task. It has a scope, a format, and a success criterion. The agent that receives it can act on it.

The distinction matters at the prompting stage. If the operator is not specific enough, the agent cannot be specific in its response. The vagueness is in the prompt, not in the model.

Anti-pattern: the constraint-as-promise

"do not hallucinate citations" tells the agent what not to do but not what to do instead. The agent dutifully avoids inventing a citation, then has no plan for how to produce citations at all. The output is technically compliant with the constraint and practically useless.

The fix is directives, not constraints. Instead of "do not do X," say what to do instead. "When you need to cite a fact, use only the documents provided in context. If no document supports the fact, say 'this is not supported by the provided documents.'" The directive gives the agent something to do; the constraint only gives it something to avoid.

The verification loop

The most powerful pattern in the catalog is the simplest: after producing output, the agent checks the output against the prompt. Did I do what was asked? Is the format correct? Did I stay within the constraints? Is the answer actually correct?

This is the verification loop, and it is what separates agents that catch their own errors from agents that produce confident wrong answers. The model has no internal mechanism for knowing whether its output is correct. The check is external: a verification step, a test, a review.

The implementation is a separate prompt or a separate tool call that examines the output. "Review the following summary and check: does it stay within 200 words? does it cover the three main points? is the tone consistent?" The verification step adds cost — one extra model call — but it catches errors before they propagate.

The piece on model behavior: laziness, hallucination, accuracy covers the model behaviors that make verification necessary and how to design for it.

What this is not

This piece is not a complete catalog of prompting techniques. The field is large and growing. The patterns here are the ones that reliably appear across different models, different tasks, and different agent frameworks. They are not the only patterns — they are the patterns that have earned their place through repeated use.

This piece is not a guarantee that using the patterns prevents failures. Each pattern has implementation-specific failure modes. A ReAct loop can loop forever. A four-part prompt can have a role that conflicts with the task. A chain-of-thought can produce confident wrong reasoning that looks valid. The patterns reduce failure rates; they do not eliminate them.

See also