Same loop, different reasoning strategies. Each pattern below is a real, cited technique — and each buys reliability with tokens. Your job as a designer is matching the pattern to the task, not maxing out the thinking.
Decide the next step only after seeing the last result. Grounds reasoning in real observations — fewer hallucinations, natural error recovery. Cost: a model call per step; can wander.
Think once, up front; then run the steps. Cheaper, auditable before anything runs, parallelizable. Cost: brittle — if step 2's result surprises you, the plan is stale.
A second pass that critiques the first, with the critique stored and fed back (Reflexion: verbal self-feedback in episodic memory). Shines when the target is checkable — code, math. Each pass roughly doubles cost.
Generate several candidate thoughts, score them, expand the promising ones, backtrack from dead ends. Big gains on branching, search-heavy puzzles; very token-hungry.
| Chain-of-thought (W3) | Plan-then-execute | ReAct (interleaved) | Tree of Thoughts | |
|---|---|---|---|---|
| Predictability | High — one call | High — plan is visible up front | Medium — path emerges at runtime | Low — search branches |
| Cost | $ | $$ | $$–$$$ (a call per step) | $$$$ |
| Adapts mid-task | No | Poorly (needs replanning) | Yes — that's the point | Yes, via backtracking |
| Auditability | One blob of reasoning | Plan reviewable before execution | Full step-by-step trace | Full tree (large) |
| Best for | Single-shot reasoning, no tools | Stable, well-understood workflows | Volatile tasks where results steer next steps | Puzzles/search where partial states can be scored |
Click a strategy. Bars show illustrative multipliers vs a single call (real numbers depend on model, prompt size, and tools — measure your own).
Everything this week — ReAct, plans, reflection — and everything last week — prompts, context — lives to the left of the model: it changes what the model sees. (Week 2 flashback: prompt ⊂ context ⊂ harness — none touch the weights.) Fine-tuning is different in kind: it rewrites the numbers inside. Watch the difference below — the network's edges are its weights; thicker = stronger.
A toy 3–4–2 network. A real LLM has billions of these edges — that's all "parameters" means: the numbers on the arrows. Changed in this demo: 0 of 20.
Parameters (= weights): the numbers inside the model — the edges above, billions of them. They were learned in training, and fine-tuning updates exactly these. Prompting never does.
Hyperparameters: NOT inside the model. They're the dials you set on the training process itself — learning rate, number of epochs, batch size. You choose them; the model never “learns” them.
Analogy: parameters are the employee's skills after the course; hyperparameters are the course schedule. “Fine-tuning updates the parameters” = the training changed the skills. (Saying it “updates hyperparameters” is the common mix-up — the schedule doesn't change the employee.)
The demo hides the real bill: hundreds+ of curated examples, GPU time, and re-running your evals to make sure the new weights didn't break something else — every time the task changes. A prompt edit ships in minutes; new weights ship in weeks.
That's the Week 3 ladder: prompt → few-shot → context/RAG → fine-tune last (the decision table). Week 7 revisits the fork one more time: RAG vs fine-tuning for company knowledge — retrieval usually wins for facts, fine-tuning for style and format at massive scale.