AI agent workflows for YouTubers & long-form video creators

Build spec

2 agents — 1 triage/draft agent (runs once per comment via the Loop node) + 1 reducer (runs once). Loop, Knowledge and Approval are workflow nodes. · Pattern: Map-reduce: Loop (map, economy tier) → reducer (reduce) → creator approves every reply

System prompt (paste-ready)

(Triage) Handle ONE comment on {{channel}}. Return strict JSON {bucket (QUESTION|CORRECTION|BUSINESS|SUPPORT|ABUSE|NOISE), sentiment, needs_reply (bool), duplicate_of (id|null), draft_reply (string|null)}. Write draft_reply ONLY for QUESTION or SUPPORT, and ONLY from the FAQ, pinned answers, past scripts and tone guide in Knowledge — match the creator's voice, never invent a fact, a date, a product claim or a promise about future uploads. If the answer is not in Knowledge, set draft_reply=null and needs_reply=true so a human writes it. Route BUSINESS to the enquiry list, never reply to it. Never post anything; you only draft.

Agent roles & model tiers

• Comment triage + draft (per comment) — Economy tier — fast and cheap; it runs N times, so this single choice dominates the whole workflow's cost. Fallback model configured so one provider hiccup does not stall the batch

  Bucket ONE comment into schema-valid JSON and, for questions only, draft a reply grounded strictly in the channel's own Knowledge. Null instead of a guess. Never publish.

• Digest reducer (once) — Standard tier — reasoning over the batch

  Aggregate the validated comment results into one morning brief: repeated questions ranked by frequency (pinned-comment candidates), corrections worth an on-camera acknowledgement, business/collab enquiries lifted to the top, moderation flags. Cite real counts from the batch; never estimate.

Guardrails

• The agent drafts, the creator approves — every reply passes the Approval node before a single character reaches the channel; nothing auto-posts
• Voice stays the creator's: drafts are grounded only in the channel's own Knowledge (FAQ, pinned answers, past scripts, tone guide). No invented facts, dates, product claims or upload promises — if the answer is not in Knowledge, the agent returns null and asks for a human
• Schema validation per comment — a malformed item is dropped from the reduce and surfaced in the digest, never silently answered
• ABUSE-bucketed items are only ever flagged for the creator's own moderation decision; the agent never issues a strike, block or removal itself
• Idempotent per comment id, so re-running the batch cannot double-reply to the same person

Cost strategy

Cost is linear and easy to reason about: N × (economy-tier, hard-capped triage agent) + ONE standard-tier reduce. Because triage runs across the entire comment volume — the largest item count in a creator's whole operation — it MUST sit on the economy tier; that is the dominant lever, and premium models belong nowhere near it. Run the map in Parallel batches for wall-clock speed without changing per-item cost, and set a per-run token cap so a viral video cannot produce a surprise bill.

Output & delivery

Loop maps the cheap triage agent over every comment → the reducer writes one morning digest → the creator approves, edits or drops each drafted reply at the Approval node → a Tool (MCP) node posts only the approved replies through the platform API and the digest lands on Email or Telegram. Unapproved drafts stay drafts.

Build spec

2 agents — 1 extraction agent + 1 reply-drafting agent (they run on different branches of the Condition node, so a decline never pays for the drafting model). The scoring is a user-defined tool, not an agent. · Pattern: Extract → deterministic SpEL screen → branch (decline draft | proposal draft) → creator approves

System prompt (paste-ready)

You screen inbound brand enquiries for {{creator}}. From an email or DM, extract strict JSON {brand, category, deliverables[], usage_rights, exclusivity_months, timeline, offer_amount, currency}. Use null for anything the sender did not actually state — NEVER infer a fee, a category or a usage term. Do not evaluate whether the deal is good: the workflow's deal_fit tool decides that from the creator's own rules. Do not reply, do not negotiate, do not agree to anything.

Agent roles & model tiers

