WorldPrompt Is a Script, Not a Prompt: How Runway's Timestamped Events Hand World-Building to Agents

Start with the simplest possible explanation, the kind you could give a friend who has never used a video model.

Think of a stage play. There is the set: the room, the lighting, where the furniture sits when the curtain rises. Then there is the cue sheet: at minute two the door opens, at minute three someone drops a glass. A conventional video prompt crams both into one paragraph and asks the model to guess the order. WorldPrompt, as Latent Space describes it, pulls them apart. You pin some aspects of the simulated environment, including the first frame, and you list events against timestamps.

That gives you two different kinds of information, and it helps to keep them mentally separate:

• Fixed state. What the world is at the start. The first frame anchors it visually. Other pinned aspects constrain what the model is allowed to change.
• Timed events. What changes, and at what moment. Each event is a discrete instruction tied to a point on the clock.

One caution before you build a mental model that is too detailed. The public excerpt describing WorldPrompt stops before it spells out exactly how events are written, so resist assuming a specific syntax or a fixed list of event types. What you can reason about safely is the structure: a starting state and a sequence. That structure alone is enough to change who, or what, is best suited to write the input.

Here is the first gotcha, and you will hit it early if you experiment with any format like this. People overload the fixed part. They try to describe every future moment in the starting description because that is what paragraph prompting trained them to do. Resist that. The fixed state should describe the world at time zero and nothing more. If something is supposed to happen later, it belongs on the timeline. Mixing the two produces the same muddle the format was designed to escape: a model guessing which details are permanent and which are meant to arrive later.

Humans are mediocre at writing precise timing into prose. Ask someone to describe a thirty-second scene and you'll get vivid adjectives and vague sequencing: "then," "after a while," "eventually." A model reading that paragraph has to infer the order and the pacing on its own.

Agents have the opposite profile. They are often clumsy with evocative description but reliable at emitting ordered, structured lists. Planning a multi-step task, breaking a goal into subtasks, sequencing tool calls: this is the core of what an agent does. A timestamped event list is the same shape of output, just pointed at a world instead of a codebase or an inbox.

That is why WorldPrompt reads to me as a bridging layer. It gives a generated world an input that looks like an agent's native output. Three practical consequences follow:

• Editable in pieces. If event four is wrong, an agent can change event four without rewriting the scene. A paragraph prompt has no such seams.
• Checkable before it runs. An agent can inspect a timeline for conflicts, such as two events claiming the same moment or an event referencing something the fixed state never introduced, before spending any generation time.
• Composable. One agent can own the set, another the action, a third the audio cues. A list merges more cleanly than prose.

Now the gotcha, which I'd bet trips up most first attempts at agent-driven timelines. Agents think in steps. Worlds run in seconds. An agent asked to "make the character walk to the window, then open it" will happily produce two events, but it has no intuition for how long a walk takes in the generated world. If the events land too close together, the model has to rush or skip. Too far apart, and the world idles.

You'll want to give your agent explicit pacing guidance: rough durations for common actions, a minimum gap between events, and a rule that every event must be physically plausible given where things stood at the previous timestamp. That guidance is not something the world model provides. It is something the layer around it has to supply.

To see why timestamps fit this particular model so naturally, you need one piece of vocabulary. Runway calls GWM Worlds 2 an "autoregressive diffusion" model, and per Latent Space, "autoregressive" describes how it generates over time.

The plain-language version: each moment is built on top of the moment before it. The model is not painting a finished clip all at once. It is extending the world forward, frame after frame. Runway's own framing, quoted in the same piece, is that the preview "turns high-fidelity video and audio generation into real-time interactive simulation."

Once you see generation as a forward-moving process, a timeline stops looking like a convenience and starts looking like the obvious interface. If the world is being extended moment by moment, then "at this moment, do this" is exactly the kind of instruction the process can act on. A paragraph prompt front-loads everything. A cue sheet meets the model where it works: at the leading edge of time.

This also explains the first-frame pin. Anchoring the first frame fixes where the forward process starts. It does not, by itself, guarantee where it ends up.

Which brings us to the gotcha I'd flag loudest. Forward-generated worlds drift. Because each moment depends on the last, small deviations compound. A detail you pinned at the start may hold for a while and then soften as the world moves further from its anchor. My read, and it is analysis rather than anything Runway has published, is that you should plan for this rather than hope it away:

• Put the events that matter most earlier in the timeline, closer to the anchored start.
• Keep individual events small and concrete. "The lamp turns off" is easier to honor than "the mood becomes tense."
• If your agent can review output, have it compare later moments against the fixed state and flag divergence, rather than assuming the pins held.

None of that requires knowing Runway's internals. It follows from the one thing the source tells us about how the model works.

ClawBlog's standing thesis is the Harness Hypothesis: the value in AI is less in the model and more in the harness that connects the model to the world. WorldPrompt is a clean test case, because the format itself is a harness artifact. The world model renders. Something else has to write the timeline, validate it, feed it in, watch the result, and recover when it goes wrong.

