Advanced prompting techniques

The video is in Italian; this page is the written version in English.

When a problem does not fall in one shot, you need patterns that make the model work in cycles: search, verify, reconsider. These are the techniques everything we now call an “agent” rests on.

ReAct: thinking and acting, alternated

The idea is to loop reasoning together with external tools. The model thinks, decides on an action, receives the result, and starts again with one more piece of information.

Thought:     I need how many Champions League titles each club has
Action:      search("Real Madrid Champions League total")
Observation: 15 titles, the last in 2024
Thought:     now the other club
Action:      search("AC Milan Champions League total")
Observation: 7 titles, the last in 2007
Thought:     15 minus 7 is 8
Answer:      Real Madrid has won 8 more

The value is that the model does not need to know: it needs to know how to obtain information and what to do with it. That is why agents hold up on recent or very specific facts.

Self-consistency: ask several times and vote

On a problem with a well-defined correct answer, you can run the same prompt several times at a mid-to-high temperature and keep the answer that appears most often.

Wrong reasoning tends to go wrong differently each time, while correct reasoning keeps converging on the same result. It costs as many runs as you make — five passes cost five times as much — so it is reserved for cases where accuracy is worth the price.

Getting it reviewed

A model is often better at criticising than at producing. Hence a two-step pattern: generate first, then in a separate call ask it to find the errors in the text just produced, then to fix them.

It works better when the review is specific: “check that every numerical claim is consistent with the data provided” beats “improve the text” by a wide margin. And it works better still when the reviewer does not know it is the author.

Decomposing instead of asking for everything

The most underrated technique is the simplest: split a big problem into small steps, each with its own call, feeding one output into the next. Every step is checkable, and when something goes wrong you know exactly where.

A task asking “analyse this contract and tell me the risks” becomes: extract the clauses, classify them, assess each one, summarise the severe ones. Four modest calls beat one encyclopaedic answer.

What it costs

Each of these techniques multiplies calls and therefore time and money. They are worth adopting when an error costs more than latency — analysis, decisions, automated pipelines — and worth skipping when you simply want a quick answer.

Between steps, check with code

The flaw shared by every multi-step technique is that the error in step N enters step N+1 as truth. None of these techniques, alone, notices.

The countermeasure is not a better prompt: it is a deterministic check between steps.

Step 1  extract the clauses from the contract
   ↓    check: valid JSON? list not empty?
Step 2  classify each clause
   ↓    check: is every category among the allowed ones?
Step 3  assess the risky ones
   ↓    check: does each assessment cite an existing clause?
Step 4  summarise

Each check is trivial — a few lines — and turns a silent failure into an explicit error you can handle: retry the step, ask for a correction, stop.

Two rules: constrain the format where you can, so the check is mechanical rather than interpretive; and fail early, because an error at step 1 discovered at step 4 has already burned three calls and produced a plausible but wrong answer.

That is the difference between a chain that works in a demo and one that holds in real use: it lies not in the prompting techniques but in the code holding them together.

Counting the calls

Each of these techniques multiplies requests, and therefore time and money. Worth keeping in mind before adopting them.

Technique	Calls
Direct answer	1
Decomposition into four steps	4
Five runs with a vote	5
Generate plus review	2-3
Tool-using agent	unpredictable, often 5-15

The question is not “does this technique improve the result” — almost always yes — but how much that improvement is worth here. On an analysis that will drive a decision, five calls are nothing. On a function called a thousand times a day, multiplying by five changes the economics of the system.

In short

Technique	What it is for
ReAct	Alternating reasoning and tools: the basis of agents
Self-consistency	Several runs, keep the most frequent answer
Self-review	Generate, then criticise, then fix: keep the critique specific
Decomposition	Small checkable steps instead of one huge request
Checks between steps	A few lines of code turn silent failures into errors
Cost	Every technique multiplies calls: judge whether the case deserves it