Anatomy of a Prompt

You give a model a request and get back something vague or badly formatted. A teammate asks for what looks like the same thing and gets exactly what they wanted. The model is identical. The difference is the prompt, and specifically whether it was built out of the right parts in the right places.

A prompt is not just "the question you type." It is a small structured document, and once you can see its parts, you can fix a weak answer by fixing the part that was missing. This lesson takes a prompt apart so the rest of the topic has something concrete to build on.

A prompt is made of parts

Start with a real one. Here is a prompt for a customer support tool that has to route incoming messages:

You are a support assistant for a bank.
Classify the message below as Billing, Technical, or Other.
Message: "My card was charged twice for one purchase."
Reply with only the category name.

That single block is doing four separate jobs, and each line maps to one of them:

• Context sets the scene: "You are a support assistant for a bank." It tells the model what world it is operating in and, here, what role to play.
• Instruction is the task: "Classify the message below as Billing, Technical, or Other." This is the one part a prompt can never drop.
• Input is the data the instruction acts on: the message "My card was charged twice for one purchase."
• Output indicator constrains the answer: "Reply with only the category name." Without it, the model might reply "This looks like a Billing issue because the customer mentions a duplicate charge," which is harder for your code to use.

AWS describes a prompt as a combination of these components: the instruction you want performed, the context of the task, demonstration examples, and the input text the model should use. You rarely need all of them at once. A prompt should combine the parts the task actually requires, and no more.

Instruction versus input: the distinction that matters most

The single most common source of confusion is treating the instruction and the input as one lump. They are different, and keeping them separate is what makes a prompt reusable.

Take the review text "The food was great but the service was slow." On its own it is just input. It becomes a task only when an instruction wraps it:

• "Summarize this review in one sentence" gives you a summary.
• "Classify the sentiment of this review as positive, negative, or neutral" gives you a label.
• "Translate this review into Spanish" gives you a translation.

Same input, three different instructions, three different jobs. This is why production prompts keep the instruction fixed and swap the input on every request. Your support tool never rewrites "Classify the message" per customer. It reuses that instruction and drops in a new message each time.

Context and output indicator: the two parts people forget

The instruction and input are obvious once named. The other two get skipped, and skipping them is where weak answers come from.

Context is background the model needs but that is not the input itself. "The following text is from a restaurant review" tells the model how to read what comes next. A role like "You are a senior tax accountant" shifts the vocabulary and caution level of the answer. Context does not ask for anything; it frames the ask.

Output indicator describes the shape of the answer. AWS shows this cleanly with summarization: "Summarize the above text" returns a paragraph nearly as long as the original, while "Summarize the above text in one phrase" returns a tight one-liner. If your downstream code expects a single word, a JSON object, or three bullet points, the output indicator is where you say so. When the model returns the wrong format, this is almost always the missing part.

Zero-shot and few-shot: teaching by example inside the prompt

Sometimes an instruction alone is not enough to pin down what you want, especially the exact format or edge-case handling. You can show the model instead of only telling it, by including worked examples in the prompt.

An example pair, one input plus its correct output, is called a shot. A prompt with no examples is zero-shot: you rely on what the model already learned during training. A prompt that includes one or more examples is few-shot (or one-shot for exactly one), also called in-context learning, because the model picks up the pattern from the prompt itself.

Here is a zero-shot sentiment prompt:

Tell me the sentiment of this headline as positive, negative, or neutral:
New airline route offers a great opportunity for passengers and investors.

And the few-shot version, which shows the model the exact answer format first:

Tell me the sentiment of each headline as positive, negative, or neutral.

Research firm fends off allegations of impropriety over new technology.
Answer: Negative

Offshore wind farms thrive as opposition dwindles.
Answer: Positive

Manufacturing plant is the latest target in a state investigation.
Answer:

The examples do two things: they lock the output to one word, and they show how to handle tricky phrasings. The key point for later lessons is that few-shot learning happens entirely inside the prompt. It does not change the model. Close the session and the model remembers none of it, which is exactly what separates prompting from fine-tuning.

Prompt templates: the reusable recipe

Once a prompt works, you do not want to retype it and risk breaking the wording. A prompt template freezes the structure and marks the parts that change. AWS writes the changing slots with double braces:

Tell me the sentiment of the following {{text type}} as {{label A}} or {{label B}}.

Text: {{example input 1}}
Answer: {{label A}}

Text: {{input}}
Answer:

The braces are a signal to whoever fills the template, not text the model sees. Before sending, you replace {{input}} with the real customer message and strip the braces. This matters because the last lesson in this topic, prompt management, is built entirely on templates with named variables, and prompt attacks in a later lesson exploit exactly the seam where your fixed instruction meets the untrusted {{input}}.

Exam tips

• If a question hands you a prompt and asks you to name its parts, map each line: what to do (instruction), what to do it on (input), the framing (context), the required format (output indicator).
• "Instruction" and "input" are the classic trap pairing. The instruction is the verb, the input is the noun it acts on. A question that swaps them is testing this exact confusion.
• A shot is an example pair inside the prompt. Zero examples means zero-shot; one or more means few-shot. If an answer choice says few-shot changes the model or its weights, it is wrong. In-context learning lives only in the prompt.
• An output indicator controls format and length. When a scenario complains that answers are too long or the wrong shape, the fix is an output indicator, not a new model.

The one thing to carry forward: a prompt is a structure, not a sentence. When an answer disappoints, ask which part was missing rather than rewriting the whole thing from scratch. Next you will see the named techniques, from zero-shot up to chain-of-thought, that decide how much of that structure a given task actually needs.