Part 2 of three articles on building my video factory. The first part follows the CDP pilot, the local voice workflow and the visual direction. This part is about how the work moved between Codex, Claude Cowork and me.
On 8 September, Claude reviewed the three final video masters that Codex had produced for the CDP, DMP and CEP articles, all three of which are now public on my YouTube channel alongside the later episodes. The review measured the delivered files independently: it decoded every frame, counted them against the storyboards, measured loudness, sampled every scene transition at its midpoint and confirmed that the approved audio had been carried across without re-encoding. All three passed. It also found a label overflowing its box in the DMP video, and gaps in the records describing how the files had reached their final state.
That combination is a fair picture of how this project worked. A second review produced evidence I could use and found things worth changing, while every decision about those changes stayed with me, and no amount of agreement between two systems could substitute for watching the result.
Using two AI collaborators paid off only when the second one had something it could check independently. The shared folder, the review reports and the limits around each task did most of the work that a phrase like “multi-agent collaboration” tends to leave unexplained.
Three contributors working on one video production
I had already used Claude Cowork for this site and for the Braze demo work, and Codex had joined my workflow as a second building partner. On the video factory those two relationships settled into a practical division of work around a common project.
Codex did most of the production implementation: writing and revising scene code, connecting the narration to the timeline, running the renders and producing the final masters with their verification reports. Claude Cowork contributed reviews, corrections to the operating process, reusable instructions and the work that connected the finished videos to YouTube and to this site. I chose the direction, recorded the voice reference, challenged the results and decided what was ready to move forward.
The responsibilities overlapped more than that summary suggests, because both collaborators wrote code and both ran checks. A Claude session that reviewed transition problems also wrote a checker for them, and a Codex session that implemented a correction also verified the file it delivered.
I was also the one carrying work between them. I would bring a review back into the implementation session, or ask another session to inspect the current files, and the production never depended on pretending that two separate chat histories added up to a shared memory. For a decision to survive the session in which I made it, it had to be written down somewhere the next session would read.
The job folder that carried each handoff
Each video had its own job folder holding the source article, the creative brief, the script, the storyboard, the audio and the review evidence. A manifest recorded the production state and pointed at the current files, and an approval log recorded the decisions that allowed each stage to go ahead. The factory has no version control of its own, so between them those two files were the history of the job.
Their purpose was to make the current production legible. Someone resuming the DMP video needed to know which narration was approved, which review file had been superseded, what the latest feedback asked for and whether another full render had been authorised, and without those answers the folder offered several plausible versions of each one.
The source snapshot dealt with a different ambiguity. Articles keep evolving on the site while a video is in production, and keeping the exact text a job was adapted from meant we could see what the script came from, instead of assuming the live article still matched the version used weeks earlier.
At the project level, shared instructions held the decisions that applied to every video: the voice profile to reuse, the visual kit to start from, where the production code lived and which checks to run before asking for an expensive render. I keep written context for the wider site operation for the same reasons, but the video work tested those documents much faster. When the next collaborator could not identify the approved audio, the weakness was audible.
Files alone did not guarantee a correct handoff, and the September review found records that had fallen behind the work. A manifest is useful because it can make state explicit, and its existence proves nothing about whether that state is accurate.
When a second review changed the implementation
The transition problem is the clearest case of a review improving more than one file.
Several CDP scenes changed state by fading one complete diagram out while the next complete diagram faded in. Halfway through, both could be readable in the same region of the screen. Each settled state looked fine, but the movement between them briefly showed an architecture that the narration was not describing, and the final review of the CDP master on 13 August held it back for exactly that reason, in six of its fourteen scenes.
Figure 1. The same moment of the CDP video in an August master that was held back (1) and in the published version (2). In the first, two complete architectures are readable at once while the claim names only one of them.
The defect was easy to miss if a review only sampled the settled scenes. It also explained why asking for a more animated video could make the result harder to follow, since the motion needed rules about what stayed visible and how a viewer could track each change.
Once the defect had been corrected, a Claude session went through the remaining work with me on 29 August. I wanted the next videos to need fewer review rounds and less effort, so Claude added a transition lint that flags the specific code pattern behind the failure, a raw fade-out written outside the shared handoff helper, and wrote a kickoff brief pointing every new production at those shared motion helpers and at the editorial kit built for DMP.
The lint makes a deliberately narrow claim. It can flag a risky fade pattern in the code, and it cannot prove that every transition reads clearly on screen, so the workflow still samples frames at the boundaries between states, where overlapping diagrams would actually appear. What changed is that the next session starts from an approved pattern, runs a free check and then inspects the frames that matter.
This is also why copying the most recent working components mattered more than copying the first successful video. The CDP code carried the history of the pilot, while the later kit encoded the decisions that history had forced, including several the pilot only reached through corrections.
Checking the delivered video independently
By early September we had three final masters. Codex had produced them, including a DMP correction in Scene 09 that gave a heading more room above the card beneath it. Claude’s review worked from the delivered files and treated the implementation report as a claim to test.
Some checks covered every frame of every file: a full decode looking for media errors, the frame count against each storyboard, and loudness measured on the delivered container. Others were sampled, namely one settled state per scene, all 39 transition midpoints and a set of points along the timeline. That distinction belongs in the account, because a set of extracted frames is a different thing from watching 22 minutes of video.
The most useful check tested the claim that the DMP correction was confined to Scene 09. Claude decoded 18 frames spread across the whole video from both the old and the new master and compared them pixel by pixel. The three that fell inside Scene 09 differed, and the fifteen outside it were identical. The extracted audio streams also matched the approved ones exactly. That supports the claim at the sampled positions and says nothing about the frames in between, which is how the report described it.
The review then found an unrelated problem in Scene 12. The word FORMER ran past the right edge of its box, and the origin of a connector sat on top of the overflowing letter. The frame was identical in the approved version, so the Scene 09 correction had not caused it; the defect had been there when I approved the picture. The report said that leaving it was defensible. I chose to fix it.
Figure 2. Scene 12 of the DMP video in the version I had approved (1) and after the fix (2), enlarged from the same frame of each master. Panel, connectors and timing stay where they were; only the label’s size and top margin changed.
The change itself stayed small. The label inherits Inter Variable, and measured in that font FORMER was 153.5 pixels wide at 36 pixels against a 130-pixel content box, and 119.4 pixels wide at 28. The fix reduced the size and adjusted the top margin, left the panel geometry and the connector origin exactly where they were, and was inspected in native-resolution crops before I authorised one more render. The render took three attempts, the first two stopped by the account’s usage limit and a configuration error, and completed later the same day. After it, the same 18-frame comparison against the previous final showed differences only inside Scene 12, and the audio stream was byte-identical to the approved one.
Claude also found less visible discrepancies. The render history had not been updated for the final deliveries, the DMP and CEP approval logs stopped at the voice gate even though both jobs had passed later ones, and two copied masters carried a recorded mode implying a fresh render that never happened. Codex backfilled the records with their provenance and recorded the timings it could not recover as unknown, without filling them in with convenient guesses.
The video and its production record were two separate things that could each be wrong, and having another collaborator inspect both exposed that difference before anything reached YouTube.
The decisions I still had to make
It would be easy to describe the workflow as Codex building, Claude checking and me approving at the end. The real sequence was less tidy, because several of my decisions changed what we were building.
I rejected the first complete visual direction and its more tightly timed successor. Both files played, and their diagrams still did not explain the material well enough. I approved the warehouse proof that set a more meaningful visual approach, and I required every label to stay inside its symbol. Those choices defined the product more directly than any final acceptance would have.
The voice called for a similarly mixed judgment. I could recognise the cloned voice and decide whether its delivery was acceptable, and a transcript check could flag phrases that had probably gone missing. Neither result answered the other’s question, so the process kept both.
Later I had to decide whether a discovered issue justified another render. The overflowing DMP label did. A legacy difference in claim capitalisation, where CDP used sentence case and the later videos used uppercase, did not justify reopening a finished production, so we froze CDP as the one documented exception and recorded uppercase as the standard for every video that followed. The choice was about what a correction was worth in context.
The practical burden stayed with me. I had to read each review, understand what its checks actually covered, watch or listen to the relevant file and keep the explanation faithful to my argument. Two collaborators increased what we could get done, and they also produced more material that arrived looking finished before I had formed a judgment about it.
In The Year the Editor Came Back I wrote about the intensity of reviewing work produced at that speed, and the video factory made the point very concrete: an approved voice, an approved visual direction and a technically valid master were three separate decisions, even when they concerned the same seven-minute file.
How each correction made the next handoff easier
The most useful habit we developed was making each session leave a better starting point for the next one. A failed voice experiment left an approved replacement profile and a completeness check. A confusing transition left shared helpers and a lint. The overflowing label left a text-fit check in the shared kit, which measures rendered text against its box with the real fonts loaded and stops the render when a label escapes, and which fails on the original 36-pixel version and passes the corrected one.
Figure 3. Three corrections and what each one left behind for the next production.
We also learned to consolidate feedback. DMP needed three replacement review videos in August for positioning fixes, and each round meant rebuilding the context, applying a correction and repeating the checks. One complete review of the video, gathered before anything changed, made a far better implementation task than finding one spacing problem after another across separate sessions, and the kickoff brief now asks for exactly that, one pass per gate.
I recognise the same pattern from delivery work with human teams. Whoever receives a handoff needs the decision, the evidence behind it and the limits of what they are allowed to change, and a long history only helps if they can tell its current instructions apart from the superseded ones.
The project also gave me a concrete extension to the silent failures I described in Agents in Production. A second reviewer can catch an error, and the bigger improvement comes when the review changes how the next error will be detected, because otherwise the operation depends on somebody remembering to notice it again.
The 8 September review earned its place because it ended with corrections we could specify and verify, including corrections to our own account of what had happened. The handoff worked when the next collaborator could check the work without having to trust the previous collaborator’s confidence.
Next in this set of three: From Article to YouTube: Making the Process Repeatable, on turning the pilot into a production routine and a publishing step, from captions and chapters to thumbnails and the upload itself. Until then, every finished episode is on my YouTube channel.
Sources
Published context
- Andrea Veggiani, From Blog Post to Video: Building My Video Factory. Part 1 of this set, covering the CDP pilot, the voice workflow and the visual direction.
- Andrea Veggiani, The Year the Editor Came Back. The earlier account of moving from chat assistance to building with AI collaborators.
- Andrea Veggiani, From Personal Site to Sales Tool: Building a Working Braze Demo with Claude Cowork, Part 2. The prior build story referenced here.
- Andrea Veggiani, Agents in Production: What the Demos Leave Out. The written-context and shared-state practices applied to this project.
- Andrea Veggiani, Agents in Production: How Agentic Systems Fail Silently. The related account of failures that pass superficial checks.
The production episodes in this article are reconstructed from my project files, saved review reports and recorded decisions. The independent master review described here combined full-file technical checks with sampled visual inspection; it was not a continuous viewing of all three videos. The figures are frames extracted from the actual renders, without re-rendering anything.
