Use prompt engineering techniques

Study guide for Generative AI Leader, Unit 3 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Defining prompt engineering and describing its significance in interacting with large language models (LLMs). Identifying prompting techniques and use cases (e.g., zero-shot, one-shot, few-shot, role prompting, prompt chaining). Identifying advanced prompting techniques and when to use them (e.g., chain-of-thought prompting, ReAct prompting).

This hive's learning objectives for the topic:

1. Explain what prompt engineering is and why it matters when working with large language models.
2. Choose zero-shot, one-shot or few-shot prompting for a task.
3. Apply role prompting and prompt chaining to a business task.
4. Recognize when chain-of-thought or ReAct prompting fits a task.

Prompt engineering techniques

Write it, test it, refine it — the prompt is part of the system

What it is — a prompt's task, instructions, examples and context. How many examples — zero, one or a few. How to structure the work — a role for the model and a chain of smaller prompts. How to make it reason — chain-of-thought, and ReAct for agents that act.

This topic is about the cheapest lever a business has over a generative model: the words it sends. Google defines a prompt as a natural language request submitted to a language model to receive a response back, and it calls the iterative process of repeatedly updating prompts and assessing the model's responses prompt engineering. Google is honest that its Gemini models often perform well without prompt engineering on straightforward tasks — but for complex tasks, effective prompt engineering still plays an important role. The deck takes four steps. First, what prompt engineering is and why it matters with large language models. Second, how many examples to include: zero, one or a few. Third, two ways to structure the work: giving the model a role, and chaining several smaller prompts together. Fourth, the advanced techniques that make a model show or use its reasoning: chain-of-thought prompting, and the ReAct framework, short for reasoning and acting, that agents use when they take actions.

What prompt engineering is, and why it matters

A prompt is a test case for the model, not a one-off message

• A prompt is a natural language request to a language model
• It can carry questions, instructions, context and examples
• Prompt engineering: repeatedly updating prompts and assessing responses
• Simple tasks often need little; complex tasks still depend on it
• Define the objective and expected outcome, then test systematically

Worked example (synthetic). A bank's assistant answers balance questions well from a one-line prompt, but its dispute summaries ramble. Adding an output format and two examples, then re-testing against twenty past disputes, fixes it — that loop is the engineering.

Start with the definitions, because the exam tests the difference between a prompt and prompt engineering. A prompt, in Google's words, is a natural language request submitted to a language model to receive a response back, and it can contain questions, instructions, contextual information, few-shot examples and partial input for the model to complete. Prompt design is the process of creating prompts that elicit the desired response. Prompt engineering is the process around it: Google describes it as test-driven and iterative, and says that when creating prompts it is important to clearly define the objectives and expected outcomes for each prompt and systematically test them to identify areas of improvement. Why does it matter so much with large language models, or LLMs? Because, as Google explains, when given some text, language models predict what is likely to come next, like a sophisticated autocompletion tool — so what you put in shapes what comes out. Google's prompt engineering guide says it directly: the effectiveness of your prompt directly influences the quality and relevance of the output. Keep the scope honest too. Gemini models often perform well without prompt engineering on straightforward tasks; the payoff grows with the complexity of the task.

What goes into a prompt

Only the task is required; everything else is a lever

Worked example (synthetic). A product team's prompt is just a task: "Summarize this review." Adding a system instruction for tone, one example of a good summary and the review's star rating as context gives three levers it did not have.

Google breaks a prompt into components, and only one is required. The task is the text in the prompt that you want the model to provide a response for. System instructions are instructions passed to the model before any user input — the place to set behaviour that should hold across the conversation. Few-shot examples show the model what getting it right looks like. Contextual information is information the model uses or references when generating its response, such as a table of figures or a policy document. Google adds that two aspects of a prompt ultimately affect its effectiveness: content and structure — so it is not only what you include but how you order and label it. When a scenario says a model's answers are inconsistent, the fix usually lives in one of these optional rows, not in a different model.

The prompt engineering loop

Define the outcome, test against it, and change one thing at a time

Figure: A left-to-right flowchart. Define the objective and expected outcome, write or revise the prompt, test it on representative cases, and assess the responses. If the responses are not yet good enough, an arrow loops back to revising the prompt; if they meet the outcome, the prompt is used.

Worked example (synthetic). A team changes only the output-format instruction between two test runs, so it can tell that the format change, not luck, fixed the summaries.

Drawn as a loop, prompt engineering looks like any other test-driven process — which is exactly how Google describes it: a test-driven and iterative process that can enhance model performance. You begin by clearly defining the objective and the expected outcome. You write the prompt, test it, and assess the responses; if they fall short, you revise and test again. Google's definition of prompt engineering is this loop: the iterative process of repeatedly updating prompts and assessing the model's responses. Two habits make the loop work. Test on cases that look like real use, not on the one example that inspired the prompt. And change one thing at a time, so you know which change helped. Writing well structured prompts, Google says, can be an essential part of ensuring accurate, high-quality responses — but you only know a prompt is well structured after the loop has proved it.

