The Prompting & Context Engineering Catalog

Source: Pattern documented across vendor documentation; specific patterns in Anthropic’s prompt engineering guide, OpenAI’s prompt engineering guide, Google’s Gemini prompting guide

Intent

Design system prompts that produce reliable agent behavior across the range of user inputs by establishing role, capabilities, constraints, and output guidelines in a structure the model handles well.

Motivating Problem

System prompts that are too brief produce inconsistent behavior; the model fills gaps with defaults that may not match the intended agent. System prompts that are too long dilute attention and may trigger lost-in-the-middle effects within the prompt itself. System prompts with conflicting or vague instructions produce unpredictable behavior. The discipline is finding the right amount of specificity --- enough to produce reliable behavior, not so much that the prompt becomes unwieldy.

How It Works

Standard structure: most production system prompts follow a pattern. Role definition first (“You are X, a specialized assistant for Y”), capability description second (“You can help with A, B, C”), constraints third (“You will not D, E; if asked about D, say F”), output guidelines fourth (“Respond in X format; use Y tone”). For short prompts the order matters little. For long prompts, Anthropic’s guidance is to put bulk material (documents, data) first and the task and key constraints after it; it reports that queries placed at the end improve response quality. On OpenAI models these instructions go in a developer message (or the Responses API instructions field), which the model ranks above user messages.

Explicit vs. implicit constraints: explicit constraints (“do not discuss competitor products”) work more reliably than implicit ones (“stay on topic”). The model’s interpretation of implicit constraints varies; explicit constraints leave less room for the model’s judgment to diverge from the intended behavior.

Concrete behavior descriptions: “When the user asks about X, do Y” works better than “Handle X questions appropriately.” The concrete pattern gives the model a specific behavior to imitate; the abstract pattern relies on the model’s interpretation of “appropriate.”

Persona vs. role: persona (“You are a friendly, knowledgeable cooking assistant”) shapes tone and approach but not specific behavior. Role (“You are a customer support agent for Acme Inc.”) shapes specific behavior through the role’s associated expectations. Production system prompts typically combine both: persona establishes tone, role establishes capability scope.

Length considerations: production system prompts range from 100 tokens for simple agents to 5000+ tokens for complex agents with many tools and constraints. The right length depends on the agent’s complexity; shorter is generally better when shorter suffices. The discipline is fitting the necessary instructions in the minimum space, not maximizing the prompt to cover every possible case.

When to Use It

Every production agent has at least a brief system prompt; the question is how much structure and specificity to include. Use the standard pattern (role, capability, constraints, output) as a starting point; expand specific sections as the agent’s requirements demand. Use explicit over implicit constraints; use concrete behavior descriptions over abstract ones.

Alternatives --- packaged Skills (Volume 2) for cases where the instructions are large enough to be reusable artifacts. Multi-turn priming where the first user turn establishes context that the system prompt alone wouldn’t convey.

Sources

• platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

• developers.openai.com/api/docs/guides/prompt-engineering

• ai.google.dev/gemini-api/docs/prompting-strategies

Example artifacts

Code.

<!-- Anthropic-style system prompt with XML structure -->

<role>

You are a research assistant specialized in technology industry
analysis. You help users

understand market dynamics, competitive positioning, and emerging
trends.

</role>

<capabilities>

- Summarize industry reports and analyst coverage

- Compare products and companies on specific dimensions

- Identify trends from time-series data

- Flag conflicting information from different sources

</capabilities>

<constraints>

- Always cite sources when making factual claims

- Acknowledge uncertainty when sources disagree or data is
incomplete

- Do not predict stock prices or make investment recommendations

- If asked about regulated activities (securities, healthcare),
recommend consulting

a qualified professional rather than answering directly

</constraints>

<output_guidelines>

- Use markdown for structure (headers, bullets, tables) when content
has structure

- Use plain prose for narrative explanations

- Include a 'Sources' section at the end listing references

- Keep tone professional but accessible; avoid jargon when simpler
words work

</output_guidelines>

Source: Brown et al., “Language Models are Few-Shot Learners” (GPT-3 paper, 2020); accumulated practitioner knowledge through 2022—2026

Intent

Improve model performance on specific tasks by including 1—N examples of desired input→output pairs in the prompt, allowing the model to infer patterns from the examples rather than relying on instruction-following alone.

Motivating Problem

Some tasks have specific format requirements, idiosyncratic conventions, or rare patterns that the model handles inconsistently zero-shot. Few-shot prompting bridges the gap: showing examples of the desired pattern produces more consistent compliance than describing it. The technique was foundational through 2022—2023 when zero-shot performance was unreliable for many tasks. By 2026 the technique is more selective --- modern models handle many tasks zero-shot adequately --- but it remains valuable for specific use cases.

How It Works

Number selection: 1-shot (one example), few-shot (typically 2—5), N-shot (more, up to context window limits). More examples improve pattern recognition for tasks where the pattern is genuinely complex; fewer examples are sufficient for tasks where the pattern is simple enough that 1—2 examples suffice. Diminishing returns set in quickly; production deployments rarely use more than 5—10 examples.

Example selection: the examples should cover the range of cases the agent will encounter. Production patterns include manual curation (engineers select representative examples), retrieval-augmented few-shot (the most similar examples to the current input are selected dynamically from a larger pool), and diverse selection (examples chosen to cover edge cases as well as common cases).

Ordering effects: examples earlier in the prompt typically have stronger influence; this is the same lost-in-the-middle pattern that affects long contexts generally. Production patterns: put the most representative examples first; vary difficulty progression (some practitioners put easy examples first to establish the pattern, then harder ones; others put hard examples first to emphasize edge cases).

Format consistency: the examples should match the desired output format exactly. Inconsistent example formats confuse the model; the model may produce output that mixes the formats it saw. The discipline is treating the examples as a strict format specification, not just a pattern hint.

When few-shot stops helping: modern models handle many tasks zero-shot adequately. Few-shot for these tasks adds context-window cost without proportionate benefit. The discipline is testing whether few-shot actually improves performance vs. zero-shot for the specific task and model; defaulting to few-shot for everything wastes context budget.

When to Use It

Tasks with specific format requirements where consistency matters. Idiosyncratic conventions specific to the application that the model wouldn’t know. Rare patterns or domains where the model’s training data didn’t include enough examples. Cases where zero-shot testing shows specific failure modes that examples address.

Alternatives --- zero-shot prompting with detailed instructions for cases where modern models handle the task adequately without examples. Fine-tuning for cases where the pattern is consistent enough and the volume high enough to justify dedicated training. Retrieval-augmented few-shot for cases where the pattern varies by input and dynamic example selection helps.

Sources

• Brown et al., “Language Models are Few-Shot Learners” (2020)

• platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices (3-5 examples, consistent format)

Source: Wei et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models” (2022); reasoning-trained model documentation

Intent

Improve performance on complex reasoning tasks by prompting the model to think step-by-step before producing the final answer, and understand how reasoning-trained models have shifted the technique’s applicability.

