Prompt Engineering Techniques: Few-Shot, Role, and Chain-of-Thought

Prompt engineering is the practice of deliberately crafting the input you give a large language model to get the output you want. A prompt is everything the model sees before it responds: your instruction, any background context, examples of good answers, and cues about format and tone. Because foundation models are general-purpose, the prompt is what turns broad capability into a specific, useful result — the same model behind a vague answer and a precise one; only the prompt changed.

Its significance comes from three properties. First, leverage: prompting is the fastest, cheapest way to improve gen AI output — no retraining, no infrastructure, no data pipeline; you simply ask better. It is the first technique to try before grounding or fine-tuning. Second, accessibility: prompting is plain language, so marketers, analysts, lawyers, and executives can all do it. The people who understand the business problem best can shape the AI's behavior directly. Third, compounding value: good prompts become reusable organizational assets — a well-crafted prompt for a weekly report or a customer reply template pays off every time it runs.

For a leader, the strategic point is that prompt quality often explains the gap between teams that get real value from gen AI and teams that dismiss it after poor first results. Before concluding that a model "can't do" something, the disciplined question is whether it was asked well.

An effective prompt gives the model four things: a clear instruction (what to do), relevant context (what it needs to know), the desired format (what the output should look like), and, where helpful, examples (what good looks like). Most weak outputs trace back to one of these being missing — the model was left to guess the audience, the length, the structure, or the purpose.

Compare two requests for the same task. Vague: Write about our new product. Engineered: Write a 100-word announcement of our new scheduling feature for existing customers. Friendly, plain language, no technical jargon. End with one sentence inviting them to try it from their dashboard. The second prompt specifies audience, length, tone, content boundaries, and a closing action — the model no longer has to guess any of them, so its output lands far closer to usable on the first attempt.

Prompting is also iterative. The first prompt is a draft: you review the output, notice what is off, and refine the instruction — tightening the format, adding a constraint, supplying an example. Sampling settings such as temperature and top-p, covered elsewhere in this domain, control how creative or predictable responses are, but the prompt itself remains the primary steering wheel. The techniques in the rest of this lesson are named, repeatable patterns for that steering.

These three techniques differ in one thing: how many worked examples ("shots") you include in the prompt. Zero-shot prompting gives the model an instruction with no examples at all — you rely entirely on its general training. It suits common, well-understood tasks: Summarize this meeting transcript in five bullet points. Foundation models handle familiar tasks like summarization, translation, and general questions well without any demonstration.

One-shot prompting includes a single example of the input and the desired output before the real request. It is the efficient middle ground when the task needs a specific format or style that is easier to show than describe: "Here is a customer review and the one-line summary we write for it. Now summarize this next review the same way." One good example communicates format, length, and tone in a way a paragraph of instructions often cannot.

Few-shot prompting includes several examples — typically two to five — so the model can infer the underlying pattern. It shines on tasks with nuance or consistency requirements: classifying support tickets into your specific categories, extracting fields from messy text, or matching a house style exactly. For example, showing three tickets each labeled Billing, Technical, or Account, then asking the model to label the next one, reliably teaches your category scheme without any model training. The practical rule: start zero-shot; add examples when the output misses your format or standard. Each example costs tokens, so use the fewest that achieve consistency.

Role prompting tells the model who to be before telling it what to do: You are an experienced financial analyst writing for a non-financial executive audience. Assigning a role steers vocabulary, depth, priorities, and tone all at once, because the model draws on the patterns associated with that persona in its training. It is one instruction that does the work of many.

The technique is valuable whenever the audience or perspective matters as much as the content. The same quarterly figures explained "as a financial analyst briefing the board" versus "as a teacher explaining to a new hire" produce genuinely different, appropriately pitched outputs. Role prompting also sets useful boundaries: a model told it is a customer-support specialist for your product line will stay closer to that scope than one given no identity at all.

