Working with reasoning models in practice

0:00 Working with reasoning models

An analyst asks two models the same question: what happens to revenue and churn if we raise our middle pricing tier? The fast model writes a fluent answer with an arithmetic slip. The reasoning model gets the arithmetic right and separates assumptions more clearly, but takes longer. The best answer came from neither alone. In this lecture you will learn how to prompt reasoning models, how to set effort sensibly, how reasoning works with tools, how to verify outputs, how to show progress to users, and how to explain the trade-offs to stakeholders.

0:40 Prompting principles

Prompting reasoning models is mostly about clarity, not choreography. State the goal, constraints and definition of done clearly. Prefer high-level guidance, like consider edge cases and check each constraint, over rigid step-by-step scripts; provider guidance for recent models suggests their own reasoning often beats hand-written procedures. Provide all the information up front, because reasoning cannot recover facts that are not present, though it can fetch them with tools. Ask for a concise final answer in a defined format. And remove legacy instructions, like repeated double-check everything, then re-test.

1:18 A reasoning-friendly prompt

Here is a pattern from the lesson. A goal tag: recommend whether to raise the middle pricing tier by ten percent, for Thursday's leadership meeting. A context tag: the pricing tiers, last quarter's usage by customer and churn history, plus a churn tolerance of three percent per quarter. A constraints tag: do all arithmetic in the Python tool, do not estimate; separate facts from assumptions and label each assumption; and if the data cannot support a conclusion, say so. An output tag: a one-paragraph recommendation, a table of three scenarios, and the list of assumptions. Notice what is absent: no think step by step, no prescribed sequence.

2:05 Setting effort

Set effort with a simple routine. Build a small evaluation set of real tasks at varying difficulty. Run it at low, medium and high settings. Record accuracy, median latency, slowest latency and cost. Then choose the lowest setting that meets your accuracy bar for each task type. The usual result is a routing design: low effort or a fast model for easy, high-volume work, and higher effort for a small share of hard or high-stakes cases.

2:38 Reasoning with tools

Reasoning models are especially strong in agentic setups, deciding which tools to call and interpreting the results. Several current models can reason between tool calls, which is called interleaved thinking: look at a result, think, then choose the next call. Two practical implications. Pass the model's content blocks back unchanged in multi-turn tool use, because some providers require reasoning blocks to be returned exactly as received. And give tools clear, compact outputs, so the reasoning has something clean to work with. Permissions and approvals still belong in code.

3:16 Verify in proportion

Longer reasoning does not guarantee correctness, so keep verification proportional to stakes. Use code checks for constraints like schedules, totals and rules. Use tests for generated code. Require citations for factual claims. And keep human review for decisions with legal, financial or safety impact. Back to the analyst: the best practice was to ask the reasoning model to write the projection as a spreadsheet formula or a short Python script, run it on the actual data, and use the model's reasoning for the qualitative churn discussion, labelled as assumptions. The numbers come from executed code on real data.

3:59 Progress and monitoring

Long reasoning can look like a frozen screen. Depending on the provider, you can stream the final answer as soon as it starts, display reasoning summaries where the API provides them, or show your own progress indicators based on tool calls. Just never present raw or summarised reasoning as a guaranteed explanation of the decision. And monitor reasoning tokens in production. Unexpected spikes often point to ambiguous or contradictory instructions, which you can fix by clarifying the prompt rather than simply lowering effort.

4:35 Communicating trade-offs

Stakeholders often assume the thinking model is always better. Explain the trade-off in business terms: better accuracy on hard problems, higher cost and slower responses, and no guarantee of correctness. Show the evaluation table, accuracy, latency and cost per task, when proposing a model choice. As a starting point: real-time chat and simple questions suit a fast model or low effort; high-volume classification suits a fast model with escalation; complex analysis, planning and code suit reasoning at medium or high effort; and high-stakes decision support needs reasoning plus verification and human review. Then review monthly, because newer models often reach the same accuracy at lower effort.

5:21 Example 1: a three-day trip plan

A simple worked example. You ask a reasoning model: plan a three-day trip to Istanbul for two people, budget one thousand euros including flights from London, and my partner does not like early mornings. Version one of your prompt adds: first list the attractions, then sort by district, then calculate costs, then write the plan. The result is rigid and over the budget. Version two states only the goal, the constraints and the output: a day-by-day plan, a cost table that must stay under budget with assumptions labelled, and nothing before ten in the morning. The model plans its own route, fits the budget, and lists its price assumptions so you can check them. Goals and constraints beat choreography.

6:13 Example 2: supplier bid comparison (illustrative)

Now a business scenario, with illustrative numbers. A procurement analyst at a manufacturing company in Sialkot compares bids from six suppliers across price, delivery time, quality history and payment terms, about thirty bids a quarter. She uses a reasoning model with a prompt that states the goal, the weighting of each criterion, and a constraint: all scoring arithmetic must be done in the code tool. The model writes and runs the scoring code, then writes a recommendation that separates facts from assumptions, such as assuming last year's quality record predicts this year's. She reviews the code, checks two scores by hand, and presents the table plus the reasoning to the purchasing committee. Preparation time falls from about a day to about two hours per round, and the committee now sees exactly how scores were calculated. Illustrative figures.

7:13 Recap

To recap. Give reasoning models clear goals, constraints, complete information and an output contract, and remove legacy scripts. Choose effort by evaluation and route by difficulty. Use interleaved thinking with clean tools, return blocks unchanged, and keep approvals in code. Verify in proportion to stakes, with numbers from executed code. Try this now: pick one analytical task, run it with a fast model and a reasoning model, have both output their calculations as code, execute it, and compare correctness, time and cost. Next: extended and adaptive thinking controls across APIs.