Motivating Problem

Many reasoning tasks (math problems, multi-step logic, complex analysis) benefit from explicit reasoning rather than direct answer generation. Through 2022—2023, prompting the model to “think step by step” before answering produced substantial accuracy improvements on these tasks. The technique entered production widely. Through 2024—2026, reasoning-trained models internalized the pattern, and by 2026 reasoning is the default mode of the main OpenAI, Anthropic and Google model lines; explicit chain-of-thought prompts became less necessary for these models because the model reasons internally before producing output.

How It Works

Classical chain-of-thought: include “think step by step” or similar in the prompt; the model produces explicit reasoning followed by the final answer. Variants include “think carefully,” “work through this step by step,” “show your work,” and structured-thinking patterns that ask for specific reasoning phases. The technique works on non-reasoning-trained models and improves accuracy on complex tasks substantially.

Zero-shot chain-of-thought: a particularly effective variant uses “Let’s think step by step” as a magic phrase that triggers chain-of-thought without examples. The pattern emerged from research showing this specific phrasing was unusually effective; the effect varies across models but the pattern remains useful.

Few-shot chain-of-thought: combines chain-of-thought with few-shot prompting. Examples include both the reasoning and the final answer; the model learns to imitate both. The pattern is more powerful than either alone for complex tasks but consumes more context window.

Reasoning-trained models: OpenAI’s GPT-5 family and later (tuned with reasoning.effort), Claude with adaptive thinking and the effort parameter, and Gemini thinking models (tuned with thinking_level) reason internally. The model reasons during a dedicated reasoning phase before producing user-visible output; the explicit chain-of-thought prompt is unnecessary because the model is already doing the reasoning. On these models, tune the effort level (see Reasoning effort control, below) instead of asking for step-by-step reasoning; current Claude models reject the older manual thinking budget (budget_tokens) with a 400 error.

Hybrid use: production agents that use both reasoning-trained and non-reasoning-trained models for different subtasks need different prompting for each. The reasoning-trained model gets direct task descriptions; the non-reasoning-trained model gets explicit chain-of-thought prompts. The architectural pattern emerged through 2025—2026 as teams discovered that the right model for each subtask varies and the prompts need to vary with it.

Visibility considerations: reasoning-trained models typically produce extensive internal reasoning that may not be shown to users. APIs expose reasoning summaries or opt-in thinking blocks, not the raw reasoning: OpenAI returns summaries through the reasoning summary parameter, Gemini returns thought summaries when enabled, and current Claude models omit thinking text by default unless the request asks for a summarized display. Production UIs often hide even the summaries by default with progressive disclosure (Volume 13 covers). Whether to show reasoning to users is a UX decision separate from the prompting decision.

When to Use It

Complex reasoning tasks on non-reasoning-trained models. Math problems, multi-step logic, careful analysis of conflicting evidence. Tasks where the user benefits from seeing the reasoning (educational use cases, transparency-required use cases). Cases where reasoning quality matters more than latency.

Skip for reasoning-trained models doing tasks they’re already reasoning about. Skip for simple tasks where chain-of-thought adds latency and tokens without benefit. Skip when the cost of additional output tokens (reasoning is verbose) exceeds the accuracy improvement.

Sources

• Wei et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models” (2022)

• Kojima et al., “Large Language Models are Zero-Shot Reasoners” (2022)

• platform.claude.com/docs/en/models/sonnet-5-5/migration-guide (adaptive thinking, thinking display)

• developers.openai.com/api/docs/guides/reasoning (reasoning effort, reasoning summaries)

• ai.google.dev/gemini-api/docs/thinking (thinking_level, thought summaries)

Source: Anthropic effort parameter documentation; OpenAI reasoning guide; Google Gemini thinking documentation

Intent

Trade answer quality against latency and token cost per call by setting the model’s effort level (Anthropic effort, OpenAI reasoning.effort, Gemini thinking_level), instead of prompting for more or less reasoning or setting a fixed thinking budget.

Motivating Problem

Reasoning models decide for themselves how long to think, and the default is tuned for hard problems. A routing step, a subagent doing a lookup, or a classification call pays the latency and tokens of deep reasoning it does not need; a long agentic coding task may need more than the default gives it. Older controls no longer fit: asking for step-by-step reasoning is redundant on a model that already reasons, current Claude models reject manual thinking budgets with a 400 error, and the frontier APIs are retiring sampling parameters (see Sampling parameters, Section D). The effort level is the control the vendors now offer for this trade-off.

How It Works

Anthropic: set output_config.effort on the request. Levels are low, medium, high, xhigh and max, with xhigh and max available only on some models. High is the default on most models; Claude Opus 5.5 and Claude Haiku 5.5 default to medium. Effort applies to every output token, including text, tool calls and thinking, so lower effort also means fewer and terser tool calls. Anthropic describes it as a behavioral signal, not a strict token budget: at low effort Claude still thinks on hard problems, only less. At high effort and above, set a large max_tokens, which caps thinking plus response text.

OpenAI: set reasoning.effort. Supported values depend on the model and can include none, minimal, low, medium, high, xhigh and max. The models also reason adaptively within a level, using fewer tokens on simple tasks. OpenAI’s guide recommends xhigh only when evals show a benefit that justifies the extra latency and cost.

Google: set thinking_level. Gemini models think dynamically by default, and the supported levels and defaults vary by model (for example, minimal through high on some Flash models, with medium as a common default).

Choosing a level: start at the model’s default, run the eval suite (Section E) at the levels on either side, and step down for routine or latency-sensitive calls once quality holds. In multi-model or multi-agent systems, give each call its own level: low for subagents and routing, the default or higher for the planning and coding steps.

When to Use It

Every call to a current reasoning model runs at some effort level; the pattern is choosing it per call type instead of accepting the default everywhere. Lower it for high-volume, simple or latency-bound calls. Raise it for long-horizon agentic and coding work where the evals show a gain. Volume 16 covers the cost side of this choice.

Alternatives: a non-reasoning or smaller model for calls that need no reasoning at all; chain-of-thought prompting (above) on models with no effort control; sampling parameters on older and self-hosted models.

Sources

• platform.claude.com/docs/en/build-with-claude/effort

• developers.openai.com/api/docs/guides/reasoning

• ai.google.dev/gemini-api/docs/thinking

Source: Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023); accumulated practitioner knowledge through 2024—2026

Intent

Determine what content goes into the context window and in what order to maximize the model’s ability to use it effectively, recognizing that larger context windows have not eliminated the need for this engineering.

Motivating Problem

Large context windows let agents include more content than smaller windows allowed, but the model’s ability to use the content degrades as content grows. Lost-in-the-middle effects mean information buried in the middle of a long context is recalled less reliably than information at the start or end. Attention dilution means instructions in a context with much surrounding content compete with the surrounding content for attention. Instruction-following degrades subtly as context length grows. The naive approach --- include everything that might be relevant --- produces context that’s technically within the window but in which the model’s performance has degraded.

