Multi-Agent-Pipeline: Wie 15 KI-Agenten YouTube-Videos bauen

TL;DR — Was du nach diesem Artikel weißt

• Was eine Multi-Agent-Pipeline ist und warum sie ein einzelner Monolith-LLM-Call nicht ersetzt.
• Welche 15 spezialisierten Agenten in der christianohle-Pipeline zusammenarbeiten — Topic-Ranker, Script-Generator, Visual-Orchestrator und 12 weitere.
• Wie der Daily-Run als Agent-Choreografie abläuft — 6+1 Stages, von News-Scrape bis YouTube-Upload.
• Welche Architektur-Entscheidungen dahinter stecken — parallel vs. seriell, GPU vs. API, Cache vs. Re-Render.
• Was diese Multi-Agent-Architektur wirklich kostet — pro Video, pro Run, pro Monat.

Ein YouTube-Video automatisch zu produzieren, klingt nach einem Skript und einem Sprachmodell. In der Realität sind es 15 spezialisierte KI-Agenten, die orchestriert zusammenarbeiten — vom News-Scraper-Agent, der morgens 60 Schlagzeilen einsammelt, bis zum Upload-Agent, der das fertige Video privat auf YouTube hochlädt. Genau das ist die christianohle-Pipeline: ein Multi-Agent-System, das ich seit Wochen täglich produktiv laufen lasse.

Dieser Artikel ist der Auftakt der Build-in-Public-Serie. Ich zeige dir die komplette Architektur — warum spezialisierte Agenten besser funktionieren als ein einzelner LLM-Call, wie die Agenten Daten austauschen, und welche Trade-offs ich dabei bewusst getroffen habe. Folge-Artikel zoomen jeweils in einen einzelnen Agenten rein. Das Big-Picture zur ursprünglichen Crash-Saga und zum Pivot weg vom lokalen Rendering steht im Faceless-YouTube-Pipeline-Artikel — dieser hier ist die nüchterne Architektur-Vivisektion.

Was ist eine Multi-Agent-Pipeline überhaupt?

Eine Multi-Agent-Pipeline ist ein System, in dem mehrere spezialisierte KI-Agenten eine komplexe Aufgabe in Teilschritte zerlegen und ihre Outputs an den nächsten Agent weitergeben. Jeder Agent hat:

• Eine eng definierte Aufgabe (Headlines bewerten, Video rendern, Audio erzeugen).
• Eigene Tools (Web-Search, ffmpeg, Replicate-API, ElevenLabs-Voice-API).
• Ein Eingangs- und Ausgangsschema, das fest definiert ist (oft via Pydantic).
• Einen eigenen LLM — Claude Haiku für günstige Klassifikations-Tasks, Claude Opus für tiefes Reasoning.

Das ist der Unterschied zum klassischen “ein-LLM-macht-alles”-Ansatz. Ein Monolith würde aus einer News-Headline direkt ein 6-Minuten-Video versuchen zu produzieren — und scheitert an Komplexität, Kosten und Halluzinationen. Eine Multi-Agent-Pipeline zerlegt dasselbe Problem in 15 fokussierte Schritte, die einzeln deterministisch und debugbar sind.

In der christianohle-Pipeline ist jede Stage ein Agent. Nicht “ein Pipeline-Step” — ein Agent. Diese sprachliche Konsequenz ist nicht zufällig: jeder Schritt hat tatsächlich eigene Logik, eigenes Memory, eigene Schnittstellen.

“Mein erster Versuch war ein einziger 800-Zeilen-Python-Skript, der alles macht. Hat zwei Wochen gehalten, dann hab ich ihn komplett zerschlagen. Mit jedem Agent als eigenem Modul ist die Pipeline heute 10× wartbarer — und auf einmal konnte ich auch Teile parallel laufen lassen, was vorher gar nicht ging.”

Die 15 Agenten der christianohle-Pipeline

Hier ist die vollständige Agent-Tabelle, in der Reihenfolge, in der sie aufgerufen werden:

Plus ein Metadata-Agent, der zwischen Schritt 14 und 15 läuft und 3 Titel-Vorschläge, eine SEO-Description und Kapitel-Marken aus dem Untertitel generiert.

Diese Tabelle ist die Bibel der Pipeline. Jeder dieser Agenten bekommt in den nächsten Folgen einen eigenen Artikel — heute die Architektur, ab morgen pro Tag ein Deep-Dive.