Zero-shot, one-shot and few-shot prompting

Add examples when instructions alone cannot pin down the pattern

• Zero-shot: a direct instruction or question, no examples
• One- or few-shot: one or more input–output examples come first
• Examples regulate format, phrasing, scope and patterning
• Always pair examples with clear instructions
• Too many examples can make the model overfit to them

Worked example (synthetic). A retailer extracts product specifications as JSON. A zero-shot prompt works, but key names vary between products; two examples with fixed lowercase keys make every output match the warehouse system.

The second objective is choosing how many examples to include. Zero-shot prompting, in Google's words, involves providing the model with a direct instruction or question without any additional context or examples — summarizing an article or translating a paragraph are typical. One-shot and few-shot prompting provide the model with one or more examples of the desired input-output pairs before the actual prompt, which can help the model better understand the task and generate more accurate responses. Google's prompt documentation names the two ends plainly: prompts that contain examples are few-shot prompts, while prompts that provide no examples are zero-shot prompts. What do examples buy? The model identifies patterns from them and applies those patterns, so few-shot prompts are often used to regulate the output formatting, phrasing, scoping or general patterning of responses. Two cautions come with them. Always accompany examples with clear instructions — without them, models might pick up unintended patterns. And more is not always better: if you include too many examples, the model might start to overfit the response to them. Use specific and varied examples instead.

Choosing the number of shots

Start with none, and add examples to fix a pattern you can name

Worked example (synthetic). A help desk classifies tickets. Zero-shot labels drift between "billing" and "payments"; three varied examples with the exact label set make the labels consistent.

Read the table from the top and stop at the first row that solves the problem. Zero-shot prompting gives the model a direct instruction or question with no examples, and for clear tasks it is often enough. One example can show the shape of an answer; several specific and varied examples help the model narrow its focus when the format, phrasing or scope must be consistent — Google lists exactly those uses for few-shot prompts. The last row is the warning: if you include too many examples, the model might start to overfit the response to them. And whichever row you choose, examples travel with clear instructions, because without them the model may pick up unintended patterns from the examples.

Role prompting and prompt chaining

Give the model a role, and break big jobs into linked steps

• Persona: who or what the model is acting as
• System instructions can set a role for the entire request
• Chaining: one prompt's output becomes the next prompt's input
• Independent subtasks can run in parallel and be aggregated
• Smaller prompts improve controllability, debugging and accuracy

Worked example (synthetic). An insurer asks one prompt to read a claim, judge coverage and draft a letter, and errors cannot be traced. Split into three chained prompts, each step's output can be checked before the next runs.

The third objective covers two techniques that shape how work is given to the model. Role prompting assigns a persona — in Google's description, who or what the model is acting as, also called a role. The natural home for a role is the system instructions: Google recommends using system instructions to tell the model how you want it to behave and respond, lists defining a persona or role as a use, and notes that when a system instruction is set, it applies to the entire request. Prompt chaining answers a different problem: a task too big for one prompt. For complex tasks that require multiple instructions or steps, Google says you can improve the model's responses by breaking your prompts into subtasks, and smaller prompts can help you improve controllability, debugging and accuracy. When the steps are sequential, you chain them: the output of one prompt in the sequence becomes the input of the next, and the output of the last prompt is the final output. When the subtasks do not depend on each other, you can run parallel prompts and aggregate the responses instead.

A chain of three prompts

Each step does one job, and its output feeds the next

Figure: A left-to-right flowchart. Raw customer feedback goes into prompt 1, which extracts the issues. Its issue list feeds prompt 2, which classifies the issues. The categories feed prompt 3, which recommends actions, and that is the final output.

Worked example (synthetic). A telecom company's feedback chain: when recommendations look wrong, the team reads prompt 2's categories first and finds a misclassified issue — a check one giant prompt would never have exposed.

This chain follows the example in Google's documentation of a telecommunications business analysing customer feedback. One prompt would have to find the issues, sort them and suggest fixes all at once. Instead, each step becomes its own prompt: the first extracts the issues from the raw feedback, the second classifies them into categories, and the third generates recommendations for each category. Google's rule for a chain is the arrow on this slide — in a sequential chain of prompts, the output of one prompt becomes the input of the next — and the output of the last prompt is the final output. The business benefit is control. Because every intermediate output is visible, a wrong answer can be traced to the step that caused it, which is the controllability and debugging Google says smaller prompts give you.

A role in the system instructions

The role shapes every answer — but it is not a security control

Figure. Two cards and a warning band. The system-instructions card gives a house-written role: a benefits advisor who answers only handbook questions, in plain language, and says so when a question is outside the handbook. The user-prompt card shows a vacation question and notes the role applies to every turn. The band warns not to put secrets in system instructions because they don't fully prevent jailbreaks or leaks.

Worked example (synthetic). House-written instructions for an HR assistant. The persona, the scope limit, the tone and the out-of-scope fallback are four separate levers, and each can be tested on its own.

