OpenAI Dots x Runway: brief a dot, it plans shots. The Sume loop
Runway's Oct 1 changelog lists OpenAI Dots x Runway for all plans: brief a dot, it plans shots, Runway shoots. The same loop with Sume MCP tools.

Runway's changelog entry for October 1, read 2026-10-03, announces "OpenAI Dots x Runway" for all plans: you brief a dot, it plans the shots, and Runway shoots them. The same plan-then-render loop works with Sume's hosted MCP tools, where an agent calls generate_video for each shot and waits with jobs_wait.
What Runway announced
The changelog line is short, so only the stated behavior is repeated here.
| Date | Entry | Availability |
|---|---|---|
| Oct 1, 2026 | OpenAI Dots x Runway: brief a dot, it plans shots, Runway shoots | All plans |
The loop on Sume
The hosted MCP inventory in the tools doc lists paid creation tools including generate_image, generate_video, music_create, tts_create and stt_create. Paid submits need an idempotency_key, and omitting payload.model routes to sume/auto unless the user named a family.
A typical agent turn plans N shots, submits N generate_video calls, then waits once with a batch jobs_wait. The jobs guide says jobs_wait accepts 1-20 job ids with wait_for set to all or any, and advises one batch wait after a parallel fan-out instead of N single waits.
Waiting without losing work
A remote MCP call holds at most 55 seconds, with 50 as the default. When a wait returns wait_slice_expired, call jobs_wait again with the same ids. Do not resubmit the paid create, because the jobs keep running and keep billing. A 524 on jobs_wait is a transport failure, never a job outcome.
Programmatic fan-out
For three or more independent calls of the same shape, script_run runs a short JavaScript program on the Sume side that calls tools in a loop or in parallel, bounded by timeout_seconds (5-55), max_calls and max_paid_calls. Each paid create inside the script still needs its own idempotency_key.
Use it for a shot list: one call per shot, one returned value, and the child jobs listed for one batch wait afterwards.
Keeping control of spend
An agent that plans shots can also overspend. On Sume, the script bounds help: max_calls and max_paid_calls cap how many tool calls a script may make, and paid creates need an idempotency_key, so a retried step does not bill twice.
Set a shot budget before the plan runs, ask the agent to list the shots with durations first, and approve the list. Then render.
What stays the same
Whatever drives the plan, each shot is a job with an id, a model, a duration and a cost. Save those with the shot list so a re-render of shot 4 does not mean regenerating shots 1 to 3.
Sources
Related posts
More in Agents
- Run the Sume video agent from your backend with Agent Completions
POST /v1/agent/completions runs the same agent as the Sume Agents chat, with tools and media generation, and returns an async run receipt you poll or webhook.
- Safe automation for AI agents that call paid APIs
Keep agents read-only by default, keep secrets out of logs, and on hosted MCP send an idempotency_key, preview with dry_run, and cap with max_spend_usd.
- Scheduled AI video agent runs: cron, API triggers, and receipts
A Sume schedule is a saved Agents automation that runs on a cron cadence and returns a run receipt. Author it in the dashboard; start and monitor runs by API.
- What is a video agent? How Sume defines and runs one
In Sume's docs, a video agent is a sandbox Agent that composes generation tools into a post-ready video. Brief it in chat, or call it over HTTP.
Written by Sume