Demos: what optimizers change

Every Predict has a demos list. Demos are labelled examples placed in the prompt before the real input, and most DSPy optimizers work by choosing them.

sort = dspy.Predict(Triage)
print(sort(ticket="Send my money back, the lamp was broken").category)

sort.demos = [dspy.Example(ticket="I want my money back for the broken lamp", category="billing")]
print(sort(ticket="Send my money back, the lamp was broken").category)

Same module, same ticket, one demo added, and the answer changed from account to billing.

demo = dspy.Example(ticket="I want my money back for the broken lamp", category="billing")
messages = dspy.ChatAdapter().format(Triage, demos=[demo], inputs={"ticket": "Send my money back, the lamp was broken"})
for message in messages[1:]:
    print(f"--- {message['role']}")
    print(message["content"])

The adapter writes each demo as an earlier turn: a user message with the demo's inputs and an assistant message with its labels, before the real ticket. A real model reads these as examples of the task. The stand-in does something much cruder, which you saw in sort_ticket: it copies the label of the demo sharing the most words with the ticket. Both answers changed because of the prompt, not the code.

Why optimizers choose demos

Which demos, and how many, matters. Wrong labels teach wrong answers, and each demo makes every call longer and more expensive. Choosing demos by hand is prompt engineering again; an optimizer chooses them against your metric. The next three lessons compare three ways to do that on the same 8 devset tickets, starting from 25.0.