Two upgrades landed in Showspring over the last couple of weeks, and they turned out to be the same idea wearing different clothes. One is about how the software gets built. The other is about how the video gets made. Both come down to a single conviction: you get studio-grade results by coordinating many specialized parts, not by asking one clever thing to do everything.
Two kinds of fleet, one idea
First, a distinction worth getting right, because it is easy to blur. Showspring is not a product that runs a fleet of agents at the customer. It is a product that is built by a fleet of agents, and that already runs on a crew of agents to guide a filmmaker through making a show. Two different agent systems, doing two different jobs.
The first is the development fleet: the team of AI coding agents that writes and maintains Showspring itself. The second is the product: when you open Showspring and make an episode, a dozen specialized AI operations are already working alongside you, from the first idea to the final render. The newest and most visible of those is the Showrunner. Same bet in both places. Coordinate many specialized parts toward one coherent result, instead of asking a single model to be good at everything.
The fleet that builds it
Most people using AI to write code today are driving a single agent. One model, one context window, one set of hands working the task in order. For a contained job that is often all you need. But Showspring is not a contained job. It is a real, growing product, and running it off a single assistant started to feel like staffing a studio with one very talented intern.
Here is the honest before and after, because I lived the before for months.
Before: one driver, with helpers. I ran the whole thing from a single Claude session. It could spawn subagents to parallelize, and I would occasionally hand a risky diff to Grok or to Codex for a second opinion. That sounds like a team, but it was really a hub and spoke. The subagents were spawned by one orchestrator, shared its context, inherited its blind spots, and vanished when the task ended. Grok and Codex were consultants I walked in for a single answer, not teammates who owned anything. When the one driver was wrong, everything downstream was wrong with it, confidently.
After: a fleet of independent developers. Now there is no single driver. There is a fleet of separate sessions, each a full developer in its own right, each owning a lane, coordinating as peers through a protocol rather than through one central brain.
- It is multi-model, not multi-instance. The lanes span different model families and runtimes: Claude Code, GPT through Codex, Grok, Google's Antigravity running a mix of Gemini, Claude, and open models, and local open models on my own RTX 5090. One model reviewing its own work is an echo chamber. Different families arguing about the same diff is a code review. The blind spots are uncorrelated, so real problems surface instead of getting rubber-stamped.
- They coordinate, they do not collide. The agents can see each other, announce what they are working on, take a lease on a shared chokepoint file so two of them never edit it at once, ask each other questions and block for the answer at zero cost, and get work handed to them as a brief they can accept or decline. There is even a standing coordinator agent that holds the map and answers the routing questions, so the humans do not become the bottleneck. It behaves like a small team with rules, not a crowd shouting into one repo.
- It routes by cost. Cheap, high-volume, low-stakes work goes to the local GPU, effectively free once the machine is on. The scarce, expensive frontier models are saved for the hard calls. A single premium agent doing everything burns money grading its own trivial homework.
- It ships. This is not a lab demo of orchestration. The fleet went live this weekend, straight onto Showspring's real production codebase. In the days since: 172 commits, 291 files touched, 19 lanes running, 229 tasks dispatched, verified along the way by 200 automated QA passes. The output is audited, human-readable code that scales, not disposable vibe-code.
That is the concept. Here is the actual thing, running. This is the fleet's control plane: every lane, what it is working on right now, and which model family is driving it.
Why bother? Because the operating model that is winning right now is velocity with discipline. The teams that move like a large org while staying small are the ones pulling ahead, and a well-run fleet is how a single builder gets there without the output turning to mush.
The crew that runs it, and June
Now the other fleet, the one inside the product. This is the part people miss when they call Showspring a video generator. When you make an episode, you are not driving one model through one prompt. A whole crew of specialized operations runs alongside you, each pointed at a different part of the craft:
- An idea agent that pitches episode concepts and story beats.
- A script writer that drafts and revises in the show's own voice, and holds to its show bible.
- A show-bible keeper that proposes canon and keeps continuity from drifting.
- Character, prop and location builders that write and render each new element on-model.
- A casting check that looks at a finished frame and counts who is actually in it, and where.
- Image and video prompt assemblers, a reference picker, a continuity board, and a voice stage that speaks lines through neural TTS.
A dozen distinct jobs, spread across Claude, Gemini, Grok, a local open model, ElevenLabs for voice, and the video engines. That is the crew that has been guiding the content process all along.
The newest layer on top of that crew is a showrunner, and giving something that job turned it into a person. Her name is June.
June works the way a good showrunner does on a real set. She is in the room the whole time, she knows the entire production cold, and she never grabs the wheel out of your hands. She sits in a rail beside the ten steps, headset on, clipboard ready.
Ask her what a step is for, whether the episode is ready to render, or what is drifting from the bible, and she answers from your actual show, not from thin air. Ask her to generate the idea, revise a line, regenerate a scene, or start the render, and she does the work, but she shows you the plan first and waits for your yes.
Why she exists: a ten-step studio is a lot to hold in your head, and the real bottleneck in solo production was never the models, it was knowing what to do next and catching the thing that quietly broke three steps ago. June is the crew member whose entire job is to keep the show coherent and keep you moving. She has read everything, she remembers where every loose thread is, and she is never the one who publishes or spends. You stay the director.
Two things keep her honest. She is cost-routed: her everyday thinking runs on a local open model on my own GPU and only escalates to the cloud when a task truly needs it, so an assistant you talk to all day does not quietly run up a bill. And she is human-in-the-loop by construction: every action she proposes is rebuilt and re-checked on the server from your real data before anything happens. She never picks a winner in a creative tournament, never switches providers behind your back, and never publishes or bills on her own. She is rolling out now, live in the staging studio.
Reference-to-video: the quality jump
The second upgrade is on the video side, and it is the one you can actually see. Over the last few weeks I moved Showspring's video generation to reference-to-video, or R2V, using Seedance.
The old default was image-to-video: you hand the model one starting frame and it animates forward. The problem is that everything after frame one is invented, so identity drifts. A character's face wanders, a coat changes shade, a second dog quietly turns into a slightly different dog by the end of the shot. It is fine for a single subject in a short beat. It falls apart the moment a scene has a cast.
R2V changes the contract. Instead of one frame, you hand the model a set of reference images, one for each character, the location, the key props, alongside the prompt, and it anchors identity to those references across the entire shot. Seedance holds up to eight of them at once. The practical difference is the gap between "a dog that looks roughly like Rusty" and "Rusty." In an ensemble scene with five distinct dogs, that gap is the entire ballgame.
What actually goes into one shot
Here is the part people underestimate. A good shot is not a prompt. The prompt is assembled, not typed, and Showspring builds it for every clip automatically. The text you see in the field is stitched together from all the show's sources: the show bible and its canon, the character definitions and their reference photos, the show's DNA (the persistent voice and the persistent look), the location, the props, and the camera and motion direction. Below is the actual Scenes step, with each of those sources traced right onto the real interface.
Every one of those lines is a decision that used to belong to a human on set: casting, blocking, location scouting, props, the camera move, the grade. And the same assembly happens again when the shot starts to move. The video step pins each character's identity, the location, the approved start frame, and the motion and voice into one reference-to-video payload, so the clip stays on-model from the first frame to the last. Seedance holds up to eight of those references at once across the whole moving shot.
The reason the output looks like a show instead of a slideshow of prompts is that the tool coordinates all of it in concert, shot after shot, for a whole episode.
A first, very wet look
All of this is going into the first full Seedance R2V episode of the Doodle Cast, which is in production now. It is called Greenies Overboard: a cruise, a greenie-smuggling operation, a storm, and a shipwreck that strands the pack on an island. It is exactly the kind of multi-character, multi-location story that used to be impossible to keep on-model, which is why it is the right one to prove the new pipeline.
Here is a raw clip straight out of the pipeline. Mimi, thoroughly soaked, riding out the storm in the lifeboat. Her one and only note on the experience: "Yipe. Wet. I hate wet."
This is one clip out of dozens, and the episode is coming together fast. I am excited to release it soon.
Showspring is shared as early access with people who want to try it and shape it. If any of this is interesting to you, request access at showspring.com and I will get you set up.
The through-line
Built by a fleet, run by a crew, rendered from a payload of references. It is the same bet made three times over: stop asking one thing to do everything, and instead coordinate many specialized parts toward a single coherent result. That is what turns a clever demo into something that actually looks, and works, like a studio.
Discussion
Be the first to comment