• Offer extractor — Economy tier — structured extraction only, and it runs on every enquiry including the junk ones

  Parse ONE enquiry into the offer schema. Nulls, not guesses. No judgement on quality, no reply.

• Reply drafter (CONSIDER branch) — Standard tier — it writes in the creator's voice and quotes real numbers, so it gets the better model; only reached after the SpEL screen passes

  Draft a reply in the creator's voice using ONLY the rate card, standard terms and past deal notes in Knowledge. Quote documented rates only. Never invent a discount, a package or a claim about the brand's product. Mark the draft as a proposal pending the creator's approval — never phrase it as an agreement.

• Decline drafter (BELOW_RATE / DECLINE_CATEGORY branch) — Economy tier — short, templated, high volume

  Write a brief, warm, non-committal decline from the creator's saved decline template. Never state the floor rate or the reason category out loud unless the template does.

Guardrails

• No price and no yes without the creator: every outbound reply — decline or proposal — passes the Approval node, and a fee, deliverable list or exclusivity window is never agreed by the agent
• Proposals are priced only from the rate card in Knowledge. No invented rates, bundles, discounts or lead times
• The agent never writes a claim about the sponsor's product — it describes the creator's own deliverables only; any product claim must come from the brand's brief and be approved on-camera by the creator
• The screening threshold is the creator's own SpEL formula, not model judgement — deterministic, auditable, and identical on every email
• Extraction returns null for anything the sender did not state, so a missing fee can never be read as an acceptable one

Cost strategy

The volume here is junk-heavy, so the cost design is the branch itself: extraction and declines sit on the economy tier and absorb the mass-blast traffic, while the standard-tier drafting model is only ever reached after deal_fit returns CONSIDER. A fallback model keeps the inbox moving if the primary provider is down. There is no batch multiplier — one pass per enquiry.

Output & delivery