In practice, role prompting is usually combined with other techniques rather than used alone — a role plus a clear instruction plus a few examples is a common and powerful pattern. It costs almost nothing (a sentence), so it is one of the highest-leverage habits to teach across an organization. Its limit is equally important to understand: a role changes how the model communicates, not what it factually knows. Telling a model it is a lawyer does not make its legal claims correct — accuracy problems are solved by grounding, not by persona.

Prompt chaining breaks a complex task into a sequence of smaller prompts, where the output of one step becomes the input to the next. Instead of asking a model to do everything at once — "read these ten customer interviews and produce a polished strategy recommendation" — you chain: first summarize each interview, then extract common themes from the summaries, then draft recommendations from the themes, then rewrite the draft for an executive audience.

Chaining works because each step is simple enough to do well, and because you can inspect and correct intermediate results before they feed the next stage. That checkpoint structure matters in business settings: a person or an automated check can verify the themes are right before recommendations get built on them, which is far safer than auditing one opaque end-to-end answer. Quality control moves from the end of the process into the middle of it.

Use prompt chaining when a task has natural stages, when a single prompt keeps producing shallow or muddled results, or when intermediate outputs are themselves useful. It is also the conceptual bridge to agent-based systems: workflows built on the Agent Platform are, at heart, orchestrated sequences of model steps with logic between them. A leader who understands chaining understands the basic architecture of most serious gen AI applications.

Chain-of-thought prompting asks the model to work through a problem step by step before giving its final answer, rather than jumping straight to a conclusion. The instruction can be as simple as adding Think through this step by step, then state your answer. to the prompt, or showing an example where the reasoning is written out before the conclusion.

It improves results because generating intermediate reasoning gives the model a structured path through multi-step problems — arithmetic and numerical word problems, logical deductions, policy decisions with several conditions, comparisons with trade-offs. Asked directly "which vendor proposal is cheaper over three years?", a model may leap to a plausible but wrong answer; asked to first lay out each proposal's yearly costs, sum them, and then compare, it is far more likely to get the answer right — and you can see exactly where any step went wrong.

That visible reasoning is the second business benefit: auditability. A recommendation that arrives with its logic exposed can be checked, challenged, and trusted in a way a bare conclusion cannot. Use chain-of-thought when the task involves multi-step reasoning or when stakeholders need to see the "why"; skip it for simple factual or creative tasks, where the extra reasoning adds tokens and latency without improving the outcome.

ReAct prompting — short for "reason and act" — has the model alternate between reasoning about a problem and taking actions to gather what it needs, such as searching for information or calling a tool, then folding the results back into its thinking. The loop looks like: thought ("I need the current list price to answer this"), action (look it up in the product catalog), observation (the retrieved price), then further thought, until the model reaches a final answer.

The difference from chain-of-thought is the actions. Chain-of-thought reasons only over what is already in the prompt and the model's trained knowledge; ReAct lets the model fetch what it is missing mid-task. That makes it the right pattern when answering requires live or external information — current data, a search, a calculation, a lookup in an enterprise system — rather than pure reasoning alone.

ReAct is the conceptual foundation of AI agents: systems that plan, use tools, observe results, and adjust until a goal is met. When you build an assistant on the Agent Platform that checks inventory, looks up an order, and then drafts a customer reply, you are operationalizing the ReAct pattern — grounding techniques like Google Search grounding or Agent Search often supply the "act" step's information. For the exam, keep the distinction crisp: multi-step thinking is chain-of-thought; thinking interleaved with information-gathering actions is ReAct.

The right technique depends on what is failing: format problems call for examples, perspective problems call for a role, complexity calls for chaining or chain-of-thought, and missing information calls for ReAct. The table summarizes each technique with a plain example.

These techniques stack. A production customer-service prompt might set a role, include few-shot examples of ideal replies, and run inside a chain — while the agent behind it uses ReAct to look up order details. Prompt engineering is not choosing one trick; it is combining the right ones for the task.