TL;DR
The study tests whether an LLM can recompute the probabilities of hypotheses as new data comes in (Bayes' rule: "it was 30% → we saw a fact → now it's 55%"). The verdict: in normal mode, without "thinking," the model gets it wrong. Turn on reasoning mode and give it code execution, and it computes precisely, stays on track over 10+ steps and even approximates probabilities you couldn't compute by hand.
The pain point: the model produces plausible-looking numbers, but they don't match the correct update. Sometimes it "buries" a hypothesis too abruptly after a single fact, sometimes it ignores strong evidence. A separate trap: ask about related events in different chats and the estimates contradict each other (in more than half of cases in most scenarios). In a single conversation, the same estimates are almost always consistent. The reason is simple: the model has no "shared brain" across chats, while within a conversation it sees its own previous answers.
The practical method: keep all estimates in one conversation, turn on reasoning mode and ask it to compute with code, not "eyeball it." State the prior probabilities and the likelihood of the data under each hypothesis explicitly.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
RULE 1: all related estimates go in ONE conversation (not in new chats)
RULE 2: turn on reasoning mode (thinking / reasoning)
RULE 3: for the math — a code tool (Python), not "in your head"
Update loop (in one prompt or one fact per message):
STEP 1: List of hypotheses + prior probabilities (sum = 100%)
STEP 2: New fact → for each hypothesis: "how likely is it to see this fact if the hypothesis is true"
STEP 3: Code: multiply the prior by the likelihood → normalize to sum to 100%
STEP 4: Show a "before → after" table; the new estimate becomes the prior for the next fact
Example in Action
Task: An Amazon seller notices that sales of the "Travel Mug 16 oz" listing dropped 40% in two weeks. There are four hypotheses: the listing slipped in search rankings, a competitor is undercutting on price, the season ended, the reviews got worse. Data arrives one piece at a time: first the ranking export, then competitor prices, then the review trend. The goal is not to flail around, but to honestly recompute what's more likely.
Prompt (reasoning mode on, code allowed):
We're working in a single conversation. Keep all estimates consistent with the previous ones.
<Hypotheses>
H1: the listing dropped in Amazon search rankings
H2: a competitor is undercutting (price 15%+ lower)
H3: the season ended (demand for travel mugs falls after January)
H4: reviews got worse (rating below 4.6)
</Hypotheses>
<Prior>
H1: 30%, H2: 25%, H3: 30%, H4: 15%
</Prior>
<Evidence_1>
Ranking for the main keyword "travel mug": was #12, now #34.
</Evidence_1>
For each hypothesis, estimate the likelihood: how likely it is to see
this ranking drop if the hypothesis is true (a number from 0 to 1)
and briefly justify it. Then CALCULATE WITH CODE (Python): multiply the prior
probability by the likelihood, normalize so the sum is 100%.
Output a "before → after" table. These numbers become the priors
for the next fact. Don't round until you've finished the calculation.
Result: The model returns a likelihood table with a justification for each hypothesis, then runs the code and shows the recomputed probabilities (summing to exactly 100%). In your next message you feed in the second fact (competitor prices), and the model updates from the numbers it already has, not from the original priors. By the end of the chain you can see which hypothesis gained weight and after which fact.
Why It Works
The weakness. Without reasoning, the model "feels" its way to an answer. It doesn't multiply or normalize; it generates plausible numbers. So its update drifts from the mathematically correct one and the error compounds with each new fact. Across different chats it has no shared picture of the world and rates the same set of events differently.
The strength. The model is good at judging qualitative things: "how typical is this fact for this hypothesis." It can also write and run code, and reasoning mode lets it work through the calculation step by step. Within a single conversation it sees its previous answers and keeps them consistent.
How the method exploits this. It splits the work: the model supplies likelihood estimates (what it's good at), and code does the arithmetic (what it's unreliable at "in its head"). A single conversation provides shared memory.
Control knobs: - Reasoning mode → turn it off for simple questions to save money, but keep it on for updating probabilities. - Code instead of "in your head" → drop the code requirement for 2–3 hypotheses you can check by hand. Keep it for 6+ hypotheses or complex dependencies. - Number of hypotheses → in the study the working size was about 8. More than that, split them into groups. - One conversation → don't open a new chat for the next fact. If you have to, paste the previous table into it.
Prompt Template
The paper has no ready-made prompt. The template below follows the design of their experiment: the model receives hypotheses, priors and observations and outputs an updated distribution. The calculation is handed off to code.
We're working in a single conversation. All estimates must be consistent
with the previous ones. Use code (Python) for calculations; don't compute in your head.
<Task>{what we're figuring out}</Task>
<Hypotheses>
{H1: ...}
{H2: ...}
{H3: ...}
</Hypotheses>
<Prior>
{H1: X%, H2: Y%, H3: Z%} (sum 100%)
</Prior>
<Evidence_{number}>
{new fact or observation result}
</Evidence_{number}>
<ReasoningLogic>
1. For each hypothesis, estimate the likelihood: how likely it is
to see this fact if the hypothesis is true (0–1). Briefly justify it.
2. In code: new_estimate = prior × likelihood, then normalize to sum to 100%.
3. Check: sum = 100%, no estimate zeroed out without a strong reason.
4. Output a "before → after" table and one sentence: what moved the estimates.
5. New estimate = prior for the next fact.
</ReasoningLogic>
What to fill in: {what we're figuring out} — the question you're answering. {H1...} — mutually exclusive hypotheses, ideally with an "other" in case you missed something. {X%...} — your starting estimate from experience, or split evenly. {new fact} — one observation at a time.
🚀 Quick start — paste into a chat:
Here is a template for Bayesian updating of estimates. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what your hypotheses are, what your priors are and what facts you already have. It needs this so the calculation rests on your data, not on something the model made up. It will map the task onto the template fields itself.
Limitations
⚠️ "No reasoning" mode hurts: without reasoning mode, models don't make accurate updates in either of the two test environments. A quick "eyeballed" answer gives confident but wrong numbers.
⚠️ Separate chats break consistency: when you ask in different conversations, estimates of related events contradict each other in most scenarios. In a single conversation it's much better, but not perfect.
⚠️ The model still "estimates" the likelihoods: in the test worlds it was given exact probabilities. In real life you ask it to guess "how likely is this fact under this hypothesis," and that part stays subjective. Code guarantees the arithmetic, not the correctness of your starting assumptions.
⚠️ Tested on mid-size open models and one large model with code: the conclusions about code rest on an experiment with a single model (Gemini 2.5 Pro). It's reasonable to expect similar results for Claude and ChatGPT, but the paper didn't test that.
⚠️ Synthetic worlds and a game of 20 questions: the tests are artificial. Transfer to business tasks with noisy data isn't proven.
⚠️ The available excerpt of the paper cuts off midway through the results. The quantitative effect sizes come from the authors' abstract, without tables.
How They Tested It
The authors framed the question like this: everyone says LLMs can't honestly update probabilities, so "AI scientists" get rigid scaffolding and fine-tuning. But has anyone actually tested that premise? They tested it along three axes.
Consistency. They took forecasting questions from ForecastBench and built "Dutch books" (a set of bets guaranteed to lose if the estimates violate the axioms of probability). They tested 3 models and 3 types of violations with 10 scenarios each. Result: across separate chats, violations occurred in more than half of the 30 scenarios for almost every model-axiom pair. In a single conversation, violations drop to 10% for Gemini and to 1 scenario out of 30 for Gemma. The authors' conclusion: the problem isn't an inability to compute, it's that there's no shared "store" of beliefs across chats.
Update accuracy. Two environments. In the first, "20 questions" (40 animals, 20 turns each), the reference was the model's own estimates. In the second, ProteinWorld, the authors generated fictional protein "worlds" with made-up names so the model couldn't lean on prior knowledge. There were 5 worlds, 8 classes, 6 experiments, 40 runs in total; the reference was the exact calculation. They compared 5 models with and without reasoning. Without reasoning, all of them failed. With reasoning, the results were much better: the models compute the reference distribution precisely and don't drift from it over 10+ observations. In the "hard" version of the world, where an exact formula isn't available, Gemini 2.5 Pro with Python code approximates the answer well.
The cost of error. The authors compared how well the model ultimately identifies the hidden hypothesis when it makes decisions based on its own estimates, versus a reference Bayesian agent. This showed that inaccurate updates hurt outcomes, not just deviate from theory.
The surprise was that rigid scaffolding and fine-tuning aren't needed: reasoning mode and a code tool are enough. Practical insight: "thinking" and "code" aren't decoration; they're a prerequisite for handling probabilities correctly.
Adaptations and Extrapolations
🔧 Technique: add a consistency self-check → catch contradictions before decisions
The idea comes from the "Dutch book" method, but the prompt is mine. Before an important decision, ask for related probabilities in one conversation and check that they add up.
Estimate in a single answer:
A) the probability that we hit the Q3 sales target;
B) the probability that we DON'T hit it;
C) the probability that we reach at least 90% of the target;
D) the probability that we reach at least 100% of the target.
Check with code: A + B = 100%? C ≥ D? If not, fix the estimates and explain what you corrected.
The effect: complementary probabilities must sum to 100%, and "≥90% of target" can't be less likely than "≥100% of target." Violations of these rules are exactly what the paper treats as a sign of bad estimates.
Extrapolation: updating with a "red team"
This combination isn't from the paper; test it yourself.
After the "before → after" table, take on the role of a skeptic: find the fact that
could change the estimates the most, and say at what likelihood value
the leading hypothesis would lose first place. Recompute with code under that scenario.
Resources
- From Prompts to Posteriors: Can LLM Agents Perform Bayesian Inference in Context?
- Authors: Linus Filbry, Luckeciano C. Melo, Yarin Gal (OATML, University of Oxford)
- Key references: Choudhury et al. (2026) — the "20 questions" protocol; ForecastBench (Karger et al., 2025); ProteinWorld — the authors' own environment