# The anatomy of a good prompt

**AI Engineering Visualised** · Prompting · Film, 1:12 · Updated 2026-09-11

A prompt is the text a model conditions on before it answers. A good one states the task, names the audience, supplies context, sets constraints, shows an example and fixes the output format.

> A prompt has six pieces: task, audience, context, constraints, an example and an output format. Watch one real request assembled plate by plate, with the model’s recorded reply to every version, and see which piece changes the answer most.

Watch the film: https://understandingdata.com/ai-engineering-visualised/anatomy-of-a-prompt/
Video file: https://assets.understandingdata.com/viz/anatomy-of-a-prompt/video/film.mp4?v=16fc227412

A model can only work with what the prompt gives it. Ask it to summarise this incident and nothing else, and the recorded reply is a polite request for the incident: there is nothing to summarise. That is the problem every prompt solves, and the six plates in the film are the six kinds of information a request can carry: the task, who it is for, the material to work from, the limits, an example of a good answer, and the exact shape the answer must take.

The film builds one real request, a summary of a checkout outage for the on-call channel, one plate at a time, and every card shows what the model actually replied. Nothing on the cards was written by hand: each version of the prompt was sent once to `google/gemini-3.8-flash` at temperature 0 on 11 September 2026, and the replies are shown verbatim, including their Markdown.

With the context plate the model writes 96 words of accurate bullet points, a report for nobody in particular. Naming the audience makes it longer, 101 words, and adds a recommendation about concurrent index creation that the incident log never mentions: told who is reading, it tried to be helpful beyond the evidence. The constraints plate, at most 60 words and only what the log shows, cuts the reply to 53 words and the guess goes away.

The surprise is the example. A single sample summary turned the reply from prose into JSON on its own, a bigger change than any other plate, because an example shows the model the pattern rather than describing it. But the reply arrived wrapped in a Markdown code fence and without a follow_up key, so a bot that runs JSON.parse on it fails. Only when the format plate names all six keys does the reply parse first time.

That is the failure mode worth remembering: a reply that looks right to a person and breaks the program that reads it. The explorer holds the removal experiments too. Without the example plate the reply still parsed, but the follow_up field held a fact from the log rather than an action. Without the format plate it parsed but had five keys. Without the constraints plate the speculative advice came back.

The honest caveat is that this is one request, one model and one recording per prompt, so the size of each effect is specific to this case: another model, another task or another run at a higher temperature will move differently. The shape of the lesson travels well, though. When a program consumes the reply, the example and the format are not optional, and a plate like the audience, which mattered a lot for a person reading, barely changed a reply whose shape was already pinned down.

## The maths

### What the bot checks

```latex
\text{usable} \;=\; \texttt{JSON.parse}(r) \text{ succeeds} \;\wedge\; \{\text{status, window, impact, cause, fix, follow\_up}\} \subseteq \text{keys}(r)
```

A program reading the reply needs both halves. The example plate alone produced JSON wrapped in a code fence, so the first half failed; the prompt without the format plate parsed but had no follow_up, so the second half failed. Only the full prompt passed both.

### How much a plate changes the reply

```latex
\text{overlap}(a, b) \;=\; \frac{|\,\text{words}(a) \cap \text{words}(b)\,|}{|\,\text{words}(a)\,|}
```

A rough measure of how different two replies are. Pulling the audience plate out of the full prompt kept 84% of the words; adding the example plate to the constrained prompt changed the reply from prose to JSON, a change no overlap figure captures.

### Temperature zero

```latex
T = 0 \;\Rightarrow\; \text{token} = \arg\max_i\, p_i
```

Every reply here was recorded once at temperature 0, so the differences between cards come from the prompt, not from sampling luck. At higher temperatures the same prompt can give a different reply each time, and the pieces that pin the shape (the example and the format) matter even more.

## Transcript

### 0:00 One request

Ask a model to summarise this incident and nothing else, and the recorded answer is a polite question back: a vague request gives it nothing to work with.

### 0:10 Context

Add the log as context and it writes 96 words of bullet points, accurate but written for nobody in particular, in a shape no program can read.

### 0:20 Audience

Name the audience, the on-call engineers, and it grows to 101 words and adds advice about concurrent indexes that the log never mentions.

### 0:29 Constraints

Then a constraint, at most 60 words and only what the log shows, cuts it to 53 words and the guess disappears.

### 0:38 Example

The surprise is the example: one sample summary turns the reply into JSON on its own, a bigger change than any other plate, but wrapped in a code fence and missing a key.

### 0:49 Format

That is the failure a bot hits, a reply that looks like JSON but will not parse, until the format plate names all six keys and it parses first time.

### 1:00 What to keep

So when a program reads the reply, always send the format and one example; pull the audience plate out here and the answer barely changes.

## Related terms

- [System prompt](https://understandingdata.com/ai-coding-dictionary/system-prompt/)
- [Context](https://understandingdata.com/ai-coding-dictionary/context/)
- [Spec](https://understandingdata.com/ai-coding-dictionary/spec/)
- [Output tokens](https://understandingdata.com/ai-coding-dictionary/output-tokens/)

## More visualisations

- [Token decoding](https://understandingdata.com/ai-engineering-visualised/token-decoding/)
- [What are tokens?](https://understandingdata.com/ai-engineering-visualised/what-are-tokens/)
- [Lost in the middle](https://understandingdata.com/ai-engineering-visualised/lost-in-the-middle/)

---

Source: https://understandingdata.com/ai-engineering-visualised/anatomy-of-a-prompt/
From AI Engineering Visualised by James Phoenix, Understanding Data. Published 2026-09-11.
