At 11:40 PM I asked my AI what was on my YouTube calendar for August.
It told me I had eight videos scheduled to publish at the exact same timestamp on the same dates. Two Shorts, one slot. Eight times over.
It also told me the fix, proposed the moves, and waited for my confirmation before touching anything.
I didn't open YouTube Studio once.
That's the short version of what RFD_YT_Engine is. The longer version starts about two months earlier, when I was running a pipeline called ContentEngine that was supposed to generate YouTube Shorts from AI-written game reviews. It had nine stages, a script generator, a brief generator, a voice synthesis layer, and a Pollinations.ai fallback for when nothing else produced a usable image. It was elaborate.
It also produced videos nobody watched, including me.
The pivot was simple: stop scripting. Use real gameplay footage. Film what actually happens when you play a game for the first time, cut out the moment that made you react, and put it online. No narration. No brief. No AI-written hook. Just the moment.
The pipeline that came with ContentEngine didn't fit that model. So I built a new one from scratch.
What RFD_YT_Engine actually is
An 8-domain Python system that manages the full lifecycle of a YouTube channel — from raw session recording through to published video — with a 24-tool MCP server that exposes the entire thing to Claude Desktop.
The eight domains:
- Capture — OBS integration, session monitoring, game detection
- Ingest — Whisper transcription, beat extraction, session tagging
- Production — Shorts assembly via FFmpeg, Highlights assembly with bridge TTS, beat-to-clip mapping
- Distribution — YouTube Data API v3 uploads, metadata resolution, scheduled publishing
- Catalog — Full channel mirror in local SQLite, 167 videos with all 11 detail columns hydrated
- Scheduling — Calendar management, collision detection, round-robin reweave
- Streaming — OBS WebSocket control, stream session management
- Interface — The MCP server. The only domain allowed to call across domain boundaries.
The architecture rule that held through every phase: one-directional dependency. No domain imports another's modules. Everything flows through shared infrastructure or the Interface layer. Eleven phases of development, zero ADR violations.
The YouTube API surface
I built the full YouTube Data API v3 and Analytics API v2 surface from scratch because the existing libraries were either too thin or too opinionated about what you could do with them.
What that means concretely:
The first sync attempt using search().list() returned 64 videos. The correct number was 167. The difference: search only returns public videos. Private, scheduled, and unlisted are invisible to it. Switching to the uploads playlist fixed it. 167 videos, all detail columns hydrated, in 4 API calls.
update_video_metadata() had a silent data corruption bug. YouTube replaces the entire snippet object on update. Sending only the fields you want to change wipes the rest — tags gone, category reset. The fix: fetch the current snippet first, merge the changes, send the complete object.
Traffic sources and audience retention are now queryable from conversation. How viewers found each video. Where they stopped watching. Direct tool calls, no dashboard.
Collision detection
The channel has 89 videos scheduled for future publication. The same-timestamp conflicts weren't obvious in YouTube Studio — it shows dates, not exact times, and two videos at 2026-08-29T02:00:00Z look identical until one of them fails to publish.
Two detection functions:
detect_collisions() finds same-game streaks exceeding a threshold across consecutive days. The Hotline Miami run that stretched six days without interruption — that's the target. The fix was interweaving 8 displaced Shorts into the streak window while filling the empty September calendar.
detect_same_day_collisions() classifies each date with multiple videos as either true_conflict (same exact timestamp, real problem) or multi_slot (different times, intentional). A Short at 2AM and a long-form session at 10PM on the same Sunday is the correct pattern. Two Shorts both at 2AM is a conflict. The function names the videos in both directions, and flags the content type — short, highlights, or long_form — derived from duration and title signal.
The eight true conflicts were resolved with one apply_batch_reschedule call after reviewing the preview. Ten video dates changed. No YouTube Studio.
What it took
190+ certified tests. Phase-gated development with verified floors — no phase starts until the previous one passes at exactly the stated count. Every architectural decision locked in an ADR. The Director → Pipeline → Agent methodology throughout: I wrote the directives, the agent implemented, I verified against raw pytest output. No agent summary counts as proof.
The most expensive bugs were the ones that looked like success. 64 videos that were actually 167. A metadata update that silently wiped tags. A calendar that showed empty because scheduled_at was never being written even though the API returned the data. Each one found by querying what the system actually knew versus what it should have known.
The outcome
167 videos in a local SQLite database. All detail columns hydrated. All scheduled dates correct. Collision detection live. Calendar management, metadata updates, batch reschedules — from conversation.
The infrastructure layer for a channel that produces 1–2 Shorts per day and a long-form session every Sunday. Everything above the infrastructure — recording, playing, picking the moment — is still manual. That's the part that should be.
Stack: Python · SQLite · YouTube Data API v3 · YouTube Analytics API v2 · FFmpeg · OBS WebSocket · MCP
Methodology: Spec-Driven Development · Director → Pipeline → Agent · phase-gated test floors · ADR-documented decisions
Top comments (0)