How It Works

Selection patterns: include what’s decision-relevant; exclude what isn’t. The challenge is determining relevance before the model runs. Patterns: recency-based selection (recent conversation turns matter more than old ones; recent tool results matter more than old ones), similarity-based selection (semantic similarity to the current query/task), explicit tagging (the agent’s logic marks specific content as required vs. optional), LLM-based pre-filtering (a smaller cheaper model judges relevance before the main model runs).

Ordering patterns: avoid burying decision-critical content in the middle of the window. Vendor guidance is specific: Anthropic recommends putting long documents at the top, each wrapped in <document> tags with its source and other metadata, and the question and instructions last, and reports that queries at the end improve response quality on multi-document inputs. For RAG, this means retrieved documents first, the most relevant at the edges of the retrieved-context section rather than in its middle, and the task after them. For conversation history, this means summarizing or repeating key prior content near the start of the current context window rather than relying on the model to find it in the middle of a long history.

Lost-in-the-middle phenomenon: documented in Liu et al. (2023) and confirmed across many models. Information at the beginning of a long context (“primacy” effect) and at the end (“recency” effect) is recalled reliably; information in the middle of long contexts is recalled less reliably. The effect varies by model and task but the general pattern persists across providers.

Trade-off considerations: context engineering adds engineering complexity. Production agents that don’t engineer context can still work; they just underperform what they could be. The discipline is justified when the agent’s value depends on careful use of available context (RAG-heavy agents, multi-turn agents with long histories, agents with many tools); it’s less critical for short-interaction agents where context engineering has less room to help.

Tools that help: agent frameworks (Volume 14 covers) provide primitives for context management. LangGraph’s state management, LlamaIndex’s indexing and retrieval, custom solutions built on agent frameworks. The tools don’t make context engineering automatic; they provide the primitives the team uses to implement the engineering discipline.

When to Use It

Production agents where context window approaches half of nominal capacity or more. RAG-heavy agents where retrieved content competes with other context for window space. Multi-turn agents with long conversation histories. Agents with many tools whose definitions consume significant context budget.

Alternatives --- architectural changes that reduce context needs (memory persistence via Volume 6 rather than including full history in context; specialized smaller agents for sub-tasks instead of one large agent handling everything). The right alternative depends on whether context engineering or architectural change addresses the root cause.

Sources

• Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023)

• platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices (long context prompting)

• Various papers on long-context model evaluation and limitations

Source: Various academic and practitioner papers on summarization and compression for LLM context

Intent

Compress context content when the relevant material exceeds the available context budget, using summarization, extraction, hierarchical retrieval, or compression-specific models, with explicit awareness of the trade-offs each compression approach introduces.

Motivating Problem

Even with large context windows, some applications have more decision-relevant content than fits. Long-running conversations accumulate history. RAG corpora can be vast. Tool result chains can compound across many calls. When the relevant content exceeds the available budget, compression becomes necessary. The choice among compression strategies depends on what information needs to be preserved and what can be lost; each strategy has characteristic trade-offs.

How It Works

Summarization (lossy): replace prior content with model-generated summaries. The summary preserves overall content at higher information density but loses specifics. Useful for conversation history where the gist matters more than exact wording; less useful for cases where specific facts or numbers need to be preserved exactly.

Extraction (precise): pull specific facts, decisions, or key information from prior content into a structured form. Less lossy than summarization for the extracted facts but discards everything not extracted. Useful for cases with well-defined facts to track; less useful for cases where the narrative or context around facts matters.

Hierarchical retrieval: store full content in an external retrieval system; retrieve summaries first; retrieve details on demand when specific information is needed. The pattern works well for RAG corpora where most documents are not relevant to most queries; it adds latency through additional retrieval round-trips when details are needed.

Compression models: dedicated smaller LLMs trained to compress context for larger ones. The compression model takes a long context and produces a shorter one optimized for downstream model consumption. The approach is more sophisticated than naive summarization but adds complexity (another model to run, another point of failure, another evaluation challenge); production adoption is uneven.

Sliding window patterns: keep the most recent N turns at full fidelity; summarize older turns; further-summarize the oldest turns. The hierarchical aging pattern matches how human memory works and fits many production conversation patterns.

Selective preservation: identify content that must be preserved exactly (specific facts the user mentioned, specific tool results referenced) and content that can be compressed. Apply different compression strategies to different categories. The pattern is more complex to implement but produces better results than uniform compression.

For conversation history inside a long agent run, Anthropic and OpenAI now do the summarization on the server; see Server-side compaction, below.

When to Use It

Long-running conversations where full history exceeds context window. RAG systems where the relevant retrieved content exceeds the budget. Multi-step agent workflows where prior tool results accumulate. Production deployments where context budget management is a recurring concern.

Alternatives --- larger context windows where the issue is purely “doesn’t fit” rather than “doesn’t help.” Architectural changes that reduce context needs (Volume 6 memory patterns; Volume 10 retrieval patterns). The right alternative depends on whether the content is fundamentally too large or whether the architecture is making the content larger than it needs to be.

Sources

• Academic literature on context compression and summarization

• Practitioner documentation in LangChain, LlamaIndex, and related framework documentation

Source: Anthropic compaction documentation (compaction on demand and at a token threshold); OpenAI Responses API compaction guide; Anthropic Engineering, “Scaling Managed Agents” (April 2026)

Intent

Keep a long-running agent inside its context window by having the API replace older turns with a provider-written summary, triggered on demand or at a token threshold, instead of writing and maintaining a summarization loop in the application.

Motivating Problem

A long agent run accumulates turns, tool calls, tool results and thinking until it nears the window, and quality degrades well before that point. The hand-built fix (the summarization patterns in Context compression patterns, above) means writing the summarization call and its prompt, deciding when to run it, rewriting the history, and keeping that code working as the model and its message format change. Each team rebuilt the same loop. Anthropic and OpenAI now run it on the server.

How It Works

Anthropic: compaction replaces the older turns of a conversation with a summary Claude writes on the server. Compaction on demand lets the application request the summary and place the returned compaction block first in the messages, in place of the turns it covers; options keep the most recent turns word for word, run the compaction in the background, or replace the default summarization prompt. Compaction at a token threshold is a single parameter on ordinary requests: when input tokens reach the trigger, the API compacts inside that request and drops what came before the block. Both are in beta.

OpenAI: in the Responses API, setting context_management with compact_threshold makes the server run a compaction pass when the rendered token count crosses the threshold, emit a compaction item in the same response stream, and prune the context before continuing. A standalone /responses/compact endpoint does the same on request. The compaction item is encrypted and not meant to be read; the returned window is the next context window and should be passed back as-is, not pruned.

Tool-result clearing: a cheaper complement that runs no model. Old tool results (and on Claude, old thinking blocks) are cleared by rule once context grows, keeping the record that the call happened. Anthropic exposes this as context editing; Volume 3 (memory tool) covers its configuration.

