Agent-Chains statt Workflows: berechenbare KI
Warum GTM-Workflows an Grenzen stoßen und wie Agent-Chains mit typisierten Übergaben, Schema-Enforcement und Lernschleifen Multi-Step-KI berechenbar machen.
Das Problem mit Workflows — und das Problem mit Agenten
Im GTM-Stack stehen sich heute zwei Automatisierungs-Philosophien gegenüber, und beide haben einen wunden Punkt:
Workflows (n8n, Clay, Zapier) sind deterministisch und nachvollziehbar — aber sie kodieren den Wissensstand vom Tag ihrer Erstellung. Der Workflow weiß nicht, dass sich seit Januar die Reply-Muster geändert haben. Jeder Sonderfall, der beim Bauen nicht bedacht wurde, bricht die Kette oder produziert stillen Müll. Und sie hängen an der Person, die sie versteht — das “ClayOps-Problem”: Wenn der Operator geht, steht die Maschine.
Autonome Agenten verstehen Kontext und behandeln Sonderfälle — aber Multi-Step-KI hat einen verdienten Ruf als Black Box: Free-Text wandert von Schritt zu Schritt, kleine Abweichungen schaukeln sich auf (Prompt-Drift), und wenn das Endergebnis falsch ist, weiß niemand, welcher Schritt es war.
Agent-Chains sind die Synthese: die Flexibilität von Agenten in der Struktur von Workflows.
Die drei Architektur-Entscheidungen
1. Typisierte Übergaben statt Free-Text
Der wichtigste Mechanismus ist unscheinbar: Jeder Agent in der Kette liefert seinen Output als strukturiertes JSON gegen ein definiertes Schema — nicht als Fließtext, den der nächste Agent interpretieren muss.
Researcher → { industry, size, tech_stack, signals[] } ✓ validiert
Qualifier → { fit_score, reasons[], disqualifiers[] } ✓ validiert
Personalizer → { icebreaker, pain_point, value_hook } ✓ validiertPasst ein Output nicht zum Schema, wird der Agent mit der konkreten Fehlermeldung re-prompted — der Fehler wird an der Quelle behoben statt drei Schritte später entdeckt. Das eliminiert die häufigste Fehlerklasse in Multi-Step-Systemen: stilles Weiterreichen von Halbrichtigem.
2. Ein Agent, eine Verantwortung
Der zweite Fehler vieler KI-Setups ist der Monolith-Prompt: ein einziger Mega-Prompt, der recherchieren, bewerten, texten und entscheiden soll. Das ist weder wartbar noch debugbar.
Die Alternative folgt einer alten Software-Regel: Single Responsibility. Researcher, Qualifier, Enrichment-Agent, Personalizer, Reply-Drafter — jeder ein eigenständiger Worker mit eigenem Prompt, eigenen Tools, eigenen Memories. Wer den Qualifier verbessert, fasst den Personalizer nicht an. Wer einen Fehler sucht, schaut in einen Schritt, nicht in eine 4.000-Wörter-Prompt-Wand.
Dazu gehört Wiederverwendbarkeit: Eine Fähigkeit wie “LinkedIn-Headline analysieren” wird einmal als Skill definiert und mehreren Agents zugewiesen — ein Lerneffekt in einem Agent verbessert alle, die die Skill nutzen.
3. Sichtbarkeit an jedem Schritt
Black-Box-Verhalten ist kein KI-Naturgesetz, sondern eine Design-Entscheidung. Die Gegenmaßnahme: Jeder Schritt legt offen, womit er gearbeitet hat —
- den Prompt, der ausgeführt wurde
- den validierten JSON-Output
- die Few-Shot-Beispiele, die als Kontext geladen waren
- die Memories, die das Modell für diesen Workspace mitbringt
Der Operator sieht nicht nur was entschieden wurde, sondern warum — und kann an jedem Punkt korrigieren. Idempotente Steps machen das praktikabel: Jeder Schritt ist einzeln wiederholbar, ohne dass die halbe Pipeline neu laufen muss.
Der eigentliche Unterschied: Chains werden besser, Workflows bleiben stehen
Bis hierher ist das saubere Technik. Strategisch entscheidend ist die dritte Eigenschaft — die eingebaute Lernschleife:
| Signal | Mechanismus | Wirkung |
|---|---|---|
| Operator bewertet einen Step | Feedback pro Chain-Schritt | fließt in den nächsten Run |
| Guter Output wird markiert | wird Few-Shot-Beispiel der Skill | alle Agents mit der Skill profitieren |
| Outcome trifft ein (Reply, Meeting, Abschluss) | Konfidenz-Signal zurück in Qualifizierung und Copy | Modell kalibriert sich pro Account |
| Erkenntnis bestätigt/widerlegt sich | Memories werden verstärkt oder abgeschwächt | Altlasten verschwinden statt sich anzusammeln |
Das Ergebnis lässt sich in einem Satz fassen: Eine Agent-Chain, die heute deployed wird, läuft in drei Monaten messbar besser — mit demselben Prompt. Few-Shots, Memories und Skill-Beispiele haben sich aus dem Betrieb verfeinert. Ein Workflow ist in drei Monaten exakt so gut wie heute — bestenfalls.
Aus unserem eigenen Betrieb ist der Effekt direkt messbar: Die Freigabe-Quote der KI-Vorqualifizierung (Approval-Rate) startet bei neuen Playbooks bei 21-35% und erreicht nach Kalibrierung durch Operator-Feedback 78-97% — ohne dass an Prompts oder Architektur etwas geändert wurde. Das große Bild dazu: Closed-Loop Outbound.
Wann Workflows trotzdem die richtige Wahl sind
Ehrliche Abgrenzung — deterministische Workflows bleiben besser für:
- Reine Daten-Plumbing-Aufgaben: CRM-Feld A nach B syncen, Webhook-Routing, Formatkonvertierung — kein Urteilsvermögen nötig, also auch keine KI
- Compliance-kritische Fixpfade: wo exakt derselbe Ablauf auditiert werden muss
- Hochvolumige Mikro-Tasks mit trivialer Logik, wo LLM-Kosten pro Ausführung nicht zu rechtfertigen sind
Die Faustregel: Workflows für Plumbing, Agent-Chains für Urteilsvermögen. Recherche, Qualifizierung, Personalisierung und Reply-Handling sind Urteils-Aufgaben — wer sie in Wenn-Dann-Regeln presst, bekommt die Sonderfälle als Kollateralschaden.
Einstieg: Die erste Chain richtig wählen
Für Teams, die den Schritt machen wollen, hat sich eine Reihenfolge bewährt:
- Mit der Qualifizierung starten — klarer Input (Firma), klarer Output (passt/passt nicht + Begründung), sofort messbar gegen menschliches Urteil
- Schema zuerst definieren — welche Felder braucht der nächste Schritt wirklich? Das Schema ist der Vertrag, der die Kette stabil hält
- Bewertungs-Routine etablieren — 10 Minuten täglich Outputs bewerten schlägt jede nachträgliche Prompt-Optimierung
- Erst dann verketten — Researcher davor, Personalizer dahinter, wenn der mittlere Schritt zuverlässig läuft
Wer das nicht selbst bauen will: Was eine GTM-Engineering-Agentur leistet — und für die Make-or-Buy-Frage die Kostenrechnung SDR vs. KI-System.
Häufige Fragen
Was ist eine Agent-Chain?
Eine Kette spezialisierter KI-Agenten (z. B. Researcher → Qualifier → Personalizer), die Aufgaben sequenziell bearbeiten und ihre Ergebnisse als strukturierte, validierte Daten weitergeben. Anders als ein Workflow entscheidet jeder Agent pro Fall, wie er seine Aufgabe löst — die Struktur der Kette bleibt dabei deterministisch.
Worin unterscheiden sich Agent-Chains von n8n- oder Clay-Workflows?
Workflows kodieren feste Wenn-Dann-Regeln vom Tag ihrer Erstellung — jede Verbesserung ist Handarbeit. Agent-Chains behandeln Sonderfälle durch Kontextverständnis und werden durch Feedback (bewertete Outputs, Few-Shot-Beispiele, Memories) besser, ohne dass jemand die Kette umbaut.
Wie verhindert man, dass Multi-Step-KI zur Black Box wird?
Durch drei Mechanismen: typisierte JSON-Outputs mit Schema-Validierung an jeder Übergabe (defekte Antworten werden re-prompted), sichtbare Prompts und Few-Shot-Beispiele pro Schritt, und idempotente Steps, die einzeln wiederholbar sind. Damit ist jeder Lauf nachvollziehbar und korrigierbar.
Was bedeutet Schema-Enforcement bei KI-Agenten?
Jeder Agent-Output wird gegen ein definiertes Schema (z. B. Zod) validiert, bevor er an den nächsten Schritt geht. Passt die Struktur nicht, wird der Agent mit der konkreten Fehlermeldung erneut geprompted. Das eliminiert Free-Text-Drift — die häufigste Fehlerquelle in Multi-Step-KI-Systemen.
Lohnen sich Agent-Chains auch für kleine Teams?
Gerade dort: Workflows brauchen jemanden, der sie baut und pflegt (das ClayOps-Problem). Eine gut designte Agent-Chain braucht einen Operator, der Outputs bewertet — eine Aufgabe, die jeder Vertriebler kann. Die Pflege-Arbeit verlagert sich vom Umbauen zum Bewerten.