An agent cuts my talks

TL;DR

• I no longer cut my YouTube talks alone. I cut them together with an agent in the terminal.
• The loop: raw clip, word-exact transcript, a cut proposal as an edit decision list, my approval, a frame-exact render, an eval, then upload.
• The agent proposes every keep and cut span on its own, but approval stays with me. Mechanically, it can never wave itself through.
• Everything runs one hundred percent locally. The language model never sees the cloud.
• Already running on the real "Vibecode together" series on my YouTube channel, not a demo.

The pain: editing eats the time that should go into building

When I record a talk, or capture a vibecode session live, I end up with a raw clip that often runs past an hour. Turning that into a publishable YouTube video means someone has to cut out every pause, remove every stumble, and set a clean start and end. That work was exactly what kept pulling me away from the reason I recorded in the first place: building.

Editing in a classic tool is frame-by-frame work. You scrub through a waveform, mark in and out points, watch the same stretch three or four times before you trust your own call. For a one-hour raw clip that easily adds up to two or three hours of pure sitting-and-watching, and none of it has anything to do with the actual thing I want to show. I build agents that take mechanical work off other people's hands. It felt off to insist on the mechanical version for my own content and never hand it off myself.

So I asked the same question I ask about any recurring step in my work: what part of this is judgment, and what part is pure execution? The answer was clean. Spotting where a pause starts and ends is pattern matching on a transcript, something a machine can do exhaustively and without getting tired. Deciding whether a take stays in as a whole, whether a thought carries or falls flat without it, is a judgment call, and that call is mine because I own the result. That is exactly the line AgenticCutter draws.

The loop: from transcript to upload

The pipeline is a closed loop with six stations, and each one has a clear job.

It starts with the unedited clip. The agent runs it through mlx-whisper and gets back a word-exact transcript, every spoken word with a timestamp. That gives it a text map of the entire recording, searchable and machine-readable, long before a single frame gets cut.

Based on that transcript, the agent proposes a cut decision: an edit decision list, or EDL for short. That is not a finished video file, it is a structured list of time ranges each marked keep or cut. Long pauses, broken-off sentences, two takes at the same thought, the agent proposes all of that for removal. Whatever actually carries the point gets proposed to stay. It makes these calls on its own, across the full length of the clip, without me nudging it through section by section.

That EDL lands on my desk, line by line. I read every proposed cut against the transcript and decide: keep it as proposed, or overrule it. Only once I approve does the pipeline move to the next step.

After approval, the agent renders frame-exact. The cut points sit exactly on the frame boundaries the EDL specifies, no manual nudging afterward, no touching the timeline once it is set.

Then comes a step a classic editor does not have at all: the eval. The render runs against a set of fixtures committed to the repo, and precision and recall of the cut get measured against them. Only once the eval passes does the render count as accepted, not the moment it finishes rendering.

At the end sits the upload to YouTube. That is the only step where anything actually leaves the machine toward an outside platform. Everything before it, transcript, cut proposal, render, eval, happens on my own hardware.

Why the approval gate is a feature

The agent proposes every keep and cut span. It does that on its own, without me triggering each section individually. But it can never mechanically approve itself. Approval is its own step in the chain, not a checkbox the agent ticks along the way.

This is not a safety rule I bolted on afterward because I do not trust the model. It is a deliberate design decision, for the same reason BuilderBob always escalates to me on money, legal questions, and complaints: some decisions belong to a human, not because the machine would make them badly, but because the responsibility for them cannot be delegated. If a take ends up in a video where I say something to an audience, that is on me. Not on the agent.

In practice that means I read every EDL in full before the render starts. Sometimes I overrule a line because a pause actually mattered content-wise, a deliberate beat rather than a mistake. The agent cannot always tell that apart from the transcript alone. I can, because I was there when it was recorded. That extra step is what turns an automated loop into a workflow I actually trust: the agent does the exhaustive groundwork, and I make the call that needs judgment.

One hundred percent local: the model never sees the cloud

The entire pipeline runs locally on my machine. Transcription through mlx-whisper, the cut decision, the render through ffmpeg, the eval: none of it leaves my hardware toward an outside server.

Technically this is enforced by an egress guard I call --zero-cloud internally. It blocks every outbound network call during processing. The language model making the cut decisions never sees the cloud at any point. It only ever works with what already sits on the machine: the raw clip, the transcript, the eval fixtures.

The reason is not primarily privacy, although that is a welcome side effect when a raw clip contains unpublished thoughts or the names of people who have not agreed to appear publicly yet. The main reason is control over the attack surface. If a step in the chain cannot open a network connection, I do not have to think about that step at all when I reason about data leaving the system or external dependencies creeping in. A process that stays local cannot accidentally send anything outward, because it simply has no path to do so.

That is the same instinct I follow elsewhere across my agent fleet: keep as much processing as possible somewhere I can watch directly and shut off on the spot if I need to. For a video-cutting process that works with my own voice and my own face, that instinct matters more here than for most other agents in the fleet.

The proof: the "Vibecode together" series runs on this

This is not a tool I built once and then left in a drawer. Every episode of my YouTube series "Vibecode together" now runs through exactly this loop: raw clip in, transcript, cut proposal, my approval, render, eval, upload.

That is the difference between a proof of concept and a tool I actually use. A demo video that works once on a stage tells you little about whether a system holds up day to day. What matters is whether I still reach for it week after week without re-litigating whether it is worth the trouble every single time.

For "Vibecode together" it is worth it, because I know the alternative firsthand: I used to cut manually, and I know exactly how many hours of pure sitting-and-watching that cost per episode. The time I get back now goes straight into what the series is actually about: building together with agents, instead of sitting at an edit timeline afterward and redrawing the result frame by frame.

What is next: Cutter and FeedFoundry stay two separate stages

AgenticCutter is not an island for me. It is one of two content stages in my agent fleet, alongside FeedFoundry, which renders short-form content for Instagram from source material. The two are deliberately not wired together today. That is not a gap I overlooked, it is a decision: I will build the connection once real usage data shows me it makes a measurable difference, not because linking two systems that already work well on their own feels elegant.

For now it is enough that both stages hold up on their own. Cutter takes the cutting work off my hands, with me as the approval step at the point that matters. FeedFoundry renders short-form content by fixed rules. How the two eventually connect is something I will document once it actually happens, not announce ahead of time.

If you want to see how this stage fits into the wider agent fleet, where Sven, BuilderBob, and the other tools sit, I wrote that up in its own article: Building an agent fleet. And if you want to start building with AI agents yourself instead of just talking about it: there is a free handout and a newsletter at agenticbuilders.at. No pitch, just a starting point for everyone who ticks the same way.