Your AI agent is editing video blind

It is tempting to treat this as a capability problem that the next model release solves. It is not. Consider what the agent actually has to work with when it drives an editor through a typical API: a list of clips, each with numbers attached. Position, size, duration, a font name, a colour.

From that, to know whether a caption is readable, the model has to hold the entire rendering pipeline in its head — how the font metrics resolve at that size, how the element's box is computed from its anchor, what is painted on the track above it, how the whole thing scales at the project's resolution. It has to simulate the renderer, accurately, every time, with no way to check its answer.

People are not asked to do this. An editor looks at the canvas. The feedback is immediate and total: you see the text is too small, you make it bigger. No mental model of font metrics required. When we removed that loop for agents and left only the JSON, we asked them to do the one thing the interface exists to make unnecessary.

So the fix is not a better guess. It is closing the loop.

The most direct repair is to hand the agent a picture. In Vidmoat, an edit can carry a previewAt parameter with a list of timestamps, and the rendered frames come back as images in the same response as the edit result. One round trip: change the thing, see the thing.

That single change alters the character of the mistakes. An agent that can see its own output stops arguing from arithmetic and starts correcting from evidence — the same loop a person uses, at a speed a person cannot match. It places the title, looks, notices it is clipped, moves it, looks again.

It also changes what the agent will admit to. An agent working only from numbers reports success whenever the API returns ok, because that is genuinely all it knows. Give it the frame and it will tell you the title is missing, because now it can tell.

Frames alone are not enough, for a practical reason: checking every frame of a five-minute video is not something you want to pay for in tokens or in latency. Images tell you about the moments you thought to look at. Something has to catch the moments you did not.

So every edit in Vidmoat also returns a lint array — the same idea as a compiler warning, pointed at layout instead of syntax. It samples the timeline, estimates each visible element's box, and reports what it finds in specific, actionable terms:

1. 01Text overlapping other text, with the percentage of the smaller element covered and the timestamp where it happens.
2. 02Elements entirely off-canvas, quoting the estimated box coordinates against the canvas size, so the correction is arithmetic rather than guesswork.
3. 03Elements running past an edge, naming which edge and by how many pixels.
4. 04Type that renders below a readable threshold for the canvas height — with the font size it should be instead.
5. 05Clips completely covered by something on a higher track for their whole duration, which can never appear in the render.
6. 06Elements crossing the 90% safe area, where a platform's own UI is likely to sit on top of them.

Writing the checks is easy. Making them worth reading is not, and this is where most automated-warning systems quietly fail: a lint that cries wolf gets ignored, and an ignored lint is worse than none, because it costs tokens and buys nothing.

Two decisions did most of the work. Stacked video and images are not flagged as overlaps, even though they overlap constantly — picture-in-picture, B-roll cutaways, adjustment layers and multicam angles are all deliberate, and warning about them would bury the real findings. Text sitting on top of a shape is not flagged either, because that is a lower third, one of the most common designed patterns in video.

What survives is the set of cases that are almost never intentional: text over text, anything off the canvas, type too small to read, a clip that is invisible for its entire life. The result is a warning list short enough that "fix every warning before rendering" is a reasonable instruction rather than a wish.

The lint also nominates timestamps worth looking at, which is what ties the two channels together: the warnings decide where to spend the expensive frames.

Everything above is geometric. It knows whether your caption is on the canvas, overlapping, and large enough to read. It does not know whether the caption is any good.

No warning fires for holding a shot four seconds too long, cutting on the wrong beat, or choosing footage that does not earn its place. A montage that fails to build is, to every check described here, a clean project. Taste has no lint rule.

The honest framing is that this makes an agent reliable at the mechanical layer, which happens to be the layer where most editing time goes — transcribing, cutting filler, syncing, reframing, restyling captions across forty clips. It does not make the agent a director, and a product that claims otherwise is selling you the demo rather than the workflow.

The generalisable lesson has little to do with video. Any agent acting on a system with a visual or physical output needs a channel back from that output, and the API return value is not that channel — it only tells the agent that its instruction was received, which is precisely the thing that was never in doubt.

Three principles carried most of the benefit, and they transfer:

1. 01Return consequences, not confirmations. "ok: true" answers a question the agent was not asking. Say what changed and what it looks like now.
2. 02Make the cheap channel structured and the expensive channel visual. Warnings are text and can run on every edit; rendered frames cost real money, so spend them where the warnings point.
3. 03Tune for precision over recall. A warning the agent learns to ignore is worse than no warning, because it still costs tokens on the way past.