Keep what compaction discards: compaction is irreversible inside the context window. Anthropic’s Managed Agents write every event to a session log outside the window, so the agent can re-read earlier context after a compaction; agent-written progress notes and the memory patterns in Volume 6 serve the same purpose.

When to Use It

Long agent tasks and long conversations that approach the context window, on a provider that offers it. Prefer it to a hand-written summarizer unless the application needs a summary format the provider’s prompt cannot be made to produce. Pair it with tool-result clearing for tool-heavy agents, and with an external log or memory when later turns may need exact earlier content.

Alternatives: client-side summarization (Context compression patterns, above) for providers without compaction or when full control of the summary is needed; tool-result clearing alone when tool output is most of the growth; splitting the work across subagents with fresh contexts (Volume 9).

Sources

• platform.claude.com/docs/en/build-with-claude/compaction

• developers.openai.com/api/docs/guides/compaction

• anthropic.com/engineering/managed-agents

• tianpan.co/blog/2026/02/26/context-engineering-memory-compaction-tool-clearing

Source: OpenAI structured outputs (Aug 2024); Anthropic structured outputs (JSON outputs and strict tool use); Google Gemini structured output (JSON Schema response format); Pydantic-based structured output libraries

Intent

Get reliable, parseable structured output (JSON, XML, custom formats) from LLMs using vendor-provided structured output features where available, falling back to prompt engineering and validation patterns where they aren’t.

Motivating Problem

Many production agents need to produce structured output that downstream systems parse --- API calls, database operations, structured analyses, configuration generation. Through 2022—2023, achieving this reliably required prompt engineering: explicit format specifications, examples of valid output, validation prompts, retry loops on parse failures. Through 2024—2026, vendor features absorbed much of this work: OpenAI’s structured outputs (announced August 2024) guarantee 100% schema compliance for JSON outputs; Anthropic’s structured outputs (output_config.format, and strict: true on tools) guarantee schema-valid JSON through constrained decoding; Gemini has a JSON Schema response format separate from function calling. The prompt engineering work remaining is narrower but still real.

How It Works

Vendor structured output features: define a JSON schema or Pydantic model; the model is constrained to produce output that exactly matches the schema. OpenAI’s structured outputs use grammar-constrained decoding under the hood to guarantee compliance. Anthropic offers two features on the same mechanism: JSON outputs (output_config.format with type json_schema) constrain the response itself, and strict tool use (strict: true on a tool definition) constrains tool names and inputs. Forcing a tool call with tool_choice (type “tool” or “any”), the older way to coerce a schema through tools, returns a 400 error on Claude Sonnet 5.5; Anthropic’s guidance is tool_choice auto plus a strict tool. The features work for cases where the schema is known and the structure fits the feature’s constraints.

When vendor features apply: most production structured output use cases. JSON outputs for downstream APIs. Function call arguments. Configuration generation. Structured analysis with predefined fields. The features work for these and should be the default choice when available.

When vendor features don’t apply: outputs that aren’t JSON (XML, custom delimited formats, prose with embedded structure). Outputs whose structure varies based on the input (different schemas for different cases). Outputs that need to be partially structured and partially free-form. Cases where the vendor feature has limitations (Anthropic’s tool use has some schema patterns it handles less well; OpenAI’s structured outputs have some recursive schema limitations).

Fallback prompting patterns: when vendor features don’t apply, the older prompting discipline applies. Explicit format specification in the prompt (“Respond with JSON matching this schema…”). Example outputs showing the expected structure. Validation prompts that check the output before downstream use. Retry loops on parse failures, with explicit error feedback to the model.

Pydantic-based libraries: Instructor, Outlines, and similar libraries provide schema-based structured output across providers. Some use vendor features under the hood; some use prompting plus validation. They provide cross-provider abstractions over the vendor-specific features.

XML and custom formats: for Anthropic Claude specifically, XML-tag-delimited outputs work reliably through prompt design alone (the model is trained well for this pattern). Other custom formats can work through prompt engineering but require more careful prompt design and validation.

Migrating from assistant prefill: older Claude models let the request end with a partial assistant message (an opening brace, say) that the model continued, which anchored the output format. Starting with Claude 4.6 models, a prefilled last assistant turn returns a 400 error. Anthropic’s migration guidance: use output_config.format or a strict tool for format, system-prompt instructions to suppress preambles, and move continuations into the user turn.

When to Use It

Any production agent that needs to produce parseable output for downstream systems. Use vendor structured output features as the default when they apply; the reliability is much better than prompt engineering alone. Fall back to prompt engineering for cases the vendor features don’t cover.

Alternatives --- unstructured output with downstream parsing for cases where the parsing is robust enough to handle variability. Tool calling for cases where the structured output is naturally a function call. The boundary between structured output and tool calling is fuzzy; production deployments often use tool calling for what is logically structured output.

Sources

• openai.com/index/introducing-structured-outputs-in-the-api/

• platform.claude.com/docs/en/build-with-claude/structured-outputs

• platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices (migrating away from prefilled responses)

• ai.google.dev/gemini-api/docs/structured-output

• github.com/567-labs/instructor (Instructor library)

• github.com/dottxt-ai/outlines (Outlines library)

Source: Anthropic Sonnet 5.5 migration guide; Holtzman et al., “The Curious Case of Neural Text Degeneration” (nucleus sampling, 2019); OpenAI and Google generation-parameter guides

Intent

Control the randomness and diversity of model output at generation time through the decoding parameters --- temperature, top-p (nucleus sampling), and top-k --- trading determinism against exploration to match the task, rather than accepting whatever the defaults produce. On current frontier APIs these parameters are deprecated or rejected, so the pattern now applies mainly to older models, open-weights models and self-hosted inference.

Motivating Problem

Prompt design determines what the model is asked; the decoding parameters determine how it selects among candidate tokens once it has been asked. The same prompt produces different output depending on these settings, and teams that leave them at defaults hit two opposite failure modes: extraction and classification tasks come back inconsistent because the sampling is too random, and ideation tasks come back flat and repetitive because it is too constrained. The parameters are a small control surface --- three numbers --- that prompt engineering alone does not address, and getting them wrong undermines otherwise well-designed prompts. They also govern reproducibility: without deliberate settings, the same input is not guaranteed to give the same output across calls.

How It Works

Deprecation on current models: all three major vendors are retiring these knobs. Claude Sonnet 5 and Sonnet 5.5 return a 400 error when temperature, top_p or top_k is set to a non-default value, and Anthropic’s migration guide says to remove them and steer tone and variety through the prompt; older Claude models still accept them. Gemini 4 and Gemini 3.6+ models ignore custom values with deprecation warning headers, and Google says they will return 400 errors in a future release. OpenAI reasoning models reject non-default temperature and top_p unless reasoning effort is none. On these models, use effort levels (Reasoning effort control, Section B), prompt instructions, and multiple candidates for variety. The rest of this entry describes the parameters where they still apply.

