We built a video pipeline that takes a short brief and turns it into a narrated video. The interesting learning was how much work lived around the agents: saving the script, waiting for audio, checking the scene plan, and deciding when a person needed to step in. We used Strands Graph to make that work explicit. It left me thinking that the agent harness is the next big thing in applied AI, because that is where a useful generation becomes a task you can finish, inspect, and run again.
These are notes from building a local video tool, not a benchmark of agent frameworks. I don't have a chart proving that harness engineering beats buying a better model. I do have a much clearer idea of which problems a better model would leave untouched.
The useful question is what survives when the agent gets something wrong.
What an agent harness means in actual work
I use agent harness to mean the software around the model that manages its context, tools, state, checks, and execution. In our case that includes the graph, typed outputs, saved files, approval points, and the rules for stopping a run. A prompt tells the writer what a good script looks like. The harness decides whether that script is valid, which step can use it, and what happens if the next step fails.
Video makes the distinction painfully concrete. A script can read well and still be too long for the requested duration. A scene can look sensible on paper while its voice recording runs past the scene boundary. Changing one sentence means the old audio is now wrong, even if the filename hasn't changed. None of those problems disappears because the writer sounds more confident.
So the work moved into the connections. Which narration belongs to this recording? Has every branch finished? Which file did the person approve? That is ordinary software engineering, with a model producing some of the inputs. I found that a useful way to keep the project understandable.
Lesson one: give every stage something concrete to hand over
Our agents return typed objects: research notes, script beats, scene plans, and critic verdicts. The run keeps those artifacts on disk. That means I can open the script, change the wording, and continue from there. I don't need to ask a conversation to remember which version it meant.
The same decision helped with approvals. The draft graph finishes before script review. The service records that the run is waiting, and a later command continues production using the reviewed script. At the more hands-on setting, there is another stop for scenes and images. The person reviews an artifact with a clear place in the workflow.
This also changes debugging. A saved scene specification, an event log, and a checkpoint give you somewhere to start. You can distinguish a bad writing decision from a missing image or a render failure. A long transcript can contain all three while making none of them easy to find.
My reusable lesson: decide what each stage hands over before polishing its prompt. Give that output a schema, an owner, and a file you can inspect.
Lesson two: a graph is only as good as its execution rules
We used Strands Graph for the draft and production flows. Production has useful parallel work: plan scenes and resolve their visuals, synthesize narration, and choose music. Timing comes after those branches. On a drawing, three arrows meeting at a box look obvious. In code, you still have to say what that meeting means.
The Python SDK's default incoming-edge behavior is OR: one satisfied incoming edge can make the destination ready. Our timing step needs all three branches. We added the same completion condition to each incoming edge so it waits for visuals, narration, and music. The current Strands documentation explicitly calls out this Python behavior; it is not a rule to assume across every SDK.
That was a useful correction to my mental model. Drawing a dependency is cheap. Understanding exactly when the scheduler will execute it takes reading the contract.
We also kept deterministic work in the graph. Kokoro generates the voice recordings, timing uses their measured lengths, and Revideo plus ffmpeg produce the finished file. Those steps don't need a language model to decide how many seconds an audio file lasts. They need reliable inputs and visible failures. A graph node is a unit of work; it doesn't have to be another agent with an impressive job title.
Lesson three: define failure before adding another retry
Our critic starts with code: duration, narration fit, text limits, image validity, and coverage metadata. Only after those checks pass does an agent review the story. A broken file path doesn't deserve a literary opinion.
The production graph allows one repair pass. Changed narration gets voiced again, timing is recalculated, and hard checks run again. If those still fail, production stops with a report. That is a deliberate boundary. An open-ended repair conversation would make it harder to predict whether a run is progressing or merely spending.
There are limits to what we built. Coverage metadata says a scene claims to cover a point; it cannot prove the sentence communicates it well. And the repair path currently repeats the hard checks without repeating the editorial review. A structurally valid result can still be dull, misleading, or awkward. I want those limitations visible when deciding what to improve next.
The lesson I would take into another project is to write down the stop condition early. Keep the rejected artifacts. Make the failure useful to the next person or the next attempt. A failed run that explains itself is something you can work with.
Why I think agent harnesses are the next big thing
My bet is that more of the practical difference between agent products will come from their harnesses: what they remember, which actions they permit, how they recover, and what evidence they leave. Better models still matter. But a better writer doesn't automatically give you resumable work, correct dependency handling, or approval of the exact artifact that will be used.
I would be suspicious of turning this into another mandatory framework. A short task may need a function, a schema, and a check. Our video workflow justified a graph because there was real parallel work and conditional routing. The architecture earned its place through those requirements.
For the implementation, I've written a separate technical walkthrough of the two graphs and the surrounding service. For your own agent, start with one exercise: interrupt a run halfway through, then ask it to continue. Look at what it repeats, what it loses, and what it can explain. Put the next engineering hour there.