AI AgentScience & Tech Frontiers

The Value of Multimodal Models: Not in Understanding Images, but in Choosing to Look

Three Labs, the Same Demo

In August, three labs released multimodal models in succession, and the hero cases in their launch materials exhibited the exact same pattern. Meta’s Muse Spark 1.2 converted a video of a house uploaded through a terminal into a functioning, interactive vacation home booking page. Z.ai’s GLM-5.3-Flash featured a dedicated section in its official materials titled “Vision in the coding loop”, where all eight best practices followed the same sequence of actions: render the code, observe the rendering results, correct visual discrepancies, and execute the rendering again. DeepSeek’s V4-Flash-Vision-Exp showcased three typical use cases: a Tibet road trip presentation, a secondary creation of its official website, and a clay-monster-styled frontend interactive demo. These three cases demonstrate the same workflow: the model first comprehends images, page structures, and design intents, and then invokes tools to produce the corresponding deliverables.

Three independent teams presented similar demonstrations within a close time window. Labs typically select showcase cases with great care; the cases themselves carry their core thesis. These three demos share a common action structure: the model first observes a video, screenshot, or page, and subsequently invokes tools to generate a webpage, presentation, or mini-game. In Meta’s and GLM’s materials, this set of actions includes a final step: looking back to inspect the artifact it just created. GLM’s best practices explicitly require users to “launch the project and compare screenshots of each page against the reference images. Continuously refine differences”; Meta’s official post also documented how the model builds a closed loop through self-examination: “By re-examining the artifacts it generates, it drives a continuous self-improvement loop”.

Visual question answering capabilities have existed for years: a system receives an image and a question, then outputs the corresponding answer. That was the role vision played in the past—merely serving as an input channel for the system. The adjustment made by these three labs is transforming vision into action steps autonomously decided by the model. The model begins to judge for itself when to observe, which region to inspect, and whether to look back and check its own deliverables. Meta provided a clear explanation of this in its announcement post: “Muse Spark 1.2’s multimodal gains are most pronounced when the model can use tools. It can inspect visual inputs more closely and incorporate what it finds into its reasoning.”

We Have Seen Such a Phase Shift Before

A similar transformation took place three years ago. RAG in 2023 was a static pipeline: the user asks a question, code executes retrieval, and the model generates an answer. Once the pipeline finishes, even if the result is off-target, the code will not take the initiative to turn back and make adjustments. Whether to retrieve, how many times to retrieve, which keywords to choose, and whether retrieval results are sufficient—all were hardcoded in presets. Agentic RAG turned retrieval into a tool actively called by the model: the model decides on its own when to initiate a search, whether to retry with different keywords, and at what point retrieval is sufficient to stop. The focus of what engineers deliver shifted accordingly—from fixed code pipelines to behavioral contracts for the model.

The vision domain is undergoing the exact same turning point. In early systems, images were merely inputs fed to the model—images go in, answers come out. Now that models are equipped with tools, they begin to autonomously decide when to bring up an image, which region to focus on, and whether to look back and scrutinize the interface they just wrote. When facing a sentence that can be directly scored, unidirectional input and output is enough to complete the task. But for complex artifacts that need to be rendered, clicked, or executed, a unidirectional path quickly stalls midway and must rely on continuous interactive actions to verify results.

A static unidirectional pipeline can only produce gradable answers, whereas a closed loop enables the model to verify its own artifacts

This Time, the Direction of the Closed Loop Is Reversed

Comparing these two closed loops closely, the direction of information flow is precisely reversed. In Agentic RAG, the model lacks information about the external world and therefore initiates retrieval outward—the direction is from world to model. In Agentic Vision, the model first generates content, and to verify whether the result is accurate, turns back to inspect its own output—the direction goes from model to world and back to model, forming a self-verifying closed loop.

For tasks such as UIs, games, presentations, and 3D scenes, correctness itself is directly manifested at the visual level. The code may compile properly, and the page may open smoothly, yet misaligned layouts, stuttering animations, or color deviations can only be uncovered once it is actually rendered, clicked, or executed. As GLM pointed out in its official materials: “many failures only show up once it is rendered, clicked or played.”

This also explains why models must possess vision natively. If vision is treated merely as a peripheral interface—where a text agent calls a vision API to obtain textual descriptions and then continues processing using the translated text—the chain for inspecting its own artifacts breaks down. GLM pointed this out in its official documentation: vision needs to be natively integrated into the model, allowing the model to decide for itself when to observe and use visual feedback to guide its next action.