Der Daily-Run als Agent-Choreografie

Die Agenten laufen nicht beliebig, sondern in einem genau definierten Daily-Run, ausgelöst Mo/Mi/Fr um 07:00 Uhr per Windows Task Scheduler. Vereinfacht sieht der Ablauf so aus:

# Ablauf:
# 1. News-Scrape (src.scraper.run.run)
# 2. Topic-Ranking via Claude (src.script.select.rank_with_claude)
# 3. Top-1 nehmen das noch keine *.topic.json hat (Duplikat-Schutz)
# 4. Topic schreiben (src.script.select.write_selected)
# 5. Script-Generation (src.script.generate.generate)
# 6. Pipeline (src.pipeline.run)
# 7. YouTube-Upload als private (src.upload.youtube.upload_from_pipeline_output)

Sieben Stages, jede mit eigenem Exit-Code (0 = erfolgreich, 1 = keine neuen Topics, 2 = Pipeline-Fehler, 3 = Upload-Fehler). Der Duplikat-Schutz in Stage 3 ist nicht trivial — er liest alle vorhandenen *.topic.json-Files, extrahiert die item.id aus dem Slug und überspringt Topics, die schon einmal verarbeitet wurden:

def get_existing_topic_ids(script_dir: Path) -> set[str]:
    """Liest alle vorhandenen *.topic.json und gibt deren item-ids zurueck."""
    ids = set()
    for f in script_dir.glob("*.topic.json"):
        stem = f.stem.replace(".topic", "")
        parts = stem.split("-", 3)
        if len(parts) == 4:
            ids.add(parts[3])
    return ids

Das ist eine bewusst pragmatische Lösung: kein Datenbank-Setup, sondern Filesystem als Single-Source-of-Truth. Die data/scripts/-Verzeichnis-Struktur ist die Memory der Pipeline.

Warum spezialisierte Agenten statt Monolith?

Die Versuchung beim Bau eines solchen Systems ist groß, einfach Claude Opus mit “Mach mir aus dieser Headline ein YouTube-Video” zu bombardieren. Drei Gründe, warum ich das verworfen habe:

Erstens: Kosten. Topic-Ranking läuft auf Claude Haiku 4.5 — das ist Faktor 12 günstiger als Sonnet, Faktor 60 günstiger als Opus. Bei 60 Headlines pro Run zähle ich jede Token-Cent. Würde ich Opus für alles nutzen, wäre das Ranking allein teurer als die gesamte Pipeline aktuell kostet.

“Ich hab tatsächlich Opus mal für das Ranking probiert — pro Run lag der Preis bei knapp 4 €. Die Qualität war marginal besser als Haiku. Sofort wieder verworfen. Bei 12 Videos pro Monat wäre das 48 € im Monat verbrannt für 5 % bessere Headline-Auswahl.”

Zweitens: Parallelisierung. Der Visual-Orchestrator rendert 14 Szenen gleichzeitig. Ein Monolith-Call wäre seriell. ThreadPoolExecutor mit 2 parallelen Workern reduziert eine 14-Szenen-Stage von ~12 Minuten auf ~4 Minuten. Bei 3 Videos pro Woche sind das 24 gesparte Minuten Renderzeit.

Drittens: Debugbarkeit. Wenn der Voice-Agent eine kaputte Datei produziert, sehe ich das im Log mit klarer Fehlermeldung. Ein Monolith würde “irgendwo zwischen Audio und Assembly” scheitern, mit einem Fehler-Trace, der drei verschiedene Subsysteme einschließt. Bei 15 Agenten ist jeder Bug binnen Sekunden lokalisiert.

Der Pipeline-Orchestrator macht diese Trennung explizit. Erstmal alle Visuals parallel:

console.print(f"[cyan]→ Rendering {len(other_scenes)} CPU/API-Visuals parallel ({parallel_visuals} workers)…[/]")
with ThreadPoolExecutor(max_workers=parallel_visuals) as ex:
    futures = {ex.submit(_render_scene, s, raw, fal_ids): s for s in other_scenes}
    for fut in as_completed(futures):
        s = futures[fut]
        try:
            visual_paths[s.scene_id] = fut.result()
        except Exception as e:
            ...

