Dies ist Teil 2 der Serie KI-Agenten als Pipeline-Engineers. Im ersten Teil ging es um Pipeline Generation — wie ein Agent aus einem Prompt heraus neue Pipelines, Connectoren und Transforms baut. Dieser Artikel zeigt die zweite Phase: Operation — Monitoring, Debug, Extend, Run, alles agentengetrieben.
Die Grundlage dafür ist weiterhin unsere DAG-Engine Reveal — und das Prinzip dahinter lässt sich auf andere Pipeline-Frameworks anwenden, solange die richtigen Voraussetzungen stimmen.
Pipeline Operation
Was der Agent grundsätzlich braucht
Bevor ein KI-Agent sinnvoll mit einer Data Pipeline arbeiten kann, braucht er Zugang zu allen relevanten Informationen. Das klingt offensichtlich — aber in der Praxis fehlt dieser Kontext fast immer.
Vier Säulen, die stehen müssen:
Pipeline-Implementierung — Zugang zum Repo. Der Agent muss den echten Code lesen können, kein Wiki-Auszug. LLMs sind in der Lage, Quellcode zu lesen, DAG-Strukturen zu verstehen und Transformationslogik zu interpretieren.
Daten-Orte — Wo liegen die Eingangsdaten? Wo landen die Ausgaben? Connection Strings, Bucket-Namen, Datenbankschemas — alles, was der Agent braucht, um Daten direkt zu inspizieren.
Helm Chart — Image-Tags, Environment-Variablen, Kubernetes-Ressourcen. Der Agent kann Helm Charts lesen und verstehen. Damit kennt er das Deployment-Setup.
Querverbindungen zwischen Artefakten — Code, Helm Chart, Kubernetes-Cluster und Daten-Orte müssen miteinander verbunden sein. Wenn der Agent in Node A einen Fehler vermutet, muss er von dort direkt zum Helm Chart und von dort zum laufenden Pod navigieren können, ohne dass ein Mensch den nächsten Schritt einleitet.
Die laufende Pipeline ist der Bereich, wo Agentic AI am sichtbarsten Wert schafft. Vier Operationen, die heute meist manuell laufen, können vollständig agentengetrieben sein: Monitoring, Debug, Extend, Run.
Monitoring — Status ohne Log-Diving
> Hey Claude, hat der gestrige Run alle Nodes erfolgreich abgeschlossen?
→ Alle 5 Nodes erfolgreich.
847 Records verarbeitet, 12 neue CashFlows, 9 Belege gematcht.
CommerzBankSourceNode: 0 Fehler.
VerheirateNode: 3 Unmatched (wie gestern besprochen).
ReportNode: HTML-Output 2.1 MB, Versand-Mail an steuer@kunde.de versendet.
Der Agent liest den Audit-Trail des letzten Runs und beantwortet die Frage — ohne dass jemand Logs aufmacht oder ein Dashboard öffnet.
Debug — der Klassiker „Die Zahlen stimmen nicht”
Der Klassiker im Data-Engineering-Alltag. Kunde schreibt: „Die Auswertung von gestern zeigt eine Differenz von 4.230 €. Bitte schaut euch das nochmal an.” Kein Stack-Trace, kein Logging-Fehler, kein Alert — nur das Symptom.
So geht ein Agent mit dem richtigen Setup damit um:
Schritt 1 — DAG analysieren, relevanten Knoten identifizieren
Der Agent liest zunächst den DAG der Pipeline. In Reveal passiert das direkt aus dem Code — jede Node-Klasse ist selbstbeschreibend, und der Mermaid-Code der Pipeline gibt die Struktur wieder. Der Agent entscheidet anhand von Node-Typ (Transform, Match, Report) und Position im DAG, welcher Knoten für den gemeldeten Fehler in Frage kommt.
> Die Auswertung für gestern zeigt falsche Umsatzzahlen.
Welcher Teil der Pipeline ist betroffen?
→ Ich sehe im DAG drei mögliche Kandidaten:
· CashFlowNormalize
· VerheirateMatch
· ReportNode
Der Fehler liegt im finalen Report — ReportNode bekommt seine
Daten von VerheirateMatch. Ich schaue dort als nächstes.
Schritt 2 — Eingangsdaten inspizieren
Der Agent greift direkt auf die Eingangsdaten des verdächtigen Knotens zu. Er liest die tatsächlichen Rohdaten aus der Datenquelle — nicht Logs, sondern die Datensätze selbst.
→ Lese delta_input.parquet aus dem letzten Run-Folder.
47 Transaktionen vom gestrigen Tag.
12 davon haben CounterAccountId = "0" (als String).
Summe dieser Transaktionen: 4.230 €.
Das entspricht genau der Differenz im Report.
Schritt 3 — Fehlerursache im Code suchen
Jetzt geht der Agent zurück in den Code — konkret in die Klasse, die für den Matching-Schritt zuständig ist.
→ In VerheirateMatchNode.cs, Zeile 84:
.Where(t => t.CounterAccountId != null
&& t.CounterAccountId != "")
Problem: CounterAccountId = "0" rutscht durch.
Später schlägt der Join gegen die Konto-Tabelle fehl.
Vorschlag: int.TryParse + Prüfung auf > 0.
Schritt 4 — Fix einspielen und Pipeline neu starten
Der Agent passt den Code an, schreibt einen Test, baut über CI/CD ein neues Image, aktualisiert das Helm Chart und triggert einen manuellen Run.
→ Patch in VerheirateMatchNode.cs angewendet.
Test geschrieben: TestVerheirateMatch_FiltersZeroAccount → grün.
CI-Build: Image-Tag 2026-05-15-fix-counter-account erstellt.
→ Helm-Wert image.tag im values.yaml aktualisiert (Branch + PR).
→ Manueller Run gestartet:
kubectl create job --from=cronjob/verheirate-match \
verheirate-match-manual-20260515 -n reveal-prod
Run läuft. Ich melde sobald 12 Records gefiltert sind.
Extend — Pipeline erweitern
Neue Anforderung, neue Node, ohne den DAG neu zu zeichnen:
> Hey Claude, wir brauchen eine zusätzliche Validierung:
Buchungsbeträge über 10.000 € sollen ein Approval-Flag setzen,
bevor sie im Report landen.
→ Ich schalte eine neue Node zwischen VerheirateMatch und ReportNode:
BuchungsApprovalNode.cs
→ Logik: für jeden Eintrag Betrag > 10.000 €
Flag.RequiresApproval = true setzen.
ReportNode rendert solche Einträge in eigener Sektion.
→ DAG-DependsOn aktualisiert. Test geschrieben (3 Cases). Alle grün.
PR #142 erstellt — bitte reviewen.
Der Agent kennt die DAG-Topologie und kann Knoten an der richtigen Stelle einhängen.
Run — Ad-hoc-Runs ohne UI-Klick-Marathon
Drei Trigger-Wege, alle agent-zugänglich:
Scheduled CronJob — kubectl get cronjob liefert Frequenz, letzte und nächste Ausführung. Der Agent weiß, wann er das nächste Mal Daten erwarten kann.
Manueller On-Demand-Run — kubectl create job --from=cronjob/... triggert eine ad-hoc Ausführung. Der Agent startet sie und beobachtet die Logs.
Re-Run mit Override — values.yaml-Override für Datumsfilter, Tenant oder Dry-Run-Modus, alles per Prompt.
Das ist Operations ohne Operations-Person.
Was Reveal hier ermöglicht
Beide Phasen — Generation und Operation — funktionieren heute, weil Reveal-Pipelines so gebaut sind, dass ein LLM direkt damit arbeiten kann:
- Selbstbeschreibende Node-Klassen — Jede Node enthält Metadaten über Input-Typ, Output-Typ und Transformationslogik. Ein Agent kann die gesamte Pipeline aus dem Codebase lesen, ohne Dokumentation.
- Mermaid-DAG im Code — Die Abhängigkeitsstruktur ist maschinenlesbar direkt im Repository — kein manuell gepflegtes Diagramm.
- Audit Trail — Jeder Pipeline-Run wird protokolliert. Der Agent kann Runs vergleichen und Regressionen erkennen.
- Kubernetes-nativ — Reveal läuft auf Kubernetes. Der Agent kann über
kubectldirekt eingreifen — Jobs triggern, Logs lesen, Image-Tags aktualisieren.
Für wen das relevant ist
Data Engineers und Berater, die Pipeline auf Pipeline implementieren: Das Setup-Investment (Repository-Struktur, Helm-Chart-Konventionen, Querverbindungen zwischen Artefakten) zahlt sich bereits ab der zweiten Pipeline aus. Generation wird ein halber Tag, Debug wird Minuten statt Stunden.
Software-Vendor-Teams, die Reporting- und Analytics-Features in ihr Produkt einbauen wollen: Wenn eure Kunden ihre Pipelines selbst erweitern und debuggen können — mit einem KI-Agenten als Interface — dann wird euer Produkt mit jedem Kundenwunsch besser, ohne dass ihr jede Anpassung selbst implementieren müsst.
BI-Teams, die ihr bestehendes BI nicht ablösen, aber erweitern wollen: Neue Datenquellen + neue Views per Prompt, kein IT-Ticket.
Der entscheidende Schritt ist nicht das LLM — das gibt es. Der entscheidende Schritt ist, die Pipeline-Infrastruktur so zu bauen, dass ein Agent überhaupt navigieren kann. Wer das einmal richtig aufsetzt, bekommt einen Mitarbeiter, der rund um die Uhr verfügbar ist, keinen Kontext verliert und sich über Routine-Debugging nicht beschwert.