AI Engineer: Build a Video Description & Script Pipeline (Buzz/Goose, Cost-Optimized)

I'm building an automated content pipeline for a video commentary podcast and a short-form social channel. The premise: videos, links, and images go in — an AI describes what's in them in obsessive visual detail — and that description becomes the raw material for both long-form episodes and vertical shorts. HARD REQUIREMENT: the entire system must be fully operable by keyboard and screen reader. No step may require mouse interaction or visual inspection of a screen. Treat this as a functional spec, not a preference — a build that "mostly works" this way doesn't pass. Where a step genuinely requires visual verification, it must be isolated and routed to a defined spot-check task, not left in the main workflow. I am cost- and token-sensitive. I will hire whoever designs the cheapest system that still works, not the most impressive one. THE PIPELINE STAGE 0 — INTAKE One accessible entry point accepting an uploaded video file, a URL (YouTube, TikTok, Instagram), or an image or batch of images. Intake works by dropping files in a watched folder AND by pasting a link into a chat channel. No web forms requiring mouse clicks. STAGE 1 — TREND RESEARCH AGENT (optional per run) An agent that finds what's currently trending in music video, streetwear, and celebrity fashion, ranks candidates, and returns a numbered digest so I can reply "do 2 and 5." Sources: YouTube Data API (free tier), TikTok Creative Center, plus the Mobilerun path below. STAGE 2 — DESCRIPTION ENGINE (THE CORE OF THIS JOB) Extract frames from each video and produce the most detailed possible description of everything visible. Requirements: — Scene-aware frame sampling, not literal every-frame. A 3-minute video at 30fps is 5,400 frames; describing all of them wastes money and produces near-identical repeated text. Sample on scene changes plus a fixed interval, with a "dense mode" flag for key moments. State your sampling strategy and its cost in your proposal. — Use a cheap vision model. Gemini Flash-class is the assumed default for the bulk pass. If you know a cheaper route that holds quality, propose it with numbers. — Description rubric. This is the product. Output specifics, not vibes: • Garments: type, cut, fit, color, fabric, logos, graphics, visible text • Brand identification wherever possible (label, silhouette, colorway) • Jewelry in detail: chain style (Cuban, rope, figaro, tennis, franco), metal color, thickness, pendant/charm description, watch make if identifiable, grillz, rings • Footwear: model name if identifiable, colorway, condition • Hair, tattoos, accessories, eyewear, headwear • Setting, vehicles, props, background people • On-screen text, captions, logos, watermarks • Camera and edit style: angle, movement, cuts, effects, color grade — Confidence tagging is mandatory. Anything uncertain must be marked as such ("looks like a Cuban link, low confidence"). This material is read aloud on air. A hallucinated brand name stated as fact is a failure condition. — Cross-frame consolidation. The document must not repeat the same outfit description 40 times. One "who and what is in this video" section, then a timestamped timeline of what changes. — Every line of output carries an absolute timestamp from the source video timeline, not offset-from-clip-start. Non-negotiable. STAGE 2.5 — TIMESTAMPED RUN SHEET (three files per video) The description document alone isn't usable during a live recording. The engine must also produce a working game plan. Three files: FILE A — Full description document. Everything from Stage 2, timestamped throughout. FILE B — Run sheet for the on-air talent. A ranked list of the moments most worth stopping on, each with: MM:SS in-point and out-point; a 5–10 word label ("chain and watch reveal"); what's on screen in one sentence; why it was flagged; and one or two suggested angles as a starting point — not a script. Flagging criteria the model scores against, and the output must state WHICH one a moment hit: • Description density — a moment loaded with specific, nameable detail. A shot with six describable items beats a shot with one. • Visual absurdity or incongruity — something that doesn't belong, is out of proportion, or is trying too hard. • Status signaling — flexing, brand stacking, obvious expense, obvious fakeness. • Contrast — setting vs. outfit, lyric vs. visual, confidence vs. execution. • Physical comedy — a face, a gesture, a stumble, someone in the background. • Repetition — something recurring that can become a running bit or callback. Ranked strongest first, with a confidence note. The model is guessing at what's funny; it doesn't need to be right. It needs to produce a shortlist with enough detail that a human can accept or kill each item in two seconds. FILE C — Producer cue sheet. A flat chronological list. Timestamp, short label, nothing else. This is what the producer scrubs to during the tape to jump straight to a moment on request. Example: 0:14 chain and watch reveal 0:31 the coat 1:02 background guy on phone 1:47 shoe close-up Every timestamp in Files B and C must be verified accurate against the source video. If the producer jumps to 1:47 and there's no shoe there, the system is dead weight during a recording. Each flagged moment also carries a clip-ready in/out point so the shorts pipeline can pull it directly. STAGE 3 — SCRIPT WRITING AGENTS Two writers reading the description document: 1. Long-form script writer — episode structure: cold open, per-video description read, riff prompts, callbacks, segment transitions. 2. Shorts writer — self-contained vertical scripts, roughly 30–60 seconds, hook in the first three seconds, one bit per short. Both write against a voice corpus I supply: style documents and transcripts. The system must actually use this corpus, not just a one-line style instruction: • The corpus lives in a folder I can add to at any time by dropping in a file. New file in, writing style updates — no code change, no redeploy. • Build a banned-phrase list from it. Anything that reads as AI-written gets rejected before it reaches me. • Scripts are graded against the corpus by a separate pass with fresh context, so the writer never grades its own work. Below the bar gets rewritten, not shipped. Scripts arrive as: one-line summary of the video, one-line summary of the angle, then numbered lines of exactly what to say. STAGE 4 — RECORD Rig already exists and I'll provide the scaffold: headworn XLR mic → Focusrite Scarlett 2i2 → foot pedal starts/stops. You wire it up, you don't design it. STAGE 5 — POST-PROCESSING Transcription (WhisperX), silence cutting, loudness normalization, stitching into vertical shorts, captions. Working scripts for most of this already exist in the scaffold. You extend and debug, not start from zero. STAGE 6 — ACCESSIBLE QC Before anything publishes: a text description of every visual element and its timing, plus the finished audio to review. Approval is a single typed or spoken word. Nothing publishes without it. STAGE 7 — PUBLISH Shorts to Instagram Reels, TikTok, YouTube Shorts (Postiz or equivalent). Podcast audio to a podcast host with an RSS feed. Scheduled, not manual. REQUIRED STACK BUZZ (by Block) is the orchestration layer and the management surface for this entire system. The agents must live in Buzz channels so the whole process is visible as text and can be interrupted or redirected by typing a message. This is a requirement, not a suggestion. Buzz is open-source, self-hostable, model-agnostic, and built on Goose. Be aware it's early-stage and pre-1.0, desktop-first, with some features unfinished. If you believe another orchestration layer is genuinely better here, you may propose it, but you must explain the tradeoff — Buzz is my default because of the text-based visibility and control it gives. MOBILERUN (formerly DroidRun) over Tailscale, driving an Android device, for anything easier to get from a real phone than an API: hashtag browsing, screenshots, saving videos from apps. Do not use raw ADB. GOOGLE GEMINI (or cheaper equivalent) for the bulk vision/description work. HEADROOM (open-source context-compression proxy) wired in from day one to cut token spend on the text side: agent conversation history, tool outputs, script drafts, transcripts. Headroom compresses text, not images, so it won't reduce the vision/frame pass — frame sampling is the lever there. I want both levers pulled. Tell me what you expect Headroom to actually save on this specific workload. I'm aware "up to 95%" is a ceiling and real-world results are often far lower. EXISTING SCAFFOLD PROVIDED BY ME: Python/Bash scripts for silence cutting, loudness normalization, stitching, trend pulls, plus skill definition files and a build spec. COST, THROUGHPUT, AND TIMELINE — REQUIRED IN YOUR PROPOSAL My ceiling for AI/API usage is $300/month and I intend to spend well under it. I will hire whoever designs the most cost-effective system that still produces accurate descriptions. Proposals that skip any of the following will not be considered: 1. RUNNING COST PER MONTH. What does it cost to operate this system — describing videos, writing scripts, processing audio, and publishing — for one month? Show your math: frames sampled × model × price per call, plus every other line item. 2. THROUGHPUT AT THREE SPEND LEVELS. Give me a table at roughly $50/month, $150/month, and $300/month. For each level tell me: • How many hours of source video can be fully described • How many finished podcast episodes that supports, and their approximate length • How many shorts that produces • What the bottleneck is at that spend level — description cost, script generation, or something else I want to understand the exchange rate: hours of content I put in versus hours of finished content I get back, per dollar. Note that description cost scales with source video length while script cost barely moves — an hour-long video costs many times more to describe than a four-minute one without yielding proportionally more usable material. Your estimate should reflect that. If $50/month gets me most of what $300 does, say so plainly. I'd rather hear that than be sold the expensive version. 3. MODEL CHOICE PER STAGE, with reasoning. Description, script writing, transcription. Mixing cheap models for bulk work and better models only where quality matters is exactly the thinking I want to see. 4. EVERY RECURRING SUBSCRIPTION OR PAID SERVICE the system requires, with monthly price. 5. COST RISK AND CAPS. Where's the biggest risk of a surprise bill, and how do you cap it — hard spend limits, per-run budgets, caching, rate limits? 6. BUILD TIMELINE. How long to deliver the $50 scope below? And if you get the full build, how long from start to a working end-to-end system? Give me calendar days, not hours worked, and tell me what could realistically slip. BUDGET: $50 FIXED PRICE FOR THIS JOB This posting is a $50 fixed-price job. It is deliberately small — a real, paid trial and the gateway to the rest of the build. What the $50 covers — deliver exactly this: 1. Buzz installed and running, with a written report on screen-reader operability: what's usable, what isn't. 2. Headroom installed in front of the agents, with before/after token numbers on at least one run. 3. A working Stage 2 + 2.5 description engine: given one video URL, return three plain text files in a designated folder — the full confidence-tagged description document, the ranked run sheet with in/out points, and the producer cue sheet. Timestamps verified accurate. 4. A one-page cost model: what one video costs to describe, and projected monthly spend with the throughput table described above. That's it. One video, end to end. Don't build the rest yet. The rest of the build goes to whoever delivers this well. Quote your own price per milestone in your proposal so I know what I'm walking into, but you're being hired and paid for the $50 scope first, and broader system access isn't granted until it's delivered. • M2 — Trend agent plus both script writers, running as agents inside Buzz • M3 — Recording rig, post-processing, shorts assembly, accessible QC report • M4 — Publishing (Postiz plus podcast RSS), Mobilerun integration, and a two-week live test with same-day bug fixes Payment is per milestone, agreed in writing before work starts. I won't accept a single lump-sum "everything fixed" arrangement. SCREENING QUESTIONS — answer directly, no template cover letters 1. Have you built software that had to be fully operable by screen reader? If not, what's your concrete plan for verifying it works by keyboard and voice, rather than "should work in theory"? 2. Have you used Buzz or Goose? If not, how long do you need to get productive with them, and does that time come out of my budget or yours? 3. Give me your frame-sampling strategy for Stage 2 in your own words, and your cost estimate for describing one 3-minute music video. 4. What's your plan if the vision model confidently misidentifies a brand? How does the system surface that before the content goes on air? 5. How will you guarantee the timestamps in the run sheet and cue sheet are accurate to the source video? They get used live during a recording. 6. Have you used Headroom or another context-compression layer? What reduction do you realistically expect on this workload, and where will it help least? 7. Have you worked with Mobilerun/DroidRun or similar phone-automation tooling over Tailscale? 8. How fast can you deliver the $50 scope, and how fast could you deliver the full build? NOTES • This job includes remote access to a workstation during setup. Serious applicants only. • The build spec and code scaffold go to shortlisted candidates. • Content is commentary on public videos. Keep publishing compliant: platform AI-disclosure toggles on where applicable, no wholesale reuploads of others' footage.