Temperature: scales the logit distribution before the final softmax. At temperature 0 the model is greedy --- it always takes the highest-probability token, the closest the API offers to deterministic output. Raising the temperature toward 1.0 (and, on some APIs, beyond) flattens the distribution and raises the odds of lower-probability tokens being chosen. Use low temperature (roughly 0—0.3) for extraction, classification, and code, where one correct answer exists; use higher temperature (roughly 0.7—1.0) for brainstorming, drafting, and any task that benefits from variation.

Top-p (nucleus sampling): restricts sampling to the smallest set of tokens whose cumulative probability crosses the threshold p. The pool sizes itself dynamically --- a handful of tokens when the model is confident, many when it is uncertain. Typical production values sit around 0.9—0.95. Top-p caps the long tail of implausible tokens without fixing the pool size the way top-k does.

Top-k: restricts sampling to the k highest-probability tokens, a fixed-size pool regardless of the model’s confidence. A top-k of 1 is greedy decoding; larger values admit more diversity. Top-k is the bluntest of the three and the least commonly tuned.

One knob at a time: the three parameters interact, and their effects overlap. The common guidance for models that accept them is to adjust temperature first and leave top-p and top-k at their defaults, reaching for the others only with a specific reason. Tuning several at once makes behavior hard to reason about and hard to reproduce.

The determinism caveat: temperature 0 reduces variation but does not formally guarantee identical output. Floating-point behavior, hardware, and server-side batching introduce residual nondeterminism. Treat temperature 0 as “as reproducible as the API offers,” not as a hard guarantee, and pin model versions when reproducibility matters.

Provider coverage: where the parameters are still accepted, not every provider or inference server exposes all three, and their ranges differ. Self-hosted servers and open-weights models generally expose all three.

When to Use It

On models that accept them, every call implicitly chooses these values; the discipline is choosing them deliberately. On current Claude, Gemini and OpenAI reasoning models, leave them unset. Set temperature low for structured extraction, verification, routing, and any deterministic pipeline --- this pairs directly with the structured-output and validation patterns in this section. Set it higher where diversity is the point, including the parallel-sampling patterns in Volume 1 (Parallelization --- Voting and Generator—Verifier both depend on sample diversity, from default sampling, prompt variants, or a mix of models, to make repeated samples worthwhile). As a default, change only temperature; reach for top-p or top-k when you have a concrete reason the temperature knob cannot serve.

Alternatives --- structured output features (above) constrain the shape of the output rather than its randomness; they compose with a low temperature rather than replacing it. Effort levels (Section B) are the per-call control on current reasoning models.

Sources

• platform.claude.com/docs/en/models/sonnet-5-5/migration-guide (sampling parameters return an error)

• ai.google.dev/gemini-api/docs/prompting-strategies (Gemini sampling deprecation note)

• arxiv.org/abs/1904.09751 (Holtzman et al., nucleus sampling)

• developers.openai.com/api/docs/guides/latest-model (unsupported parameters when reasoning effort is not none)

Example artifacts

Code.

from openai import OpenAI

# Self-hosted open-weights model behind an OpenAI-compatible server (e.g. vLLM),
# where sampling parameters are still honored
client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused")

# Deterministic extraction: temperature 0, one right answer
extraction = client.chat.completions.create(
    model="my-open-weights-model",
    temperature=0,
    messages=[{"role": "user", "content": "Extract the invoice total as JSON."}],
)

# Diverse ideation: higher temperature, top_p left at its default
ideation = client.chat.completions.create(
    model="my-open-weights-model",
    temperature=1.0,
    messages=[{"role": "user", "content": "Brainstorm ten taglines for a coffee brand."}],
)

# Current Claude models: omit temperature, top_p and top_k (non-default values return 400)
# and ask for variety in the prompt instead

Source: LangSmith Prompt Hub, formerly LangChain Hub (docs.langchain.com/langsmith/manage-prompts); PromptLayer (promptlayer.com); Anthropic Workbench; OpenAI prompting guide (prompts-as-code)

Intent

Treat prompts as versioned artifacts with explicit history, rollback capability, and lifecycle management, using prompt registry infrastructure that separates prompts from application code while maintaining the connection between specific prompt versions and specific deployment versions.

Motivating Problem

Prompts embedded in application code work for simple cases but produce problems at scale. Changes to prompts mix with code changes in pull request reviews, making the prompt impact hard to evaluate. Rolling back a prompt change requires a code deployment. Sharing prompts across applications requires copying code. Comparing prompt variants across deployments is hard. Prompt registries solve these problems by separating prompts from code: prompts are versioned independently, applications reference specific prompt versions, changes can be deployed and rolled back without code deployments.

How It Works

LangSmith Prompt Hub (formerly LangChain Hub): hosted prompt registry, now part of LangSmith’s Prompt & Context Hub. Prompts are stored as commits with tags and environments; applications reference them by name and commit or tag, and commit webhooks and GitHub sync connect the registry to the code repo. Integrates with LangChain framework natively but the prompts can be used outside LangChain. Free for public prompts; commercial for private/team.

PromptLayer: dedicated prompt registry with versioning, A/B testing, and observability. Integrates with multiple model providers; tracks which prompt versions are used in which requests. Commercial product with various tier options.

Vendor playgrounds: Anthropic Workbench, Google AI Studio. Each vendor has its own prompt management UI tied to their platform. OpenAI is retiring its hosted reusable prompt objects (creation de-emphasized from 2026-06-03, v1/prompts shuts down 2026-11-30). The lock-in is real (prompts saved in one vendor’s playground don’t easily move to another); the convenience is high for single-vendor deployments.

Prompts-as-code: OpenAI now recommends keeping each production prompt in a code-managed, versioned module, reviewing prompt changes in the same pull requests as the behavior they support, and rolling back with git, tags and feature flags. This is a first-class alternative to a registry, not only a fallback for small deployments: prompt and code changes are reviewed together, and eval checks run in CI.

Self-hosted patterns: some teams build their own prompt registry as part of their internal platform. The pattern is appropriate for teams with strong infrastructure capabilities and specific requirements existing registries don’t meet; for most teams, the existing registries are sufficient and self-hosting is unnecessary complexity.

Operational patterns: typical deployment workflow involves authoring prompts in the registry, testing them through registry tooling, deploying specific versions to specific environments (staging, production), monitoring performance, rolling back when needed. The pattern mirrors software deployment workflow with prompt-specific tooling.

Choice criteria: prompts-as-code for teams that want prompt and code changes reviewed together. LangSmith Prompt Hub for teams using the LangChain ecosystem. PromptLayer for teams wanting framework-agnostic prompt management with strong observability. Vendor playgrounds for single-vendor deployments with simple needs. Self-hosted for teams with specific platform requirements.

When to Use It

Production deployments with non-trivial prompt counts. Teams where multiple people change prompts. Cases where prompt changes need rollback capability separate from code rollback. Deployments where prompt A/B testing is part of the development process.