Look at what agent tooling shipped the same week, and a pattern shows up. None of these releases mention world models. All of them are building the plumbing a timeline-driven world would need.

• Anthropic's Claude Code v2.1.283 release added an identifier to gateway headers "so LLM gateways can group the requests that serve one user prompt." Translated: one thing the user asked for often becomes many model calls, and the infrastructure now wants to trace them as a single unit.
• Google's ADK v2.10.0 release "introduces advanced skill lifecycle management" and "brings richer efficiency metrics to agent evaluation." Translated: agent builders want to manage capabilities over time and measure how efficiently a multi-step job gets done.

Now map that onto a WorldPrompt timeline. One user intent, "show me a storm rolling into the harbor," becomes a fixed state plus a dozen timed events, and possibly many generation requests behind them. Grouping those requests, measuring their cost, and evaluating whether the sequence actually landed are harness problems. They are the same harness problems agent platforms are already solving for code and text.

This is the pattern worth watching, stated as analysis rather than fact: the agent orchestration patterns that matured around software tasks look directly transferable to simulated worlds. The skills are the same. Decompose, sequence, execute, verify.

There is a strategic wrinkle too. Under Commoditize Your Complement, a company that owns the orchestration layer benefits when the rendering layer becomes interchangeable. If a declarative format like WorldPrompt becomes common across world models, the agent that writes timelines can swap renderers the way it swaps language models today. Runway calling it a "proposed" format hints that the company is at least open to it becoming more than a private feature. Whether that ends up helping Runway or the harness vendors is the open question.

A timeline sounds tidy on paper. In a live, interactive simulation it has to survive contact with real connections, and real connections break.

You can see agent tooling bracing for this. Pydantic AI's v2.51.0 release lists compatibility notes for Google's Gemini Live realtime models, including rejecting an unsupported feature "at connect" and raising a dedicated realtime error around Gemini Live sessions closing. The details are specific to that library, but the lesson generalizes: realtime sessions have their own failure surface, and frameworks are giving those failures names so agents can handle them instead of silently stalling.

Apply that to a world driven by timestamped events. Suppose the session drops at second eighteen of a forty-second timeline. What happened to events at twenty, twenty-five, and thirty? Did any fire partially? Does your agent know where the world was when it died?

Here is the checklist I'd hand anyone wiring an agent to a realtime world, based on how streaming sessions tend to fail:

• Log every event as it fires, not just when it was scheduled. The gap between planned and delivered is where debugging lives.
• Design for resume, not restart. If the fixed state and the last delivered event are recorded, an agent can pick up from there instead of regenerating the whole world.
• Check capabilities before you start. Pydantic AI moved a rejection to connect time for a reason. Failing before the first frame is cheaper than failing mid-scene.
• Keep a human-readable copy of the timeline. When something looks wrong, you want to read the cue sheet, not reverse-engineer it from frames.

It also helps to be clear about which kind of "moving picture" your agent is actually making. Simon Willison recently described asking Claude Opus 5.5 to build an animated pixel-art kākāpō party on an HTML canvas, noting buzz about how good the model was at pixel art animations. That is one path: the agent writes code that draws, and the result replays identically every time. A world model driven by a timeline is the other path: the agent writes a script, and a generative system performs it live, never quite the same way twice.

Both are legitimate. They fail differently. Code breaks loudly and reproducibly. A performed world drifts, drops, and improvises. Your agent's verification strategy should match the path it is on.

On a Wardley Map, which plots components from genesis through custom-built to product and finally commodity, WorldPrompt sits firmly at the left edge. The model it serves is a research preview. The format itself is described as "proposed" in Latent Space's piece. Expect it to change, possibly a lot.

That has practical implications for you right now:

• Don't build deep dependencies on exact syntax. Keep your agent's internal representation of a scene (fixed state plus timed events) separate from whatever format it gets translated into. If the format shifts, you rewrite one translation step, not your whole approach.
• Do invest in the concepts. Separating fixed state from events, pacing actions realistically, and verifying against anchors will outlast any single format.

The second framework to reach for is the Autonomy Spectrum, because most failures come from deploying at the wrong point on it. For world scripting there are roughly three positions:

• You write, the agent assists. You author the timeline; the agent checks it for timing conflicts and missing setup.
• The agent drafts, you approve. The agent turns your intent into a full cue sheet; you review before anything renders.
• The agent writes and runs live. The agent generates, executes, watches, and adjusts events on the fly in a realtime session.

For a format at genesis, I'd start in the middle. The agent is good at producing structure, you are good at noticing when a sequence feels wrong, and a review step costs far less than a botched generation. Moving to full autonomy makes sense only once you have the logging and resume behavior from the previous section in place.

Three signals will tell you whether this pattern is going mainstream:

• Whether other world model builders ship comparable event-timeline inputs, which would push the idea from proprietary feature toward shared grammar.
• Whether agent platforms add first-class tools for authoring and validating timelines, the way they already have for code and documents.
• Whether events can be injected during a live session rather than only scheduled up front. The phrase "real-time interactive simulation" suggests that is the direction. That capability is where agents stop being scriptwriters and start being directors.