Dann seriell die GPU-Szenen (ComfyUI ist GPU-bottleneck — parallel würde nur OOM-Crashes erzeugen):

if gpu_scenes:
    console.print(f"[cyan]→ Rendering {len(gpu_scenes)} GPU-Visuals seriell (ComfyUI)…[/]")
    for s in gpu_scenes:
        visual_paths[s.scene_id] = _render_scene(s, raw, fal_ids)

Diese Unterscheidung ist eine bewusste Architektur-Entscheidung. Mehr dazu im Artikel zum Visual-Orchestrator, der ab morgen online geht.

Wie die Agenten miteinander reden

Schnittstellen sind das, was eine zusammengeschusterte Skript-Sammlung von einer echten Multi-Agent-Pipeline unterscheidet. Bei christianohle nutzen die Agenten zwei Hauptkanäle:

Kanal 1: Pydantic-Schemas als Datenkontrakte. Der Script-Generator-Agent gibt nicht “ein Skript” zurück, sondern ein VideoScript-Objekt mit fest definierten Feldern. Jede Scene hat scene_id, duration_sec, narration, visual_type (manim / slide / comfy / stock / code / title_card / code_slide), visual_prompt, optional motion_hint. Der Visual-Orchestrator weiß, was er bekommt — kein Parsing, keine Halluzinations-Toleranz.

Kanal 2: Filesystem mit konventionellen Pfaden. Jeder Agent schreibt seinen Output an einen vorhersehbaren Pfad. Visuals nach data/raw/<topic_id>/<visual_type>/scene_NNN.mp4. Audio nach data/raw/<topic_id>/voiceover/scene_NNN.mp3. Caches nutzen denselben Pfad — wenn die Datei schon existiert und größer als 1024 Bytes ist, wird übersprungen:

sub = raw_dir / scene.visual_type
cached = sub / f"scene_{scene.scene_id:03d}.mp4"
if cached.exists() and cached.stat().st_size > 1024:
    console.print(f"[dim]Cache hit: scene_{scene.scene_id:03d} ({scene.visual_type})[/]")
    return cached

Die Cache-Strategie ist ein Game-Changer. Bei einem fehlgeschlagenen Pipeline-Lauf rendert der nächste Versuch nur die fehlenden Szenen neu — eine 4-Minuten-Recovery statt 12 Minuten kompletter Re-Run.

Was diese Architektur ermöglicht: jeder Agent kann unabhängig getestet, ersetzt oder verbessert werden. Der Comfy-Agent läuft heute auf Replicate Flux Schnell — morgen kann ich ihn auf SDXL umstellen, ohne dass irgendein anderer Agent etwas merkt. Solange das Output-Schema stimmt (MP4 mit definierter Länge), ist die Schnittstelle stabil.

Fallback-Ketten als Robustheits-Pattern

Was eine produktionsreife Multi-Agent-Pipeline von einem Demo unterscheidet, sind Fallback-Ketten. Jeder Agent hat eine Plan-B-Logik, falls sein primärer Tool-Call scheitert. Beispiel aus dem Visual-Renderer:

# Fallback-Kette: fal.ai → comfy (Replicate) → slide
if s.scene_id in fal_ids:
    console.print(f"[yellow]  Fallback fal→comfy fuer Scene {s.scene_id}[/]")
    try:
        visual_paths[s.scene_id] = comfy_r.render(...)
        continue
    except Exception as e2:
        console.print(f"[red]  comfy-Fallback auch failed: {e2}[/]")

console.print(f"[yellow]  Fallback auf Slide-Renderer fuer Scene {s.scene_id}[/]")
fallback_sub = raw / "slide"
visual_paths[s.scene_id] = slide_r.render(
    s.visual_prompt, s.duration_sec, fallback_sub, s.scene_id
)

Wenn der Fal-Video-Agent (Kling 2.5) eine Szene nicht rendern kann, fällt der Visual-Orchestrator auf den Comfy-Agent (Replicate Flux) zurück. Wenn auch der scheitert, kommt der Slide-Agent als letzte Reißleine — der wird immer funktionieren, weil er nur HTML+Playwright nutzt.

Das ist nicht über-engineered, sondern in Production gelebte Realität. fal.ai-Renderings können bei besonders aktionsreichen Prompts an interner Validierung scheitern. Wenn das morgens um 07:15 Uhr passiert, will ich nicht aufstehen und manuell triggern — die Pipeline löst das selbst.