Alternatives --- prompts versioned in the application repo, with eval checks in CI, for teams that want prompt and code changes reviewed together; OpenAI’s own guidance now prefers this for production.

Sources

• docs.langchain.com/langsmith/manage-prompts

• promptlayer.com

• developers.openai.com/api/docs/guides/prompting

• Anthropic Workbench documentation

Source: Various practitioner literature; vendor evaluation tools (Claude Console evaluation tool, OpenAI Evals and Datasets); third-party (Promptfoo, Braintrust)

Intent

Apply systematic testing discipline to prompts: verify specific behaviors against test cases, detect regressions when prompts or models change, compare prompt variants quantitatively for A/B testing decisions.

Motivating Problem

Prompts have consequences. Changes to a system prompt can shift agent behavior in ways the team doesn’t anticipate; the shift can be improvement or regression. Without testing, the team learns about regressions through user complaints or visible failures, after the regression has affected users. With testing, regressions are caught before deployment, and prompt changes can be evaluated quantitatively rather than by impression. The testing discipline borrows from software testing but adapts to LLM stochasticity --- pure assertion testing doesn’t work because the same input can produce different outputs; statistical testing replaces deterministic testing.

How It Works

Test case construction: build a set of test cases that represent the agent’s expected inputs. Include common cases, edge cases, and known failure modes from production. Each test case has an input (what the user/system provides) and an expected output or assertion (what the agent should produce, possibly with tolerance for variation).

Grading strategies: exact-match grading for cases where the output is deterministic (structured outputs, specific format requirements). LLM-as-judge grading for cases where the output is open-ended and a stronger model can assess whether it meets quality criteria. Embedding-similarity grading for cases where semantic similarity to a reference matters more than exact wording. Multiple grading strategies typically apply to different parts of the test suite.

Run frequency: pre-deployment runs (test the new prompt against the suite before deploying); periodic runs (test the production prompt against the suite to catch drift); A/B testing runs (compare prompt variants statistically against the same test cases or against production traffic).

Tooling: the Claude Console has an evaluation tool for running a prompt against test cases. OpenAI is shutting down its Evals platform (read-only for existing users from 2026-10-31, shut down 2026-11-30) and points users to Datasets and graders. Vendor-neutral tools (Promptfoo, Braintrust, LangSmith) provide cross-platform evaluation; Volume 8 (Evaluation & Guardrails) describes them, including its Promptfoo and LangSmith Evaluators entries. This entry covers the practice; Volume 8 covers the tools.

Integration with observability: production observability (Volume 7) provides the traces that show how the agent actually behaved on real inputs. Eval suites bridge observability and testing: real inputs from production traces can become test cases; production failures inform new test cases; eval results inform deployment decisions.

Limitations: LLM stochasticity means tests can pass on one run and fail on another. Statistical interpretation (run each test case multiple times; report success rate; track distributions) replaces binary pass/fail. The discipline is more nuanced than software testing; the LLM-specific patterns are still evolving.

When to Use It

Production agents where prompt changes are frequent enough that regressions matter. High-stakes agents where prompt-induced failures have costs. Teams with multiple people making prompt changes who need shared validation. Cases where A/B testing prompt variants would inform deployment decisions.

Alternatives --- manual testing for simple cases where the prompt count and change frequency don’t justify automated testing infrastructure. The transition point varies; teams typically discover the need for systematic testing after experiencing a few painful regressions.

Sources

• claude.com/resources/articles/evaluate-prompts (Claude Console evaluation tool)

• developers.openai.com/api/docs/guides/evals (OpenAI Evals, deprecation notice)

• promptfoo.dev, braintrust.dev

Source: Anthropic prompt engineering guide; OpenAI prompt engineering guide; Google Gemini prompting strategies; practitioner experience across providers

Intent

Use the prompting conventions each major foundation model handles best, recognizing that cross-model portability is partial and production deployments need to be aware of which conventions they’re using.

Motivating Problem

The same prompt instruction phrased differently produces different results across models. Anthropic’s Claude family handles XML-tagged content particularly well. OpenAI’s models treat the role structure as a meaningful part of the prompt: developer messages rank above user messages. And by 2026 the same request can fail outright on one model and succeed on another, because each model accepts a different set of request parameters. Production prompts that work well on one model may underperform on another not because of capability differences but because of convention mismatches.

How It Works

Anthropic XML conventions: Claude models handle XML-tag-delimited content particularly reliably. Wrapping instructions in `<instructions>`, examples in `<examples>`, retrieved content in `<context>` or `<document>`, user input in `<user_input>` improves Claude’s ability to distinguish the parts of the prompt and produce structured output. Anthropic’s documentation explicitly recommends this convention; production deployments using Claude typically adopt it.

OpenAI developer messages and formatting: OpenAI models weight developer messages (or the Responses API instructions parameter) above user messages, following OpenAI’s model spec. The developer message sets persistent behavior; user-turn content sets the immediate task. OpenAI’s guide recommends Markdown headings and lists for prompt sections, with XML tags to delimit documents and other data.

Google Gemini conventions: Google’s guide recommends consistent delimiters, XML-style tags (such as <context> and <task>) or Markdown headings, choosing one format and using it throughout a prompt.

Supported request parameters: the largest per-vendor difference in 2026 is which request fields each model accepts. Current Claude models reject assistant-turn prefill (from Claude 4.6), non-default sampling parameters and manual thinking budgets (Sonnet 5 and later), and forced tool_choice (Sonnet 5.5). Gemini 4 and 3.6+ ignore sampling parameters with deprecation warnings. OpenAI reasoning models reject temperature and top_p unless reasoning effort is none. Reasoning depth is set by a different field on each API (effort, reasoning.effort, thinking_level). Code that moves between models, or between versions of one vendor’s models, needs these fields checked as well as the prompt text.

Cross-model portability: prompts can typically be moved between models with some adaptation. The structural conventions need adjustment; the underlying instructions usually transfer. Production deployments that need cross-model portability typically develop their own intermediate representation that gets transformed into model-specific prompts at deployment time.

Tool calling and structured outputs: each provider has its own tool calling and structured output mechanisms (Volume 3 covers tool calling specifically). The prompt design implications differ: when tool calling is the primary output mechanism, the prompt design focuses on tool selection rather than output structure; when structured outputs are used, the prompt design references the schema rather than describing the structure verbally.

Multi-vendor deployments: agents that use different models for different subtasks need different prompt conventions for each model. The pattern emerged through 2025—2026 as teams discovered that the right model for each subtask varies and the prompts need to vary accordingly. Production deployments typically have prompt libraries organized by model.

When to Use It

Production deployments using a specific foundation model where the model-specific conventions produce measurable performance improvements. Cross-model deployments where prompts need to be adapted for each model. Cases where prompt-engineering effort justifies investment in model-specific conventions vs. lowest-common-denominator approaches.

Alternatives --- lowest-common-denominator prompts that work acceptably across models for cases where portability matters more than per-model optimization. Vendor-agnostic prompt libraries that use neutral conventions and accept some per-model performance loss.