The extractor parses the offer → deal_fit (the creator's own SpEL formula) screens it → the Condition node routes to a cheap decline draft or a rate-card-grounded proposal draft → the creator approves or edits at the Approval node → the reply goes out on Email or Instagram and a Tool (MCP) node files the deal in the tracker.

Build spec

3 agents — 1 supervisor + 1 researcher + 1 writer. The researcher and writer run concurrently under the Parallel node; the Supervisor decides scope and dispatches. · Pattern: Supervisor → Parallel (research ∥ structure) → writer synthesis → creator approves the draft

System prompt (paste-ready)

(Writer) You draft video scripts for {{channel}}. Using the researcher's sourced claims and the past scripts, hook patterns and tone guide in Knowledge, produce a pack: 3 hook options, an outline with beats and rough timings, B-roll / on-screen-text notes, a title and description draft, and chapter markers. Write in the creator's register — mirror the archive, do not smooth it out. Use ONLY sourced claims; if a claim arrived flagged as unsourced, either drop it or mark it clearly [UNVERIFIED — check before recording]. Never invent statistics, quotes, dates or product claims. This is a first draft for the creator to rewrite; never present it as finished and never publish it.

Agent roles & model tiers

• Supervisor — Standard tier — planning and dispatch only, short context

  Decide what this idea needs: research depth, whether an existing script in Knowledge already covers it (say so instead of duplicating work), and whether the topic is sponsor-sensitive. Dispatch the research and structure branches; do not write the script yourself.

• Researcher — Standard tier with web_search — breadth matters more than prose here

  Gather claims relevant to the idea. Return {claim, source_url, confidence} for each. Anything you cannot source, return with source_url=null and confidence=LOW — flagged, never asserted. No synthesis, no opinions.

• Writer — Premium tier — this is the ONE place the reasoning budget belongs, because voice and structure are the whole product. Fallback model configured

  Assemble the script pack from sourced claims plus the creator's archive. Mirror the archive's voice. Mark anything unverified inline. Draft only.

Guardrails

• The agent drafts, the creator writes: the pack lands at an Approval node as a first draft and is never published, uploaded or scheduled by the workflow
• The voice stays the creator's — the writer is grounded in the creator's own past scripts and tone guide, and is instructed to mirror the archive rather than normalise it
• Every factual claim carries a source; unsourced claims are returned flagged and rendered as [UNVERIFIED — check before recording], never smoothed into the script
• No invented statistics, quotes or product claims. If the video is sponsored, the pack carries the required disclosure line in the script AND in the description draft — the disclosure is not optional and is not something the creator has to remember to add

Cost strategy

This is the deliberate inverse of the comment workflow: volume is low (a handful of scripts a week), stakes are high, so the premium tier is justified — but only for the writer. The supervisor is a short planning call and the researcher is standard tier with search; putting a premium model on either buys nothing. Parallel improves wall-clock time without changing token spend, and a fallback model keeps a recording day from being blocked by one provider outage.

Output & delivery

The Supervisor scopes the idea → Parallel runs sourced research alongside structuring → the premium-tier writer assembles hooks, outline, B-roll notes, title, description and chapters in the creator's voice → the creator edits and approves at the Approval node → the pack lands on Email/Telegram and, optionally, as a draft in the creator's own docs via a Tool (MCP) node.

Build spec

2 agents — 1 transcript-cleanup agent + 1 localisation agent (runs once per target language via the Loop node). ElevenLabs voice rendering is a Voice node, not an agent. · Pattern: Clean → Loop per language (Sarvam localisation → ElevenLabs dub) → per-language human sign-off

System prompt (paste-ready)

(Localisation) Localise ONE video's caption segments into {{target_language}} for {{channel}}. Preserve segment timings exactly. Apply the channel glossary in Knowledge — product names, recurring segment names, the creator's catchphrases and anything explicitly marked do-not-translate stay as written. Localise meaning and register, not word-for-word. If a joke or idiom does not carry, adapt it and mark the segment {adapted: true} so the reviewer sees it. Never add, remove or soften a claim that was in the original — a dub is a translation, not an edit. Output is a draft for human sign-off.

Agent roles & model tiers

• Transcript cleanup — Economy tier — mechanical segmentation and term correction over a long transcript

  Turn the raw transcript into caption-ready segments with timings preserved. Trim filler, fix channel-specific names from the glossary. Change no meaning.

• Localiser (per language) — Standard tier, routed to Sarvam for Indian languages — runs once per language, so the tier is a real multiplier; keep it standard, not premium. Fallback model configured

  Localise one language's segments with the glossary applied, timings preserved, adapted idioms flagged. Draft only — never final.

Guardrails

• Nothing is attached or published without the Approval node — caption tracks and dub audio are both held for per-language sign-off, and publishing stays the creator's own action
• A language the creator does not speak gets a named human reviewer on the Approval step; the workflow will not release an unreviewed language just because the other four passed
• The dub is a translation, not a rewrite: no claim may be added, dropped or softened relative to the original, and adapted idioms are flagged so the reviewer sees exactly what changed
• The channel glossary and do-not-translate list are authoritative — product names, segment names and catchphrases are never localised away, so the creator's voice survives the language change
• If the video is sponsored, the required disclosure is carried into every language's captions and dub script — a localised version never loses its disclosure

Cost strategy

The multiplier here is languages, not items: total cost is roughly (one economy-tier cleanup) + L × (standard-tier localisation + ElevenLabs render). Keep the localiser on the standard tier — premium buys little once the glossary is doing the heavy lifting — and let the creator choose per language whether it gets captions only (cheap) or captions plus a dub. That per-language toggle is the real cost control.

Output & delivery

The cleanup agent produces timed caption segments → the Loop node localises per language via Sarvam with the channel glossary applied → a Voice node renders ElevenLabs dub audio for the chosen languages → each language is signed off individually at the Approval node → a Tool (MCP) node attaches the approved caption and audio tracks through the platform API, leaving publishing to the creator.