TL;DR
Model-First Reasoning (MFR) is a technique where the LLM first builds an explicit model of the problem (entities, state variables, actions, constraints) and only then solves it based on that model. It works through an ordinary two-stage prompt: phase 1 builds the structure, phase 2 reasons strictly within that structure.
CoT and ReAct keep state implicitly, in the model's "head", spread across the text. The longer the reasoning chain, the more it drifts: the model forgets constraints, invents nonexistent actions, and breaks dependencies between steps. In a medication schedule it might prescribe two incompatible drugs at the same time. In project planning it might start a task before its prerequisites are done. The problem isn't the inference logic, it's that there's no explicit anchor: the structure of the problem is fuzzy.
MFR separates representation from reasoning. First the model writes everything out explicitly: what objects exist, what can change, which actions are allowed, which rules can't be broken. Then it solves the problem, constantly checking against that model. The result: fewer constraint violations, fewer hidden assumptions, greater structural clarity. It's especially effective on tasks with many dependencies and long chains of steps.
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
PHASE 1: Build the model
└─ Explicitly define:
• Entities (objects, agents)
• State variables (what can change)
• Actions (with preconditions and effects)
• Constraints (invariants, rules)
└─ Do NOT propose a solution
PHASE 2: Reason within the model
└─ Generate the plan step by step
└─ Every action must:
• Satisfy its preconditions
• Follow the defined effects
• Not violate any constraints
Both phases run in a single prompt or in two consecutive requests.
Example in Practice
⚠️ When the method fits: It works best for complex, multi-step tasks with explicit constraints. For simple questions ("Who founded Google?") it's overkill.
Task: You're launching an online design course. You have a team of three: a marketer (available Tuesdays and Thursdays), a designer (busy until May 15), and a tech specialist (can only start once the materials are ready). You need to build a landing page, record a promo video, set up an email sequence, and launch ads. Launch date is June 1. The landing page can't go live without the promo video. Ads can't launch without the email sequence.
Prompt:
Task: [description of the course launch above]
Phase 1: Build an explicit model of this task:
1. Entities (people, resources, artifacts)
2. State variables (statuses, readiness, availability)
3. Actions (what can be done, with which preconditions and effects)
4. Constraints (timing, dependencies, rules)
Do NOT propose a solution plan at this stage.
Phase 2: Using only the model above, create a step-by-step launch plan.
Make sure every action satisfies its preconditions and doesn't violate any constraints.
Result:
The model will output a structured description: who's involved, what can change (task statuses, people's availability), which actions are possible (for example, "Record video: precondition — designer is free; effect — promo video is ready"), and which rules can't be broken (video before landing page, emails before ads). Then comes a plan with specific dates and an order of steps, where each step explicitly references the model. You'll see whether every dependency and timing constraint is respected.
Why It Works
The LLM weakness: The model holds the task's state implicitly, in latent representations and scattered text. The longer the reasoning, the stronger the "drift": the model forgets early constraints, introduces nonexistent assumptions, and breaks logical coherence. This isn't an inference problem (the model can reason), it's a representation problem: there's no stable anchor.
The LLM strength: The model is great at generating structured descriptions and following explicit instructions. Give it a clear scheme ("here are the variables, here are the rules, here's what you can do") and it can stay consistent much longer.
How the method leverages that strength: MFR externalizes the internal representation. Instead of relying on the model's hidden state, we make it write the structure out explicitly and then reason strictly within those bounds. It's soft symbolic grounding: not a rigid formal language (like PDDL in classical AI planning), but enough structure to narrow the solution space and prevent hallucinations.
Prompt control levers:
Model detail → You can ask for more or less detail in phase 1. For simple tasks, simplify the model (fewer tokens). For critical ones, go for maximum detail.
Model output format → You can set the structure: a table, a list, pseudocode, natural language. A table is easier to check.
Explicit checking → Add to phase 2: "After each step, explicitly check whether all constraints from the model are satisfied." This boosts reliability, but also token count.
Iterative correction → Once you have the plan, you can ask: "Check the plan for violations of the model. If you find any, fix them." That's an extra verification pass.
Prompt Template
Task: {describe the task with its constraints and dependencies}
Phase 1: Build an explicit model of this task. Define:
1. Entities — which objects, people, resources are involved
2. State variables — what can change (statuses, location, availability)
3. Actions — what can be done, which preconditions are required, which effects result
4. Constraints — which rules and invariants must always hold
Do NOT propose a solution at this stage. Only the model.
Phase 2: Using only the model created above, generate a step-by-step plan to solve the task.
Make sure that:
• Every action satisfies its preconditions
• All state transitions are consistent with the defined effects
• No constraint is violated at any step
What to fill in:
- {describe the task} — a specific problem: planning, resource allocation, routing, scheduling. Be sure to state the constraints (timing, dependencies, rules) and the dependencies between steps; otherwise an explicit model won't give you an edge.
Limitations
⚠️ Overhead for simple tasks: If the task takes 2-3 steps with no constraints, building a model is wasted effort. MFR pays off on complex, multi-step tasks with many dependencies.
⚠️ More tokens: An explicit model makes both the prompt and the answer longer. If the context limit is tight, this can become a problem.
⚠️ Depends on model quality: If the LLM builds an incomplete or wrong model in phase 1, the errors carry over into phase 2. The model doesn't guarantee correctness; it only lowers the risk through explicit structure.
⚠️ Not a formal verifier: MFR makes errors visible but doesn't eliminate them entirely. Critical systems (medicine, safety) need additional checks.
How They Studied It
The researchers took three reasoning strategies, Chain-of-Thought (CoT), ReAct, and Model-First Reasoning, and ran them through a set of planning tasks: multi-step medication scheduling, routing with time dependencies, resource allocation, and logic puzzles. The focus was on qualitative assessment: constraint compliance, hidden assumptions, structural clarity.
CoT often produced smooth text but skipped critical steps or introduced nonexistent assumptions. ReAct improved local coherence by alternating thought and action, but global constraints were still violated: observations were sometimes "made up" rather than derived from the state. MFR showed noticeably fewer violations and rare hidden assumptions, because the explicit model acted as an anchor.
Why? The authors concluded that most LLM errors are representational, not logical. The model can draw inferences, but without explicit structure it "loses the thread": the state drifts and constraints get forgotten. MFR externalizes the structure, turning a hidden representation into something visible and checkable. It's a soft form of symbolic grounding: not rigid formalism (like PDDL), but enough structure for stability.
Remarkably, a simple split into two phases had this much effect. The authors stress that it's not a new architecture or fine-tuning, just prompt engineering. But it changes the approach: first "what exists", then "what to do". This echoes classical AI planning (where the model is specified by hand before solving) and cognitive science (where thinking errors often come from incomplete mental models rather than logic failures).
The practical insight: if your task is complex and constrained, don't start solving right away; ask the model to write out the structure first. That's not overhead, it's the foundation of reliability.
The Original from the Study
Context: The authors propose a two-stage prompt where phase 1 builds the model and phase 2 uses it for reasoning.
Phase 1 Prompt (Model Construction):
Analyze the following problem. First, explicitly define the problem model
by listing: (1) relevant entities, (2) state variables, (3) possible actions
with preconditions and effects, and (4) constraints. Do not propose a solution yet.
Phase 2 Prompt (Reasoning):
Using only the model defined above, generate a step-by-step solution plan.
Ensure that all actions respect the defined constraints and state transitions.
Adaptations and Extrapolations
💡 Adaptation: Combine with Chain-of-Thought in phase 2
MFR and CoT aren't rivals. Use the explicit model as the foundation and CoT as the reasoning style inside phase 2. You get both structure and transparent steps.
Phase 2: Using only the model created above, generate a step-by-step solution plan.
At each step, reason out loud (Chain-of-Thought):
• Which action you're choosing and why
• Which preconditions have been checked
• What effect is expected
• How this affects the state and the constraints
💡 Adaptation: MFR for analyzing texts and arguments
The method works not only for planning but also for structural analysis. Instead of "actions", use "claims"; instead of "constraints", use "logical links".
Example: Analyzing an article or a talk.
Task: {paste the article text or transcript}
Phase 1: Build a model of the argument:
1. Entities — which concepts, people, phenomena are mentioned
2. Claims — the author's main assertions
3. Arguments — which reasons are given in support of each claim
4. Links — how the claims relate to each other (support, contradiction, consequence)
5. Premises — which implicit assumptions underlie it all
Do NOT evaluate the arguments at this stage.
Phase 2: Using the model, assess:
• Logical coherence — is every claim backed up
• Completeness — are there gaps in the argument
• Weak spots — where the argument rests on unverified assumptions
Result: You get a structured map of the argument rather than a vague impression. The model will surface hidden assumptions and show where the logic limps.
🔧 Technique: Iterative checking → catch errors in the model
By default MFR builds the model once. But if the task is complex, the model may be incomplete. Add a verification loop.
Phase 1: [build the model as usual]
Phase 1.5: Check the model you built:
• Are all entities accounted for?
• Are all dependencies between actions reflected?
• Are all constraints stated explicitly?
If anything is missing, add it to the model.
Phase 2: [reason within the final model]
This adds tokens, but it's critical for tasks where mistakes are costly (for example, budget planning or medical protocols).
🔧 Technique: Visualize the model → make human review easier
Ask the model to output the structure as tables or a dependency graph. That makes it easier to check for completeness and correctness.
Phase 1: Build an explicit model of the task.
Present the result as tables:
Table 1: Entities
| Name | Type | Initial state |
Table 2: Actions
| Action | Preconditions | Effects |
Table 3: Constraints
| # | Constraint description | Type (time/resource/logical) |
The table format makes the model easy to scan, so you'll quickly notice if something is missing.
Resources
Model-First Reasoning LLM Agents: Reducing Hallucinations through Explicit Problem Modeling
Gaurav Kumar (Independent Researcher, Stanford AI Professional Program)
Annu Rana (Independent Researcher, IESE EMBA Program)
Works referenced: - STRIPS (Fikes & Nilsson, 1971) — the classic AI planning formalism - Mental Models (Johnson-Laird, 1983) — cognitive science of mental models - PDDL — Planning Domain Definition Language (McDermott et al., 1998) - Chain-of-Thought (Wei et al., 2022) - ReAct (Yao et al., 2022)