The retrieval loop flows from world to model, while the self-verification loop flows from model to world and back to model

How to Measure a Model That Knows How to Look

As the modality of model capabilities evolves, the evaluation methods must adjust accordingly. Early testing methods were akin to visual question answering: given an image and a question, answers were graded against a standard answer key. This approach evaluates a single instance of observation and response. When facing a task like building a playable game, it is impossible to write down a rubric in advance that covers every detail, nor does the artifact itself have a unique standard answer.

When dealing with artifacts that lack standard answers, the solution is pairwise comparison. By collecting thousands of pairwise judgments, an overall Elo ranking can be calculated, much like the mechanism employed in chess and Chatbot Arena. Meta implemented this logic in WildArtifactBench: agents are tasked with fully creating a webpage, game, or presentation, which is then submitted to judges for pairwise quality comparisons, fitting Elo scores from win rates. This approach no longer relies on ground-truth answers, allowing the evaluation scope to cover diverse tasks, deliverable formats, and varying degrees of verifiability.

To ensure fairness among judges, the benchmark established two parallel tracks: agentic judges and human judges, each completing around 2,000 pairwise comparisons. AI judges are flexible to call but may exhibit biases, whereas human judges provide stable judgments at a high cost; the conclusions of both tracks corroborate each other to establish the final results. The evaluation environment itself must also support practical interaction: models are placed in a sandbox environment equipped with a GUI, with a maximum step limit per exploration trajectory and financial costs calculated separately.

This benchmark acts as a ratchet here: it turns whether a model can actively take action to see clearly into a quantifiable fact, and once quantified, training has a clear objective. WildArtifactBench will be open-sourced, and the weights for Muse Spark 1.2 will also be made publicly available.

How to Train a Model That Knows How to Look

With evaluation criteria in place, training methods must also keep pace. Traditional training data mostly consists of paired images and descriptions, or images and answers. Such data can teach a model to observe an image and provide an answer, but cannot teach it to inspect its own work, pinpoint flaws, and take action to fix them.

Developing this capability is akin to mentoring an intern on creating presentations. Merely showing them a thousand beautifully formatted finished slides will hardly help them grasp the essentials of typography and layout. A far more effective approach is to have them lay out a page themselves, inspect the visual result on their own, and make adjustments one by one whenever they encounter overflowing text, misaligned components, or overlapping images and text. Only by recording the complete sequence of creation, inspection, and modification can the intern truly internalize the methods of adjustment from this chain of actions.

Model training follows the exact same logic. In synthetic data generation, GLM requires models to continuously interact with the environment, inspect their own outputs, and make iterative revisions, preserving the entire interaction trajectory as training data; in frontend tasks, training uses environmental feedback for reinforcement learning, where the rendered output serves as direct visual feedback for the model. Muse Spark 1.2 similarly constructed a comparable loop in its training pipeline, utilizing the previous generation Muse Spark 1.1 to construct challenging environments and scoring candidate solutions to form a dataset ready for training.

This training approach exhibits a clear symmetry: during the training phase, external processes guide the model through generation, inspection, and correction; during the inference phase, the model autonomously repeats generation, inspection, and correction. The objective of training is to enable the model to internalize the requirements of external processes into its own behavioral habits. In visual tasks, environmental feedback is even more direct: while answers in text tasks often rely on another model for scoring, in visual tasks the rendered image is right there—the model can directly see discrepancies, allowing the actions of inspecting deliverables and iteratively fixing them to reliably obtain feedback signals.

The training loop and the inference loop share the same cycle of generation, inspection, and correction

In Closing

For engineers building applications, the focus when selecting and invoking multimodal models is shifting. First, look at whether the model can complete an interactive closed loop: whether the execution framework grants it the ability to both observe and invoke tools simultaneously, whether the runtime environment allows it to render pages, click elements, and execute code, and whether the model itself takes the initiative to look back and inspect its generated artifacts. Traditional static VQA benchmark scores still hold reference value, but the primary axis for evaluating model capability has shifted.

The release of highly consistent demonstration forms by three laboratories within the same time window sends a clear technical signal. Visual perception is being integrated into the core loop of agent systems as an action autonomously initiated by the model, and this capability can now be systematically trained and evaluated.

When evaluating multimodal models, we no longer need to look solely at how accurately they interpret images. What matters even more is whether they take active initiative to see clearly.