From State to Foresight: Adding a Predictive World Model to an LLM Assistant — Without the Hallucinations
Our assistant already knows where each project stands. The next step is knowing what happens next: given the current state and a candidate action, predict the likely outcome — so the product can rank what's actually worth doing. The catch: ask an LLM to imagine the future and it fabricates one. Here's how we built a one-step predictive world model that's forced to cite real evidence or stay silent, earns its confidence from consensus rather than self-report, and runs in observe-only mode until backtests prove it's calibrated.

Alexandre Gonzales — CEO & Founder, Zenfox · June 2026 Part of our ongoing work on world models at Zenfox.ai
TL;DR
Our assistant already maintains a descriptive world model of each project — a compact, LLM-distilled representation of "what this project is and where it stands." It's great for grounding, but it only describes the present. The natural next step is foresight: given the current state and a candidate action, predict the likely next state, so the product can prioritize what's actually worth doing.
The obvious way to do this — "ask the model to imagine the future" — hallucinates badly. This article describes the design we use to get useful one-step prediction out of a general-purpose LLM while keeping fabrication under control. The short version: make grounding mandatory, constrain the output space, keep the horizon tiny, derive confidence from agreement instead of trusting the model's self-reported certainty, and ship the layer in observe-only mode until it's calibrated.
1. The gap: a model that describes but doesn't anticipate
Most "AI assistant context" today is descriptive. You ingest a user's signals — email, calendar, notes, meetings — and distill them into summaries the LLM can read. We do this per project: each project carries a rolling summary, a set of salient entities, and a feed of insights. This is a state representation. It answers "where are things right now?"
What it doesn't answer is the question a good chief-of-staff answers implicitly all day: "if I do X, what probably happens next?" A descriptive model can tell you three restaurant reservations are unconfirmed. It can't tell you which of your five possible next actions most moves the project forward. That ranking requires a transition function: a way to estimate the next state conditioned on an action.
In reinforcement-learning terms, that transition function is exactly what the literature calls a world model. The classic version (Ha & Schmidhuber, 2018) learns environment dynamics so an agent can "imagine" rollouts and plan. The recent twist is that you don't need a bespoke neural simulator — a sufficiently capable LLM already encodes transition regularities, and you can prompt it, in natural language, to predict the next state given the current state and an action. WebDreamer (Gu et al., 2024) does this for web agents: before clicking, simulate the outcome of each candidate action, score it, then commit. RAP (Hao et al., 2023) frames reasoning itself as planning against an LLM world model. More recent work pushes toward training the simulator explicitly with next-state-prediction objectives (Reinforcement World Model Learning, 2026; Imagine-then-Plan, 2026) and toward measuring how good LLMs really are as implicit text-based world models (From Word to World, 2025).
So the building block exists. The hard part is that, used naively, it lies.
2. Why the naive version hallucinates
If you hand an LLM the project state and say "what happens if the user sends this follow-up?", it will happily produce a vivid, plausible, fabricated future: a reply that never arrives, a date nobody set, a stakeholder who doesn't exist. Three failure modes drive this:
- Ungrounded generation. With no obligation to point at real evidence, the model fills gaps with priors. Fluency reads as confidence.
- Open-ended output. Asked for a free-form narrative of the future, the model invents specifics (names, dates, quotes) because prose wants specifics.
- Horizon drift. Each simulated step compounds error. Two or three steps out, the imagined state has quietly decoupled from reality.
And the model's own stated confidence doesn't save you — calibration of self-reported certainty is notoriously poor. A prediction can be wrong and sound sure.
The design below is essentially a list of countermeasures, one per failure mode.
3. The design
We don't build a deep planner. We build the smallest thing that adds value: a one-step outcome predictor that ranks actions we were already going to suggest. It never invents new actions, and it never rewrites the descriptive state. It's a lens, not a replacement.
3.1 Grounding is mandatory — predict-with-citations or abstain
The single most important rule: every prediction must cite the real evidence it relied on. Concretely, the predictor receives a slice of the project's actual, already-distilled item facts (the neutral, third-person fact summaries our ingest produces once per item — see §4) and must reference specific items by ID in its output. If it can't cite anything relevant, it isn't allowed to guess — it must return an explicit abstain with an unknown outcome.
This flips the default. Instead of "produce a future," the task becomes "given this evidence, what does it imply — and if it implies nothing, say so." A prediction grounded in nothing is treated as a bug, not a soft signal. In practice, forcing citations is the biggest single reduction in fabrication we saw: the model can't invent a reply from a contact when the only admissible support is the real inbox slice in front of it.
3.2 Constrain the output space — closed labels, not open prose
The predictor doesn't write a story about the future. It emits a small structured object with a closed-vocabulary outcome label (think: advances / stalls / needs input / no effect / unknown), a one-line predicted next state, a probability, the evidence references, and a confidence band. Closing the label set removes the surface where invented specifics live. The model is choosing among bounded outcomes, not authoring details.
3.3 Keep the horizon tiny
We predict one step (occasionally two). Horizon drift is a function of depth, so we cut depth to the bone. We are explicitly not doing tree search over deep rollouts; the marginal planning value of depth, for our use case, isn't worth the fidelity it costs. Short, grounded, frequent predictions beat long, speculative ones.
3.4 Derive confidence from agreement, not self-report
Rather than trusting a confidence number the model invents, we sample the prediction a few times and look at consensus. If the independent samples agree on the outcome label, confidence is high and the probability reflects the agreement rate. If they scatter, confidence is low — and low confidence routes to abstain. This turns calibration into something we measure (cross-sample agreement) instead of something we hope the model reports honestly. Sampling is kept low-variance so the signal is about genuine ambiguity, not temperature noise.
3.5 Tell the model, explicitly, not to invent
These predictors run as focused, single-purpose calls rather than inside a chatty assistant persona, so they need their discipline spelled out. The instruction is blunt: do not invent any event, date, person, or reply that isn't in the provided evidence; if the evidence is insufficient, abstain. Capable models follow clear, explicit constraints well — but you have to state them; they won't infer the secrecy of the contract on their own.
4. Reusing "understand once" — the predictor is cheap because the state already exists
A design point worth calling out: the predictor doesn't re-read raw emails. Our ingest interprets each item exactly once and emits a neutral, durable fact representation plus a canonical entity list, which everything downstream reuses. The predictive layer consumes that same representation as its evidence slice. There's no second summarization pass, no re-interpretation of raw content, and the predictor inherits whatever fidelity the one-time interpretation already established. The transition function is a thin addition on top of a state representation we were maintaining anyway.
This is also why grounding is enforceable: the evidence the predictor cites is the same curated, ID-addressable record the rest of the system trusts — not free-floating text.
5. Productizing it safely — additive, reversible, observe-first
Three rules keep this from ever degrading the product:
It's purely additive. The predictive layer only re-orders actions the system already surfaces (and optionally which insights rise first). It never overwrites the descriptive state, the insights themselves, or any of the underlying data the user sees. Remove the layer and you're back to today's behavior exactly.
It degrades gracefully. Re-ranking only kicks in above a confidence band. On abstain or low confidence — which is the correct output for a project with no relevant signal — the existing heuristic order is preserved untouched. The worst case is "no change," never "confidently wrong reorder."
It ships observe-first. Before the layer is allowed to influence anything, it runs in log-only mode: it makes predictions, we record them, and we wait to see what actually happened. Influence over ranking is unlocked only after the predictions prove themselves (next section). The whole thing sits behind a flag.
6. Knowing whether it actually works
A predictor you can't evaluate is just a vibe. We treat calibration as a first-class deliverable, not an afterthought.
The core method is backtesting against history: take a project as it stood at some past point, predict the outcome of an action that actually happened afterward, then compare the prediction to the recorded reality in the item stream. Because every action and outcome is already logged, ground truth is free.
We track three things:
- Calibration (a Brier-style score): when the predictor says 70%, does it happen ~70% of the time? Calibration matters more than raw accuracy here, because we threshold on confidence.
- Abstention rate: how often does it correctly decline? A healthy predictor abstains a lot — silence on thin evidence is a feature.
- False-confidents: high-confidence predictions that were wrong. This is the number that can actually hurt users, so it's the one we gate on.
Only once these look good does the layer earn the right to re-rank. And the same logs — prediction versus eventual reality — are exactly the dataset you'd need later if you wanted to train the predictor with an explicit next-state objective rather than relying on a general model zero-shot. We're not there yet, and deliberately so: you earn the fine-tune with the calibration data, not before.
7. Limitations and open questions
- Single-step myopia is a real ceiling. Some genuinely useful planning needs to look two or three moves ahead. We've traded that away for fidelity on purpose, but it's a known limit, not a solved problem.
- Forced citation reduces fabrication; it doesn't eliminate it. The model can still misread real evidence. Grounding constrains where it can be wrong, not whether.
- Cross-sample agreement can be confidently homogeneous. If a prior is strong, all samples can agree on the same wrong answer. Backtest false-confident rates are the safeguard, but the failure mode exists.
- Calibration is per-distribution. A predictor calibrated on travel-planning projects may be miscalibrated on sales pipelines. Whether confidence cutoffs should be learned per project type — possibly from the user's own thumbs-up/down feedback — is open.
8. Takeaways
If you already maintain an LLM-distilled state representation, you're one careful step away from foresight — but the step is mostly discipline, not modeling horsepower:
- Make grounding mandatory. Cite real evidence or abstain. This is the load-bearing wall.
- Close the output space. Labels, not narratives.
- Keep the horizon at one step. Depth is where drift lives.
- Earn confidence from agreement, not from the model's self-report.
- Ship observe-first and additive. Log, backtest, calibrate, then let it influence anything — and never let it overwrite what already works.
A predictive world model doesn't have to be a giant simulator. For an information assistant, it can be a thin, well-fenced transition function over a state you already have — and the engineering that makes it trustworthy is almost entirely about what you forbid the model from doing.
References
- Ha & Schmidhuber, World Models, 2018 — https://arxiv.org/abs/1803.10122
- Hao et al., Reasoning with Language Model is Planning with World Model (RAP), 2023 — https://arxiv.org/abs/2305.14992
- Gu et al., Is Your LLM Secretly a World Model of the Internet? Model-Based Planning for Web Agents (WebDreamer), 2024 — https://arxiv.org/abs/2411.06559
- From Word to World: Can Large Language Models be Implicit Text-based World Models?, 2025 — https://arxiv.org/pdf/2512.18832
- Reinforcement World Model Learning for LLM-based Agents, 2026 — https://arxiv.org/abs/2602.05842
- Imagine-then-Plan: Agent Learning from Adaptive Lookahead with World Models, 2026 — https://arxiv.org/html/2601.08955v2