Sources

• platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

• developers.openai.com/api/docs/guides/prompt-engineering

• ai.google.dev/gemini-api/docs/prompting-strategies

• platform.claude.com/docs/en/models/sonnet-5-5/migration-guide

Source: Various practitioner reports through 2024—2026; Anthropic prompt generator in Workbench; OpenAI prompt enhancement features; research literature on automated prompt optimization

Intent

Use foundation models to generate, optimize, or refine prompts for other AI tasks, leveraging the model’s knowledge of effective prompt patterns to accelerate prompt development.

Motivating Problem

Prompt design is time-consuming. A new agent’s system prompt takes hours to days to develop well; refinement based on observed behavior takes more time. Meta-prompting aims to accelerate this work by having AI generate first-draft prompts, suggest improvements to existing prompts, or optimize prompts against evaluation criteria. The pattern is appealing because it scales prompt engineering effort; the limitation is that AI-generated prompts may not match what a thoughtful human author would produce.

How It Works

Prompt-from-description: the user describes what the agent should do in natural language; the model generates a system prompt that would implement that description. Anthropic’s prompt generator in Workbench implements this pattern; OpenAI has similar tools. The pattern produces reasonable first drafts that humans typically refine.

Prompt-from-examples: the user provides examples of desired input→output behavior; the model generates a prompt that would produce that behavior. The pattern works better than prompt-from-description for cases where the behavior is hard to describe but easy to demonstrate.

Prompt optimization against evals: given an existing prompt and an eval suite, the model proposes modifications and tests them against the evals. The optimization loop runs until improvements plateau. The pattern is more sophisticated than first-draft generation but requires significant infrastructure (eval suite, optimization loop, model calls for each variant).

Self-prompting: the model writes its own task-specific prompt at runtime based on the user’s description. The pattern lets the same agent handle varied tasks by generating appropriate prompts dynamically. The trade-off is increased latency (a model call to generate the prompt before the main task) and reduced reproducibility (the generated prompt may vary across runs).

Limitations of AI-generated prompts: the model’s knowledge of effective prompts comes from training; the model may not know what works best for the specific deployment context, the specific model the prompt will run on (Anthropic’s model generates prompts; whether those prompts run best on Anthropic’s model vs. others is unclear), or the specific edge cases the human author has encountered. Production deployments typically treat AI-generated prompts as drafts that human authors refine.

Automated optimization: DSPy optimizers (MIPROv2, and GEPA, a reflective prompt-evolution method published in July 2025 and shipped as dspy.GEPA) and research methods such as Promptbreeder search for better prompts against an eval metric. DSPy is a production library, not only research; adoption is still less consolidated than for the simpler meta-prompting patterns above.

When to Use It

First-draft prompt generation when starting a new agent; the AI-generated draft is a starting point rather than the final artifact. Prompt iteration where the human author wants suggestions for improvement. Cases where prompt design effort is the bottleneck and faster iteration matters more than peak optimization.

Alternatives --- human-authored prompts for cases where the prompt quality matters more than development speed. Prompt templates for cases where the pattern is well-known and parameterization captures the variation. Direct experimentation with prompt variants for cases where the team has the time and infrastructure to test systematically.

Sources

• claude.com/resources/articles/prompt-improver (Claude Console prompt improver)

• OpenAI prompt enhancement documentation

• dspy.ai/api/optimizers/GEPA/overview/ (DSPy GEPA optimizer); various research papers on automated prompt optimization

Appendix A --- Pattern Reference Table

Cross-reference of the patterns covered in this volume with what each solves, when to use each, and the section that covers it in detail.

Pattern	Solves	When to use	Section
System prompt design	Establishing role and behavior	Most production agents	Section A
Few-shot / N-shot	Demonstrating desired patterns	Tasks needing specific formats	Section B
Chain-of-thought	Step-by-step reasoning	Complex tasks on non-reasoning models	Section B
Reasoning effort control	Per-call quality vs. latency and cost	Every call to a reasoning model	Section B
Context selection	Choosing what model sees	Production agents with rich context	Section C
Context ordering	Position-aware placement	Long-context deployments	Section C
Context compression	Reducing to fit budget	When relevant content exceeds window	Section C
Server-side compaction	Long runs outgrowing the window	Long agent tasks and conversations	Section C
Structured output prompting	JSON/typed output guarantees	Downstream parsing requirements	Section D
Sampling parameters	Output randomness and diversity	Older and self-hosted models	Section D
Prompt registry / versioning	Operational lifecycle	Production deployments at scale	Section E
Prompt testing	Verification and regression detection	Frequent prompt changes	Section E
Model-specific conventions	Per-vendor optimization	Cross-model or vendor-optimized work	Section F
Meta-prompting	AI-generated prompts	Prompt development acceleration	Section G

Appendix B --- The Series

This catalog joined the fourteen prior volumes to form a fifteen-layer vocabulary for agentic AI (the series has since grown to nineteen volumes), with the explicit caveat that this volume is the weakest entry in the series.

• Volume 1 --- Patterns of AI Agent Workflows --- the timing of agent runs.

• Volume 2 --- The Claude Skills Catalog --- model instructions in packaged form.

• Volume 3 --- The AI Agent Tools Catalog --- the function-calling primitives.

• Volume 4 --- The AI Agent Events & Triggers Catalog --- the activation layer.

• Volume 5 --- The AI Agent Fabric Catalog --- the infrastructure substrate.

• Volume 6 --- The AI Agent Memory Catalog --- the state and context layer.

• Volume 7 --- The Human-in-the-Loop Catalog --- HITL engineering.

• Volume 8 --- The Evaluation & Guardrails Catalog --- LLM-internal safety.

• Volume 9 --- The Multi-Agent Coordination Catalog --- agent-to-agent communication.

• Volume 10 --- The Retrieval & Knowledge Engineering Catalog --- finding the right information.

• Volume 11 --- The AI Compliance & Regulatory Catalog --- compliance-facing governance.

• Volume 12 --- The AI Infrastructure Security Catalog --- security around the AI system.

• Volume 13 --- The Agent UX Patterns Catalog --- design discipline for agent interaction.

• Volume 14 --- The AI Agent Products Survey --- a snapshot, not structural vocabulary.

• Volume 15 --- The Prompting and Context Engineering Catalog (this volume) --- defensibly skip or fold.

The series now has a clear taxonomy. Volumes 1—10 are the engineering substrate --- patterns and mechanisms that compose into agentic AI systems. Volumes 11—13 are complementary disciplines that consume the engineering substrate --- compliance, security, design --- each with its own audience and artifacts. Volume 14 is a deliberate-snapshot product survey. Volume 15 (this volume) is the weakest entry: the content is largely covered elsewhere in the series; the residual is real but narrower than prior volumes’ scope. Treating this volume as optional, with the fold-into-existing-volumes alternative as a legitimate choice, is honest framing the reader should consider.

