Was keine KI-Demo zeigt

Eine überzeugende (KI-)Demo ist kein Garant dafür, dass in der Praxis alles problemlos läuft.Gorodenkoff | shutterstock.com



Demos im Technologieumfeld verlaufen oft nach einem ähnlichen Muster: Innerhalb von circa zwölf Minuten verwandelt sich ein Figma-Frame in einen bestandenen Test. Dann lässt Jemand im Raum das Schlagwort „Produktivität“ fallen – und das war‘s.



Was danach kommt, spielt in der Demo keine Rolle – und läuft dann zum Beispiel über meinen Pager ab, wenn ich Bereitschaftsdienst habe. Dort laufen dann Fragen auf wie:




Wem gehört das Ticket, das der KI-Agent um 3:14 Uhr morgens eröffnet hat?



Welcher Modell-Call hat die Assertion in Testfall 47 ausgelöst?



Wer schließt die 17 vorläufigen Tickets, die ein hängengebliebener Run hinterlassen hat, bevor sie beim nächsten Sprint-Planungs-Meeting auffallen?




Nach 20 Jahren Erfahrung in Sachen Testautomatisierung bei Consumer-Plattformen habe ich inzwischen ein Gefühl dafür entwickelt, welches Präsentations-Slide keinen Aufschluss darüber gibt, ob eine Pipeline in der Praxis liefert: das mit der Architektur. In der Praxis hilft hier nur ein Runbook weiter.



Für diesen Artikel habe ich eine unbeaufsichtigte, agentenbasierte Test-Pipeline über das Model Context Protocol (MCP) aufgebaut. Einen Softwareentwicklungszyklus mit fünf verschiedenen Agenten (Produktmanager, QA-Engineer, Automation Engineer, Developer, Pull-Request-Prüfer), der über MCP-Server für Jira, Figma, Confluence, TestRail und GitHub koordiniert wird. Als gehostetes Orchestrierungsmodell kommt dabei Claude zum Einsatz, die Validierungsbasis bildet das Open-Weight-KI-Modell Hermes-3.  



Diese Pipeline habe ich quasi als unabhängiges Forschungsprojekt betrieben. Das Ziel war dabei, herauszufinden, welche produktionstechnischen Einschränkungen von KI-Agenten regelmäßig unter den Teppich gekehrt werden – zum Beispiel im Rahmen von Demos.



Agenten, die sich selbst belügen



Der kostspieligste Failure Mode, den ich in einer Multi-Agenten-Pipeline beobachtet habe: Agent A liefert eine richtige Antwort, Agent B interpretiert diese falsch.



Das konnte ich auch bei meiner Pipeline beobachten: Der Requirements-Agent generierte einen sauberen Output mit einem Feld namens acceptance_criteria, das eine Liste von Strings enthielt. Der Ticket-Agent erwartete allerdings, dass dieses Feld ein einzelner Markdown-Blob ist.



