Skip to main content

PAN 2 from MBZUAI: what MENA teams should test

An open world model offers inspectable simulation, but complete-plan results, deployment boundaries and failure cases deserve a closer look.

Updated 7 min readMarkdown
Part of seriesAnalysis
PAN 2 from MBZUAI: what MENA teams should test

Abu Dhabi's Institute of Foundation Models at MBZUAI has released PAN 2, a world model that turns a starting scene and a described action into a simulated video. The release gives regional research teams something they can inspect and adapt, rather than another demonstration they can only watch.

The useful distinction is between predicting a plausible sequence and establishing that the sequence would happen. PAN 2's own evaluation makes that gap visible: individual steps succeed much more often than complete plans. For MENA teams considering robotics or industrial AI, that is a reason to investigate the model carefully, not to connect it to equipment.

Cover: original SultanByte artwork showing a scene and proposed action passing through reasoning and video simulation, with physical validation kept separate.

What is available to inspect

The IFM release materials describe a November 2026 release with model weights, training code and inference code. Its public repository includes the perceptual backbone's training pipeline and the conceptual reasoner's prompt format. These are inspectable artefacts, although a repository is not a turnkey deployment or a promise to reproduce every published result.

The model card identifies the released simulator as a roughly 29-billion-parameter diffusion model. It supports text-to-video and image-to-video from an optional starting frame, with output of up to 20 seconds. PAN 2's own code and weights use Apache 2.0; third-party components retain their own licences. A commercial team should review the whole dependency set, not stop at the headline licence.

The contribution is UAE-linked research infrastructure, not evidence of a deployed regional robotics service. A Saudi manufacturer, a UAE logistics operator and a university lab could investigate the same release while needing very different datasets and acceptance criteria. The release does not establish performance at any of their sites.

A reasoner and a simulator do different work

PAN 2 separates conceptual reasoning from visual prediction. A language model describes the next state, including timed actions and camera movement. The diffusion model then produces visual detail from that structured description. The resulting video is an observation for an external agent to assess, not a command sent to a machine.

That separation matters when reproducing a demonstration. Changing the upstream language model can change the plan being simulated even when the video weights stay fixed. Record the reasoner, its prompt policy and the generated state description alongside the simulator checkpoint. Otherwise, two teams can say they tested PAN 2 while evaluating different systems.

Hugging Face's Diffusers documentation explicitly says its integration contains the generative simulator, not the reasoning backbone that writes the prompts. It documents modular text-to-video and image-to-video workflows. Loading that pipeline therefore does not, by itself, reproduce the complete reasoning-and-simulation system.

Treat the structured caption as an interface worth testing. Does it preserve the requested action, the starting condition and the order of events? A visually convincing clip cannot repair an incorrect description passed into the simulator.

Read the complete-plan result before the ranking

In IFM's multi-step study, PAN 2 achieves 75.1% step completion and 34.0% full-plan completion. These are different measures: the latter requires every step in a simulated plan to complete. They are research-team results on the study's tasks, not robot success rates or an estimate of industrial reliability.

The model card describes 100 everyday tasks presented in both image-to-video and text-to-video form, producing 200 prompts and 456 steps. It also says the quantitative study covers open-loop plans designed to succeed. How faithfully the model simulates plans that should fail has not yet been measured. That missing test matters when the intended use is rejecting unsafe or impossible actions.

Avoid turning a selected comparison into an unrestricted leaderboard claim. The Physics-IQ benchmark repository distinguishes image-conditioned and multi-frame inputs, prompt treatments and candidate-selection methods. Its rules also prohibit using test data to improve submission scores. A procurement comparison needs matching configurations and uncontaminated evaluation material, not just the highest number beside each model name.

PAN 2 research results: 75.1% step completion versus 34.0% full-plan completion. The study uses 100 tasks, 200 prompts and 456 steps; plans are designed to succeed, and these are simulation results rather than real-world success rates.

Original infographic: SultanByte. Source: IFM PAN 2 technical blog and model card, November 2026. Percentages describe different completion measures in the same multi-step study; they are not deployment performance.

Budget for the actual pipeline

The vLLM-Omni PAN 2 recipe documents offline generation and video-serving interfaces, along with hardware-specific configurations. It expects structured captions and separates text-to-video from first-frame-conditioned generation. Use its hardware profiles as starting configurations to validate, rather than as a universal capacity promise.

For a pilot, measure the complete request: caption generation, video generation, safety checks and review. Record peak memory, elapsed time, failed generations and the cost of repeated attempts. A short output video says nothing about how quickly it was generated. Do not equate a 20-second simulation window with real-time operation.

The Diffusers page inspected for this release is the development documentation and says it requires installation from source. Pin the tested code revision and model files. A working notebook against a changing branch is weak evidence for a reproducible service.

Keep data routing explicit. If a local simulator receives captions from a remotely hosted reasoner, the system is not wholly local. Review the starting images, descriptions, logs and review tools as separate data paths. Hosting the weights in one country does not answer where every component processes customer information.

Give a regional pilot a falsifiable task

Our proposed first use is an offline evaluation, using non-sensitive scenes that the team can reproduce safely. For example, ask whether an object remains present after occlusion, whether an action respects a prerequisite, or whether changing the camera leaves the scene's state intact. Define the expected outcome before generating the video.

Include deliberately impossible instructions and cases that should fail. Preserve every attempt instead of selecting the best-looking clip. Score intermediate states as well as the ending: a final image can look correct even when an object appeared without the required action.

Use separate reviewers for visual realism and task correctness. Record disagreements and compare generated sequences with controlled observations where feasible. If prompts need manual repair, count that intervention as part of the workflow rather than presenting the repaired clip as an unattended result.

For Arabic-facing products, test the language interface independently. Equivalent Arabic and English requests should preserve the same objects, constraints and action order in the structured caption. This is a proposed local acceptance test, not a claim that the release demonstrates Arabic instruction parity.

Keep simulation outside the control loop

The model card warns about prompt sensitivity, drift across long interactions and coarse text descriptions of dexterous actions. It also distinguishes generated predictions from evidence of events. Content guardrails address harmful requests and outputs; they do not certify physical correctness.

A CTO can approve a bounded research exercise without approving autonomous control. A buyer should ask for the exact tested pipeline, retained failure cases and a comparison against its own task criteria before funding a larger deployment.

PAN 2 makes a useful research system accessible. The next meaningful result for a regional team is a reproducible evaluation showing where that system predicts consequences correctly, where it fails and how much human correction it needs. A convincing video should begin that review, not end it.

About the author

  • I have lead the Engineering for multiple startups in UAE. I also have my own agency qualascend.com.

The gap between 75.1% step completion and 34.0% full-plan completion is the number I would keep in front of any team planning a pilot. A model can look capable step by step and still fail most complete plans, because one wrong step breaks the whole sequence. That is the difference between a good demo and a system you can rely on.

Your point about testing the Arabic interface independently is also important for MENA teams. Equivalent prompts in Arabic and English should give equivalent behaviour, but that cannot be assumed — it has to be tested with the same scenes and the same scoring, or a team can end up with a product that works well in one language and quietly underperforms in the other.

I would add one more test to your falsifiable pilot: deliberately impossible instructions, as you suggest, plus a check on what happens after a failure. Does the model recover, repeat the same mistake, or drift? How a system fails matters as much as how often it succeeds, especially if anyone is tempted to move simulation into a control loop later. Keeping that boundary explicit is the right call.