Voice-over takes a recording, writes down what was said, translates it, and speaks it back in another voice. Three different model surfaces in one run — transcription, chat, speech — which makes it the best thing we have for answering a question people ask about agents in general: what does chaining models actually cost?
The three stages cannot overlap
This is the part worth understanding before you reach for any chained agent. Each stage's input is the previous stage's output, so there is nothing to parallelise: the translation cannot start before there is a transcript, and nothing can be spoken before there is a translation.
So latency is the sum, not the maximum. For a three-minute clip that works out at roughly:
- Transcription — the long pole, and the one that scales with the length of the audio rather than the amount of speech in it.
- Translation — a few seconds. It is a chat call on a few hundred words, and it is the cheapest part of the run by a wide margin.
- Speech — scales with the text, not the original audio. A dense three minutes costs more to speak than a sparse ten.
The practical consequence: if you are pricing a workflow like this, price it per minute of audio for the first stage and per character for the last, because they do not move together.
You get to correct the middle
The transcript is shown before anything is translated, and this is the single most useful design decision in the agent. Transcription mistakes are not random — they cluster on names, on domain jargon, and on the exact words most likely to matter.
Left alone, a wrong name propagates: it is translated as if it were a word, then spoken confidently in the new language, and by the time you hear it the error is three stages deep and expensive to fix. Correct it in the transcript and the other two stages are just rerun.
Four voices, and the agent says so first
The honest constraint is the interesting half of this agent. There are four voices. If you ask for a fifth — a specific accent, a particular register, a clone of someone — you are told before the run starts rather than after it has spent your credit and produced something you did not ask for.
That is a design position and we will defend it: an agent should surface what it cannot do at the point where it still costs you nothing. The alternative is a system that always says yes and then negotiates afterwards, which is how you end up paying for three attempts at a thing that was never available.
What it broke, and it was the big one
This agent is the reason we started writing this series down. On its first attempt the speech step failed — and so did image generation, and so did every other media tool an agent could call. They had never worked. Not regressed; never once worked, since the day they were written.
The cause was two processes running identical code in different environments: our media routes resolve a storage bucket from FIREBASE_CONFIG, which Firebase populates in a Cloud Function and Cloud Run does not set. The media studio called the function, so the studio worked, in front of us, every day. Agents reach the same routes over the Cloud Run loopback.
The first fix deployed cleanly and failed identically, because we had swapped one absent variable for another. The whole story, with the other four findings, is in the series post.
What it is genuinely good for
- Putting a short product video in front of an audience that does not speak the language it was recorded in.
- Turning a recorded walkthrough into a transcript you can edit, and then into audio again, without three tools and two file transfers.
- Checking what a translation sounds like out loud before committing to a human voice session, which is where the real money is.
Open Voice-over. Bring a clip; the first thing you will see is the transcript, and the first useful thing you will do is fix a name in it.