Prompt Chaining and Few-Shot Prompting: Patterns, Examples, and When to Use Each

Overview

A single-pass prompt asks an LLM to complete a task in one request. It is often the simplest starting point: provide the input, explain the desired output, and validate the result. For a narrow, well-defined task, this may be all you need.

Few-shot prompting adds a small set of input-and-output examples to demonstrate the expected behavior. The examples act as an in-context specification. They can show formatting, classification boundaries, tone, or how to handle ambiguous cases without requiring model fine-tuning.

Prompt chaining divides a larger task into multiple steps. Each step has a focused instruction and passes its result to the next step. A chain might extract facts first, classify them second, summarize them third, and check the final answer last. The workflow can run sequentially, conditionally, or in parallel when the steps are independent.

These approaches are not mutually exclusive. A chain can use few-shot examples in one or more of its prompts. A single-pass prompt can also be upgraded with examples before it is split into a chain. The practical choice depends on task complexity, error tolerance, latency, cost constraints, and how much control your application needs.

How to compare options

Start by describing the task as a measurable workflow rather than asking which prompting technique is generally best. Define the input, expected output, failure conditions, and the amount of human review available.

• Task complexity: A short transformation may suit one prompt, while a workflow involving extraction, reasoning, and formatting may benefit from separate stages.
• Consistency: If outputs must follow a stable schema or classification policy, examples and validation steps can make the behavior easier to control.
• Debuggability: A chain exposes intermediate results, making it easier to identify whether extraction, interpretation, or final writing caused an error.
• Latency and cost: Multiple model calls add operational overhead. Use a chain when the quality or observability benefit justifies the extra calls.
• Input variation: Few-shot examples are useful when the model needs to see how your team handles representative edge cases. They are less useful when examples are too narrow or contradictory.
• Maintenance: Every prompt, example, parser, and handoff becomes part of the workflow. A more elaborate design should earn its maintenance burden.

A practical evaluation method is to build a small test set containing normal inputs, incomplete inputs, ambiguous inputs, and adversarial or irrelevant content. Run the same cases through a single-pass version, a few-shot version, and a chained version. Compare not only final quality, but also schema validity, error recovery, review time, and the usefulness of intermediate outputs.

Feature-by-feature breakdown

Single-pass prompting

Use a single-pass prompt when the task has one clear objective and the model can produce the result without intermediate state. A basic template might look like this:

System: You are a careful data transformation assistant.

User:
Convert the text below into JSON with these fields:
- title: string
- priority: one of low, medium, high
- action_items: array of strings

Return valid JSON only. If a field is missing, use null or an empty array.

Text:
{{input_text}}

This pattern is easy to implement and monitor. Add explicit output rules, but do not add unnecessary instructions that compete with the main objective.

Few-shot prompting

Few-shot examples are most valuable when the desired behavior is difficult to explain in abstract language. For instance, examples can clarify how to label support requests:

Classify each message as billing, technical, account, or other.
Return JSON with the fields category and reason.

Example 1
Message: I was charged twice for the same invoice.
Output: {"category":"billing","reason":"The message reports a duplicate charge."}

Example 2
Message: The password reset email never arrives.
Output: {"category":"account","reason":"The user cannot complete account recovery."}

Message: {{input_message}}

Choose examples that represent different valid categories and boundary cases. Keep the output format consistent across examples. If examples disagree with the written instructions, the model may produce inconsistent results, so treat them as part of the prompt's specification and test them like code.

Prompt chaining

Chaining is useful when a large instruction is doing several jobs at once. Consider a document review workflow:

1. Extract: Identify names, dates, obligations, and unresolved questions.
2. Normalize: Convert dates and labels into a consistent schema.
3. Classify: Assign each item a type or priority using a focused policy.
4. Summarize: Write a concise overview using only the normalized items.
5. Check: Verify that required fields exist and that the summary is supported by the extracted data.

Each stage should have a narrow contract. Pass structured data between steps rather than a loosely formatted paragraph whenever possible. This makes parsing, logging, retries, and human review more reliable. A validation step can reject malformed output or route uncertain cases for review instead of silently continuing.

Combining the patterns

A strong workflow often combines both methods. For example, the classification step in a document chain can use few-shot examples, while the extraction step uses a schema and the final step uses a concise single-pass summarization prompt. This selective approach avoids turning every task into a long chain.

Best fit by scenario

If you are building an AI assistant backed by documents, keep retrieval separate from answer generation when possible. A retrieval stage can select relevant passages, a reasoning or extraction stage can organize them, and a final response stage can cite or present only the supported information. For broader architecture guidance, see this RAG tutorial for document question-answering. Also review the prompt injection prevention checklist when external text is passed into a chain.

When to revisit

Prompt workflows should be revisited when the input distribution, output schema, model behavior, or business rules change. New document types may expose extraction failures. A revised label policy may make old few-shot examples misleading. A model or API change may alter formatting reliability, latency, or how strongly examples influence results. These are maintenance triggers, not reasons to redesign a stable workflow automatically.

Keep a versioned prompt set and a compact regression suite. Include examples that previously failed, not only ideal inputs. When updating a chain, test each stage independently and then test the complete workflow. Track whether a change improves the final result without creating more parsing errors or unsupported claims.

For a practical maintenance routine:

1. Record the task contract, schema, and intended failure behavior.
2. Store prompts and few-shot examples with version identifiers.
3. Log intermediate outputs where privacy and security requirements allow.
4. Measure valid outputs, correction rate, review effort, and end-to-end latency.
5. Remove examples that no longer represent the real input distribution.
6. Re-test after model, policy, retrieval, or parser changes.

The best next step is usually small: implement the simplest single-pass prompt, add a few representative examples if classification or formatting remains inconsistent, and split the workflow only when a distinct stage needs its own instructions or validation. This progression keeps prompt engineering practical while leaving room for reliable AI workflow automation as the use case grows.