Appendix C --- The Case for Skipping This Volume

This appendix makes the case for treating this volume as optional. The case is honest because the content largely exists elsewhere in the series; if a reader finds the consolidated treatment less valuable than the distributed treatment in the prior volumes, skipping this volume is a legitimate choice.

The strongest fold-into-existing-volumes argument is that prompting and context engineering are integrated practices, not separable disciplines. Real production agents use system prompts (could go in Volume 2 Skills), tool definitions (Volume 3 Tools), persistent context (Volume 6 Memory), retrieved content (Volume 10 Retrieval), safety patterns (Volume 8 Evaluation & Guardrails), and multi-agent prompts (Volume 9 Multi-Agent) all together. The integration is the point; separating prompting into its own volume artificially isolates a discipline that’s tightly coupled with the rest of the agent’s design.

The argument against fold-and-skip: the residual this volume covers (the system-prompt design patterns, the few-shot and chain-of-thought variants, the context-window engineering at production scale, the prompt versioning and testing discipline, the model-specific conventions, the meta-prompting patterns) is coherent enough that distributing it across the prior volumes would lose the coherence. The reader looking up “chain-of-thought” doesn’t want to find it discussed only in passing in Volume 8 as a safety technique; the reader wanting context-engineering guidance doesn’t want to find it scattered across Volumes 6 and 10 with the prompt-design angle implicit. Consolidating provides a discoverable reference; distributing optimizes for integration but loses discoverability.

The reader’s choice. If the reader values discoverable reference for prompting patterns, read this volume. If the reader values integration with the broader engineering substrate, treat this volume as appendix material that the prior volumes would have covered comprehensively if they’d been written with prompting-discipline awareness. Either choice is honest; the series accommodates both.

Appendix D --- Discovery and Standards

Resources for tracking prompting discipline evolution:

• Anthropic prompt engineering guide (platform.claude.com/docs)

• OpenAI prompt engineering guide (developers.openai.com)

• Google Gemini prompting strategies (ai.google.dev)

• Claude cookbooks (github.com/anthropics/claude-cookbooks)

• OpenAI cookbook (github.com/openai/openai-cookbook)

• Practitioner writing: Eugene Yan (eugeneyan.com), Hamel Husain (hamel.dev), Simon Willison (simonwillison.net)

• Latent Space podcast and newsletter (latent.space)

• Academic conferences: NeurIPS, ICLR, ACL for prompt engineering research

• Prompt registries: LangSmith Prompt Hub, PromptLayer, vendor playgrounds (as both pattern reference and infrastructure)

• Eval tooling: Claude Console evaluation tool, OpenAI Datasets and graders, Promptfoo, Braintrust (as both validation infrastructure and pattern reference)

• Resources for tracking prompting discipline: the vendor guides, practitioner writing and cookbooks listed above, as a reading list for keeping current (platform.claude.com/docs, developers.openai.com, ai.google.dev)

Two practical recommendations. First, vendor documentation is the most reliable source for vendor-specific recommendations and updates as models evolve. Practitioner writing captures patterns not yet in vendor docs and provides commentary on what works in production. Academic literature provides the theoretical foundations and emerging techniques. The three categories complement each other. Second, the discipline accumulates faster through hands-on experimentation than through reading; this volume and the broader literature provide vocabulary and pattern recognition, but actual production prompts require iteration on the specific use case. Treat the reading as background; treat the experimentation as the main work.

Appendix E --- Omissions

This catalog covers 13 entries across 7 sections, a deliberately smaller count than prior volumes reflecting this volume’s narrower scope. The wider prompting and context engineering discipline includes content not covered here:

• Packaged agent instructions (Volume 2 Skills covers).

• Tool definitions and function calling schemas (Volume 3 Tools covers).

• Memory persistence patterns (Volume 6 Memory covers).

• RAG and retrieved context patterns (Volume 10 Retrieval & Knowledge Engineering covers).

• Safety prompt patterns and constitutional AI (Volume 8 Evaluation & Guardrails covers).

• Multi-agent prompting (Volume 9 Multi-Agent Coordination covers).

• HITL approval prompting (Volume 7 Human-in-the-Loop covers).

• Specific commercial prompt-optimization tools beyond brief mention. The category is small and changing; comprehensive coverage would age quickly.

• Detailed comparison of prompt registries and eval tools. Volume 14 (Products Survey) covers some of these at product level.

• Voice and multimodal prompting specifics. The patterns are emerging; the volume focuses on text where the discipline is more consolidated.

• Fine-tuning as alternative to prompt engineering. Fine-tuning is its own discipline; this volume covers what prompts do, not what fine-tuning does instead.

Appendix F --- A Note on Weaker Candidates

This volume is the first “weaker candidate” in the series --- the first volume I would defensibly skip or fold into other volumes, distinct from the four “Not gaps” volumes (11—14) that earned their place despite my initial framing. The honest framing matters because the catalog’s value proposition depends on the volumes being worth their place; including volumes that don’t earn their place dilutes the series’ overall value. Acknowledging this volume’s weakness lets the reader make an informed choice about whether to engage with it.

Why include a weaker candidate at all? Because the discipline has accumulated working knowledge that’s worth consolidating somewhere, and consolidating it in one place is more useful than scattering it across the volumes it would nominally fit. The trade-off is real: scattering preserves integration; consolidating preserves discoverability. The series chose consolidation; readers who prefer scattering can treat this volume as optional and rely on the prior volumes’ distributed coverage.

The pattern of including weaker candidates has limits. Future volumes would need to earn their place more clearly than this one does; the series can’t sustain unlimited expansion without diluting the value proposition. Adjacent areas where comparable treatment might be valuable --- cost engineering for AI systems, model lifecycle management, enterprise integration patterns --- each face the same question: does standalone treatment add enough value over distributed treatment to justify the additional volume? The answer should be skeptical; the bar for additional volumes should rise as the series grows. This volume’s honest framing acknowledges that this volume’s answer is “defensible but contested”; future volumes should answer more clearly.

Fifteen volumes at the time of writing (the series has since grown to nineteen). Patterns, Skills, Tools, Events, Fabric, Memory, Human-in-the-Loop, Evaluation & Guardrails, Multi-Agent Coordination, Retrieval & Knowledge Engineering, AI Compliance & Regulatory, AI Infrastructure Security, Agent UX Patterns, AI Agent Products Survey, and now Prompting and Context Engineering with explicit acknowledgment that it’s the weakest entry. The first ten are the engineering substrate. The next three are complementary disciplines. The fourteenth is a perishable products snapshot. The fifteenth is a defensible-but-weaker consolidation of distributed content. The series at fifteen volumes covers what an architect could want to know about agentic AI in mid-2026, with each volume’s standing in the series honestly framed. The proposition still holds: the structural vocabulary in Volumes 1—13 should outlast the products in Volume 14 and the consolidations in Volume 15.

--- End of The Prompting and Context Engineering Catalog v0.1 ---

— The Agentic AI Series —