Für sich genommen lag keiner der beiden Agenten falsch, beide bestanden ihre eigenen Unit-Tests. Die Pipeline hat daraus ein Jira-Ticket erstellt, dessen Akzeptanzkriterien aus vier Zeichen bestand: [“ — – der JSON-Serialisierung für ein leeres, erstes Element.



Der Testplanungs-Agent hat das gelesen, einen Test generiert, diesen als bestanden markiert und fuhr fort. Ich bemerkte den Fehler dann erst in der Pull-Request-Phase.



Hierbei handelt es sich um einen Kompositionsfehler – der natürliche Fehlermodus jedes Systems, in dem unabhängige Komponenten strukturierte Daten über eine Grenze hinweg übergeben, die sie nicht gemeinsam kontrollieren.



Experten für verteilte Systeme schreiben seit Jahren über dieses Problem. Im Zusammenhang mit Large Language Models (LLMs) wird es jedoch immer noch oft als Prompt-Problem betrachtet.



Das ist nicht der Fall, denn es ist nicht mit einem optimierten System-Prompt behebbar. Vielmehr braucht es dazu einen Handoff-Vertrag, dem beide Agenten zustimmen – sowie einen Validator dazwischen, der „schreit“, wenn die Struktur abweicht.



Auf diese Fausregeln setze ich inzwischen auch selbst: Jede Grenze zwischen zwei Agenten erhält ein Schema und einen Validator. Jeder Agent eine „Golden Input“-Regressions-Suite, die Vertragsabweichungen abfängt, bevor sie einen nachgelagerten Agenten erreichen.



Beides ist nicht gerade glamourös. Aber es macht den Unterschied zwischen einer Pipeline, die liefert, und einer, die ein kostspieliges „Stille Post“-Spiel generiert.



Wenn Sie herausfinden wollen, ob die agentenbasierte Pipeline Ihres Teams das erste Quartal überstehen wird, fragen Sie nach, wie der Vertrag zwischen Agent A und B aussieht. Lautet die Antwort „Das Modell findet das schon heraus“, können Sie das Budget für Nachbesserungen direkt einplanen.



Der Audit-Pfad, den niemand geschrieben hat



Ein weiterer Aspekt, auf den ich mittlerweile bestehe: Jedes von einer Pipeline erzeugte Artefakt muss auf Anhieb die Antworten auf drei grundsätzliche Fragen liefern:  




Welcher Agent hat es produziert?  



Welcher Modell-Call hat es generiert?



Welche vorgelagerten Inputs hat der Agent dabei berücksichtigt?




Das klingt nach „Nice-to-have“, ist aber eher ein „Must have“. Warum, zeigt ein Blick auf meine selbstgebaute Pipeline: Etwa in der dritten Woche nach dem diese in Betrieb war, stieß ich auf einen subtilen Fall: Der Requirements-Agent referenzierte eine Confluence-Seite auf sich selbst.



Der MCP-Server für Confluence hatte bei einem ersten Call ein leeres Ergebnis zurückgegeben, der Agent eine Platzhalter-Anforderung generiert. Der zweite Call verlief dann erfolgreich: Der Agent hatte seinen eigenen Platzhalter abgerufen und behandelte diesen beim dritten Durchlauf als „Source of Truth“. Im Ticket war übrigens allen Ernstes zu lesen, dass die Anforderung vom Design Owner stammt – was schlicht gelogen war.



Diese Art von Fehler lässt sich nicht anhand von Protokollen beheben, die festhalten, was das Modell „gesagt“ hat. Vielmehr sind dazu Protokolle darüber nötig, was das Modell „betrachtet“ hat.



Das hat zur Folge:




die Tool-Call-ID für jeden MCP-Aufruf zu erfassen,



jedes Artefakt mit den IDs zu kennzeichnen, aus denen es abgeleitet wurde, und



in einer nachgelagerten Phase nicht irgendwelche abgerufenen Fakten zu akzeptieren, die nicht auf einer echten externen Quelle basieren.




Ich nenne das die „Proof-the-Source“-Regel. Das mag langweilig sein. Allerdings hat mir diese zweizeilige Anforderung im Runbook bislang am meisten Zeit eingespart. Diese Guardrail hat außerdem einen willkommenen Nebeneffekt: Wenn Auditoren fragen, woher eine Entscheidung stammt, kann das über die Pipeline nachgewiesen werden.



Warum ich das Shutdown-Skript jetzt zuerst schreibe



Teams, die zum ersten Mal eine agentenbasierte Pipeline ausliefern, könnten davon überrascht sein, wie viel „Schutt“ sich dabei anhäuft. Denn eine Pipeline, die eine Woche lang unbeaufsichtigt läuft, verursacht unterschiedliche „Lecks“. Zum Beispiel in Form von:




Jira-Ticket-Entwürfen, deren übergeordnete Stories nie genehmigt wurden,



GitHub-Branches für Test-Suiten, die nie zusammengeführt wurden,



TestRail-Leaks, die gestartet wurden, zwei Ergebnisse geliefert und nie eine Zusammenfassung erhalten haben, oder



Kommentaren auf Confluence-Seiten, die der Agent gepostet hat, während er sich selbst eine klärende Frage gestellt hat.




Hierbei handelt es sich nicht um Bugs, sondern um die natürlichen Outputs eines autonomen Systems, das mehr Tasks in Angriff nimmt, als es abschließt.



Das habe auch ich durch Zufall entdeckt: Sechs Wochen nach Beginn meines Pipeline-Projekts führte ich in Jira eine Abfrage nach Tickets durch, die in den vergangenen 30 Tagen automatisiert erstellt wurden.



Ich war davon ausgegangen, vielleicht 20 zu sehen zu bekommen. Es waren allerdings 91 – von denen wiederum 68 „[DRAFT]“ im Titel trugen. So wurde mir klar, dass die Pipeline eine „stille“ zweite Aufgabe hatte, für die ich sie nicht ausgelegt hatte: Garbage Collection.



Deshalb enthält jede Pipeline, die ich ausführe, inzwischen drei Elemente, die noch vor dem ersten Agenten entstehen:




ein Shutdown-Skript, das sämtliche Artefakte schließt, die nach dem aktuellen Run verwaist sind,  



einen (nächtlichen) Reconciliation-Durchlauf, der die Artefakte schließt, die nach früheren Runs verwaist sind, sowie  



einen namentlich benannten, menschlichen Owner für jedes nachgelagerte System, in das die Pipeline schreiben kann.




Wenn die Pipeline nun ein Jira-Ticket erstellt, hat dieses auch einen realen Empfänger. Wenn sie einen Pull-Request eröffnet, steht ein spezifischer Prüfer in der Verantwortung. Und wenn sie einen TestRail-Lauf ablegt, wird jemand benachrichtigt, sobald dieser veraltet ist.



An dieser Stelle will ich die Gelegenheit nutzen, ein Anti-Pattern ganz offen anzusprechen: Lassen Sie einen Agenten unter keinen Umständen seine eigenen Artefakte schließen. Ich habe es versucht: Der mit der Bereinigung beauftragte Agent schloss die falschen (30) Tickets.



Anschließend schrieb er eine selbstbewusste Zusammenfassung, in der er das Gegenteil behauptete. Merke: Ein Cleanup sollte kein Modell-Aufruf sein. Dieser Task erfordert Menschen im Loop oder ein deterministisches Skript.



Nachdem ich die in diesem Artikel dargelegten Maßnahmen umgesetzt habe, funktioniert meine Pipeline nun – und spart tatsächlich Zeit in der Praxis. Das hat aber auch jede Menge Aufwand verursacht, den die meisten Teams vorab nicht auf dem Zettel haben.



In einer Demo wird keiner dieser Aspekte, die das Runbook ausmachen, gezeigt oder thematisiert. Allerdings entscheidet dieses darüber, ob eine Pipeline nur ein Experiment bleibt – oder verlässlich in der Produktion funktioniert.  



Teams, die das Runbook als Erstes erstellen, liefern auch zuerst. Teams, die sich darum erst nach dem ersten Sonntags-Incident kümmern, werden die folgenden zwei Quartale damit verbringen, ihren Rückstand aufzuholen. (fm)



Dieser Beitrag wurde im Rahmen des englischsprachigen Expert Contributor Network von Foundry veröffentlicht. Alle Infos zum deutschsprachigen Experten-Netzwerk finden Sie hier.