Here is a role written the way Google suggests — as system instructions, which the model processes before it processes prompts and which apply to the entire request. The left card sets four things: a persona, a scope, a tone and a fallback for questions outside the scope. Google's prompt components name these as persona, constraints and tone; constraints are restrictions on what the model must adhere to, including what it can and can't do. The right card is an ordinary user question, and the role shapes the answer without being repeated. The warning band matters for a leader making policy. Google says system instructions can help guide the model to follow instructions, but they don't fully prevent jailbreaks or leaks, and it recommends caution about putting any sensitive information in them. A role is a quality control for answers, not a security boundary.

Chain-of-thought and ReAct

Ask for the steps when reasoning matters; let agents reason and act

• Chain-of-thought: break reasoning into intermediate steps
• Zero-shot chain-of-thought: simply ask for the reasoning steps
• Asking a model to explain its reasoning can improve it
• ReAct: an agent's two key features, reasoning and acting
• Agents act through tools and observe results to decide next

Worked example (synthetic). A finance assistant must say whether a refund breaks policy. Asked to reason step by step, it states the rule, the amount and the comparison; as an agent it would also look the policy up with a tool before answering.

The fourth objective is the advanced techniques, and the question the exam asks is when to use them. Chain-of-thought prompting, in Google's words, encourages the model to break down complex reasoning into a series of intermediate steps, leading to a more comprehensive and well-structured final output. It does not need examples: zero-shot chain-of-thought simply asks the model to perform reasoning steps, which may often produce better output. Google's prompt components include the same idea as reasoning steps — tell the model to explain its reasoning, which can sometimes improve its reasoning capability. Use it for multi-step problems: calculations, policy checks, anything where a wrong intermediate step produces a confident wrong answer. ReAct, short for reasoning and acting, goes further and belongs to agents. Google's agents page names the key features of an AI agent as reasoning and acting, as described in the ReAct framework. Reasoning uses logic and available information to draw conclusions; acting takes action or performs tasks; and agents also observe — gathering information about the situation to make informed decisions. The actions usually go through tools, which Google defines as functions or external resources an agent uses to interact with its environment. So the choice is simple: chain-of-thought when the answer needs visible reasoning; ReAct when the answer also needs the model to do something, see the result, and decide what to do next.

Reason, act, observe — the ReAct loop

The agent decides, uses a tool, looks at the result, and decides again

Figure: A left-to-right flowchart. A user request goes to a Reason step that decides what to do next. If it needs data or an action, it goes to Act, which uses a tool, then to Observe, which reads the result, and back to Reason. When there is enough to answer, Reason leads to Answer.

Worked example (synthetic). A travel agent bot is asked for a hotel under a budget. It reasons that it needs prices, calls a booking tool, observes three options, reasons that one fits, and answers.

Drawn as a loop, ReAct — reasoning and acting — is easy to tell apart from plain chain-of-thought. Chain-of-thought reasons once, inside one response. A ReAct agent reasons, then acts, then observes, and repeats. Reasoning, in Google's description, uses logic and available information to draw conclusions and solve problems. Acting is the ability to take action or perform tasks based on decisions or external input, which is how an agent interacts with its environment. Observing is gathering information about the environment or situation so the agent can make informed decisions — here, reading what the tool returned. Tools are the functions or external resources the agent uses to act. The loop ends when the reasoning step has enough to answer. For a business leader the signal is the task: if answering requires looking something up or changing something in another system, and then deciding again based on what came back, it is a ReAct-style agent task, not a prompting trick.

What this topic actually tests

Four questions about any prompt

Is it tested? define the outcome and iterate. Does it need examples? zero-shot first; few-shot to fix a pattern. Is the job too big? a role sets behaviour; a chain splits the work. Does it need reasoning or action? chain-of-thought for steps; ReAct when an agent must act and observe.

Close with four questions you can ask of any prompt in a scenario. Is it tested? Prompt engineering is a test-driven, iterative process, so a prompt nobody has assessed against an expected outcome is not finished. Does it need examples? Start with a zero-shot instruction, and add a few specific, varied examples when the format, phrasing or scope must be consistent — with clear instructions alongside, and not so many that the model overfits. Is the job too big? Give the model a role through system instructions when behaviour must hold for the whole request, and break a complex task into a chain of smaller prompts when steps must be checked one by one. Does it need reasoning or action? Ask for chain-of-thought when the answer depends on intermediate steps; reach for ReAct, reasoning and acting, when an agent must take an action, observe the result and decide again. The next topic turns from what you say to the model to what you ground it in.

Official sources for this topic

• Introduction to prompting — Gemini Enterprise Agent Platform
• What are AI agents? — Google Cloud
• Overview of prompting strategies — Gemini Enterprise Agent Platform
• Prompt engineering: overview and guide — Google Cloud
• Include few-shot examples — Gemini Enterprise Agent Platform
• Use system instructions — Gemini Enterprise Agent Platform
• Break down complex tasks into simpler prompts — Gemini Enterprise Agent Platform