Was diese Architektur kostet

Die Frage, die jeder zuerst stellt: Was kostet ein Video? Aus den Kostenlogs der letzten Wochen, gemittelt über 12 Videos:

• Topic-Ranker-Agent (Claude Haiku 4.5, 60 Headlines): ~0,02 €
• Script-Generator-Agent (Claude Opus 4.7, 14 Szenen): ~0,15 €
• Comfy-Agent (Replicate Flux Schnell, 6 Szenen): ~0,30 €
• Fal-Video-Agent (Kling 2.5, 3 Promotionen): ~0,80 €
• Manim-Agent + Slide-Agent: ~0,03 € (nur Claude für Manim-Code)
• Voice-Agent (ElevenLabs Turbo v2.5, ~600 Worte): ~0,40 €
• Subtitle-Agent (Whisper lokal): 0 €
• Assembly-Agent (ffmpeg lokal): 0 €
• Thumbnail-Agent: ~0,15 €
• Metadata-Agent + Upload-Agent: ~0,03 €

Gesamt: ~1,96 € pro Video. Das ist der Stand Mai 2026, mit aktuellen Modellpreisen. Bei 12 Videos pro Monat liegt der Stack-Preis bei ~24 € — günstiger als jeder einzelne Cloud-Editor-Abo. Mehr Details zur Kosten-Analyse pro Agent kommen im letzten Teil der Serie.

Was diese Zahl nicht zeigt: die ~70 Stunden Setup-Zeit, die ich in den ersten zwei Wochen reingesteckt habe. Davon waren ~20 Stunden in Crashes und Workarounds, dokumentiert im Faceless-YouTube-Pipeline-Artikel. Die restlichen ~50 Stunden waren echte Architektur-Arbeit — und die hat sich gelohnt.

“Mein größter Lerneffekt: Wer mit einem Multi-Agent-System anfängt, denkt anders über jedes Problem. Statt ‘wie löse ich das in einem Prompt’ frage ich heute ‘welcher Agent macht was, und welche Schnittstelle brauchen sie miteinander’. Das ist eine Denkverschiebung, die mir auch in Nicht-KI-Projekten hilft.”

Was als nächstes in der Serie kommt

Die nächsten 7 Artikel zoomen jeweils in einen oder zwei Agenten der Pipeline rein:

• Teil 2 — Topic-Ranker-Agent: wie Claude in 5 Sekunden 60 News-Headlines bewertet, mit dem 5-Kriterien-Score-System.
• Teil 3 — Script-Generator-Agent: Schema-First-Generation mit Pydantic, warum strukturiertes Output > Prompt-Tweaking.
• Teil 4 — Visual-Orchestrator: wie 6 Sub-Agents parallel 14 Szenen rendern.
• Teil 5 — B-Roll-Agent: Cutaway-Detection per Claude, Pexels-Fetch, ffmpeg-Overlay.
• Teil 6 — Voice-Agent + Subtitle-Agent: Word-Level-Timing-Pipeline.
• Teil 7 — Assembly-Agent: ffmpeg-Filter-Komplex hinter dem fertigen Video.
• Teil 8 — Cost per Video: vollständige TCO-Analyse, was sich skaliert und was nicht.

Im nächsten Teil schaue ich mir den Topic-Ranker-Agent an. Spoiler: der ist enger mit dem Script-Generator-Agent verzahnt als du denkst — die Score-Verteilung beeinflusst, wie viel Story-Substanz für das spätere Skript überhaupt da ist.

Meine Einschätzung

Ich habe vor dieser Pipeline versucht, alles in einem einzigen Skript zu lösen — und bin damit grandios gescheitert. Seitdem ist Multi-Agent-Architektur für mich kein Selbstzweck, sondern eine pragmatische Antwort auf Komplexität. Die Investition in saubere Schnittstellen zwischen Agents zahlt sich ab dem dritten Bug-Fix aus. Gleichzeitig gibt es eine klare Kehrseite: Wer mit Multi-Agent anfängt, bevor ein einziger Agent stabil läuft, verzettelt sich. Erst ein Agent, dann zwei, dann die Pipeline. Nicht umgekehrt.

Quellen

• Anthropic API — Claude Models
• [Replicate Flux Schnell](https://replicate.com/black-forest-l