Mehr Engineering, weniger Magie: Wie Agentic AI den Weg in die Produktion findet

Wenn wir ehrlich sind, waren 2023 und große Teile von 2024 und 2025 die Jahre der Demos. Wir haben alle diesen „Aha“-Moment erlebt, wenn ein AI-Agent eine komplexe Aufgabe scheinbar mühelos löst. Es fühlt sich an wie Magie. Aber wenn man versucht, diese Magie in eine Enterprise-Umgebung zu bringen – in Prozesse, die auditierbar, zuverlässig und skalierbar sein müssen – verfliegt der Zauber oft schneller, als einem lieb ist.

In meinem letzten Beitrag habe ich über Sicherheit gesprochen – über Prompt Injection und Data Exfiltration. Aber selbst wenn ein Agent absolut sicher ist, bedeutet das noch lange nicht, dass er nützlich oder zuverlässig ist.

Ende 2025 ist oft nicht das Modell das zentrale Problem, wenn es um Zuverlässigkeit geht. GPT-5.1, Claude 4.5 oder Gemini 3 sind smart genug. Das Problem ist das Fehlen von angemessenem Engineering um das Modell herum, sowie notwendiger Systematik bei der Entwicklung.

Wenn du heute einen Agenten baust und deine Strategie lautet: „Wir schreiben einen guten Prompt und hoffen das Beste“, dann baust du kein Enterprise-System, sondern ein Experiment.

Von diesen haben wir die letzten Jahre genügend gesehen – das heißt nicht, dass sie nicht immer wieder hilfreich sind, aber wir müssen einen Schritt weiterdenken.

Was ist also notwendig, um Agentic AI von der Spielwiese in die Produktion zu bringen? Drei wichtige Aspekte, die Demos von verlässlichen Systemen unterscheiden: Evaluierung, systematisches Prompt Engineering und Architektur. Verbunden mit dem wichtigsten Mechanismus überhaupt (auch im Zeitalter der Prompts und Foundation Models) – dem Data Flywheel – bilden sie eine solide Basis für produktionsreife Agentic AI.

Warum klassisches Software-Testing für Agenten nicht ausreicht

In der traditionellen Softwareentwicklung leben wir in einer deterministischen Welt. Input A in Funktion B ergibt immer Output C. Wenn nicht, ist es ein Bug. Wir schreiben Unit Tests, wir erreichen 100 % Coverage, wir gehen live.

Agenten funktionieren nicht ganz so einfach.

LLMs und damit umso mehr Agenten sind probabilistisch. Sie treffen Entscheidungen basierend auf Wahrscheinlichkeiten. Sie nutzen Tools, sie haben einen „Memory State“, sie schmieden Pläne, die sich mitten in der Ausführung ändern können.

Ein Agent, der heute funktioniert, kann morgen bei exakt gleicher Eingabe scheitern, weil das Sampling anders ausfiel oder es ein Update im Inference-Stack gab.

Das „Vibe Check“-Problem

Das größte Risiko in aktuellen AI-Projekten ist das Verlassen auf den „Vibe Check“. Ein Entwickler schreibt den Prompt oder passt ihn an, testet manuell fünf Beispiele, nickt zufrieden („Sieht gut aus!“) und deployt.

Was in klassischer Software-Entwicklung schon lange ein No-Go ist, wird mit Agentic AI (oder AI allgemein) nicht plötzlich wieder akzeptabel.

In der Enterprise-AI-Welt sehen wir völlig neue Fehlerklassen:

1. Subtile Logikfehler: Der Agent klingt extrem überzeugend, aber die Fakten oder die abgeleiteten Entscheidungen sind falsch.
2. Mangelndes Alignment: Der Agent trifft nachvollziehbare Entscheidungen, die aber nicht mit den speziellen Geschäfts- oder Compliance-Regeln des Unternehmens übereinstimmen.
3. Infinite Loops & Kosten: Ein Agent verfängt sich in einer Schleife und verbrennt API-Budget, ohne ein Ergebnis zu liefern.
4. Tool Misuse: Der Agent ruft die richtige API auf, aber mit Parametern, die zwar syntaktisch korrekt, aber semantisch unsinnig sind.

Wer einen Machine Learning oder Data Science Background hat, weiß: Wenn es keinen expliziten Evaluierungs-Stack für einen Agenten und AI-Komponenten gibt, fliegt man blind. Eine Änderung am Prompt, die ein bestimmtes Problem zufriedenstellend löst, kann gleichzeitig diverse andere Szenarien ruinieren. Deshalb sind Regressionstests selbstverständlich auch bei AI essenziell – und sie bringen ein paar Besonderheiten mit sich.

Messen, was zählt

Eine robuste Strategie besteht nicht aus einem einzigen "Test", sondern aus Schichten:

1. Unit Level (Deterministisch): Bevor wir überhaupt über KI reden: Funktionieren deine Tools? Validieren deine Pydantic-Schemas die Outputs korrekt? Das ist klassisches Software-Testing.
2. Component Level (RAG & Tasks): Wenn dein Agent Dokumente sucht, wie gut ist das Retrieval? Wenn er Daten extrahieren soll, wie hoch ist die Precision/Recall? Hier helfen Frameworks wie DeepEval oder Ragas.
3. End-to-End Agent Scenarios: Hier werden Szenarien mit erwartetem Ergebnis definiert, die die gesamte Agent-Loop testen: „Gegeben ist Support-Ticket X und Kundendaten Y. Das erwartete Ergebnis ist: Ticket klassifiziert als ‚High Priority‘, Rückerstattung über 50€ veranlasst, Kunde per Mail informiert.“

Offline- vs. Online-Evaluierung

Die Offline-Evaluierung (Offline = statisch/Batch) ist unsere Regression Suite. Bevor eine neue Prompt-Version live geht, läuft sie gegen 200 historische Fälle ("Golden Dataset"). Wir messen Erfolgsrate, Kosten, Latenz und alles, was wichtig ist. Initial liefert so eine Evaluation überhaupt erstmal belastbare, mehr oder weniger objektive Zahlen, ob das System überhaupt reif für die Produktion ist. Arbeitet es zuverlässig genug und mit der notwendigen Qualität? Funktioniert ein AI Agent für diesen Use Case überhaupt, oder haben wir uns übernommen? Hier braucht es Zahlen schwarz auf weiß und mit vorher klar definierten Schwellenwerten für KPIs. Wurden diese erreicht, müssen sie bei jeder Änderung kontinuierlich wieder überprüft werden.

Aber auch das reicht noch nicht. In der Produktion braucht es Online-Evaluierung (Online = live/Echtzeit). Du kannst nicht jeden Chat lesen. Du brauchst LLM-as-a-Judge-Systeme, die im Hintergrund mitlaufen und Gespräche bewerten: Hat der Agent die Policy eingehalten? War er hilfreich?

Kombinieren wir das mit harten Business-Metriken (wurde das Ticket wirklich geschlossen?), haben wir endlich Transparenz.

Ohne Observability – also das detaillierte Logging von jedem Gedankenschritt (Chain-of-Thought), jedem Tool-Call und jedem State-Change – ist keine Fehleranalyse möglich. Man muss den „Trace“ sehen, nicht nur Input und Output.

Prompts: der Abschied von den "Magic Strings"

Prompts sind Freitext mit praktisch unbegrenzten Freiheitsgraden. Die Performance des LLMs hängt maßgeblich von der Struktur und Formulierung der Prompts ab und gleichzeitig ist es oft ein Rätselraten und jede Menge aufwändiges, händisches Experimentieren von „Prompt-Engineers“, das bestimmt, wie ein Prompt am Ende aussieht. Mit Glück gibt es vom Hersteller einen groben Prompting-Guide für das jeweilige Modell. Trotzdem hängt es am Ende teils an kleinen Formulierungen oder Zusätzen, ob das Modell so performt, wie es soll.

Ein Prompt ist dabei (wenn er richtig entwickelt wurde) immer auf ein ganz spezielles Modell zugeschnitten und lässt sich oft nicht direkt ohne Nebeneffekte auf andere Modelle übertragen.

In vielen Unternehmen sieht der Code für LLM-Anwendungen zudem gruselig aus: Riesige Python-Dateien, in denen f-Strings mit hunderten Zeilen Prompt-Text vergraben sind. Irgendwo werden undurchsichtig Variablen reinformatiert.

Jetzt stellen wir uns vor, unser Unternehmen skaliert die Adoption von LLMs und AI Agenten. Hunderte, händisch geschriebene, an verschiedenen Modellen hängende Prompts, über diverse Codebases verteilt.

Regelmäßig müssen diese Prompts modifiziert werden, um das System zu verbessern und bestimmte Fehler aus Produktion zu beheben. Früher oder später müssen oder sollen sie komplett migriert werden auf eine neue Modellgeneration (typische Lebenszeit in der API: nur 2-3 Jahre), von einem Anbieter zum anderen, oder von proprietär zu open-weight.

So behandelt wie bisher werden Prompts damit zu massiven technischen Schulden.

Um diese Probleme zu adressieren, müssen wir Prompts stattdessen wie Code behandeln – oder besser noch: wie kompilierte Artefakte.

Zentralisierung: Prompts gehören nicht hardcoded in die Business-Logik. Sie gehören in eine Registry. Jeder Prompt hat eine ID und eine Version.

Spezifikation statt Text: Automatische Prompt-Optimizer (wie in DSPy) ändern das Paradigma: Anstatt stundenlang am Wortlaut („Sei nett und denke Schritt für Schritt“) zu feilen, definiert man die Signatur (Input -> Output) der AI-Komponente, die relevanten Metriken und ein Gold-Set. Ein Optimizer kompiliert dann den perfekten Prompt für das spezifische Modell.

Versionierung: Wenn GPT-6 rauskommt, wird dein handgeklöppelter Prompt für GPT-5 wahrscheinlich nicht mehr optimal sein. Mit einem systematischen Ansatz (Prompt Registry + Eval Suite + Optimizer) tauschst du das Modell, lässt den Optimizer laufen, validierst gegen dein Gold-Set und gehst mit einer neuen Version live. Dank der Registry und Versionierung ist ein Rollback jederzeit möglich.

Die Architektur-Regel lautet: Trennung von Belangen.

• Der Workflow (BPMN) sagt, wann und wo eine KI-Entscheidung nötig ist.
• Der Prompt-Service liefert die wie-Implementierung (den konkreten Text), basierend auf Version und Modell.

Bounded Autonomy: Agenten brauchen Leitplanken

Es gibt die Wunschvorstellung vom „vollautonomen Agenten“, den man auf ein Problem wirft und der es schon irgendwie lösen wird. Im Enterprise-Kontext ist das meistens eine schlechte Idee.

Wir brauchen Bounded Autonomy (begrenzte Autonomie).

Workflow First, Agent Second

Die stabilsten Systeme, die ich mir vorstellen kann, drehen das Verhältnis um. Sie nutzen keine Agenten, um den Prozess zu steuern. Sie nutzen einen Prozess (z. B. in Camunda oder ähnlichen Orchestrierungstools), um Agenten zu steuern.

Der Rahmen (die Orchestrierung) ist deterministisch (BPMN). Innerhalb von Tasks wird AI-Funktionalität verwendet (Klassifikation, Extraktion). Innerhalb kleiner, klar definierter Subprozesse darf ein begrenzter Agent "denken" und Tools nutzen, sofern es für den Prozess denn wirklich notwendig ist.

Die Grenzen sind hart codiert: Welche Tools darf er nutzen? Wie viel Budget hat er? Und vor allem: Wo sind die Human-in-the-Loop-Checkpoints? Viele Entscheidungen sollte aus Gründen der Zuverlässigkeit und Governance am Ende ein Mensch treffen. Der Agent liefert nur zu oder behandelt nur definierte low-risk Fälle selbstständig.

Das Ziel ist nicht, die KI einzuschränken, sondern das Risiko zu managen. Nur so werden Agenten von einer „netten Spielerei“ zu einem geschäftskritischen Werkzeug.

Dabei sollte man auch darauf achten, nicht technologiegetrieben auf Zwang Agenten in die Prozesse einzubauen, sondern ehrlich sein und schauen, wo sie wirklich helfen. Oft lassen sich Demo-Use-Cases eigentlich nach und nach so weit zerlegen, dass sie von einem gewöhnlichen Workflow mit AI-Tasks bewältigt werden könnten – mit großen Vorteilen bei Zuverlässigkeit, Governance und auch Kosten. Use Cases, die wirklich von Agenten profitieren, sind oft explorativer Natur (Recherche, Analyse etc.). Unstrukturierte Daten allein rechtfertigen noch lange keinen Agenten, es ist das LLM, das man benötigt.

Das Data Flywheel: der Motor des Ganzen

Jetzt haben wir Evaluierung, sauberes Prompt-Management und Prozess-Leitplanken. Aber das System ist immer noch statisch.

Das Geheimnis der Tech-Giganten (und warum deren Modelle immer besser werden) ist das Data Flywheel.

Ein AI- oder Agenten-System ist niemals „fertig“. Der erste Tag in Produktion ist der schlechteste Tag des Systems. Ab diesem Zeitpunkt sollte es lernen.

Wie das Flywheel funktioniert:

1. Daten erfassen: Jeder Trace, jeder User-Feedback-Daumen, jede Korrektur durch Mitarbeitende im Human-in-the-Loop-Prozess wird gespeichert.
2. Kuratieren: Wir filtern aus diesen Daten die „Hard Cases“ – die Fälle, wo der Agent unsicher war oder versagt hat.
3. Evaluierung anreichern: Diese Hard Cases wandern sofort in unsere „Golden Tasks“ Test-Suite. Unsere Tests werden also mit der Realität härter und besser.
4. Optimieren: Wir nutzen diese Daten, um (via DSPy oder Fine-Tuning) die Prompts oder sogar das Modell zu verbessern.
5. Deployen: Die neue Version geht live und generiert noch bessere Daten.

Das ist der Unterschied zwischen einem Projekt und einem Produkt. Ohne diesen Kreislauf akkumuliert man nur Fehler. Mit diesem Kreislauf lässt sich ein Wettbewerbsvorteil (Data Moat) aufbauen.

Ein Fahrplan für die Umsetzung

Das klingt nach viel Arbeit. Und ja, das ist es. Aber: Wir müssen nicht alles ab Tag 1 so implementiert haben. Hier ist ein pragmatischer Vorschlag:

Schritt 1: Instrumentierung (Blindflug beenden)

Bevor du irgendetwas optimierst: Logge alles. Inputs, Outputs, Tool-Calls, Latenzen. Baue ein Dashboard. Wisse, wie oft dein Agent eigentlich scheitert.

Schritt 2: die erste Regression Suite

Nimm 50 echte Beispiele aus deinen Logs und baue einen automatisierten Test. Nutze regelbasierte Metriken wo möglich, LLM-as-a-Judge wo nötig. Wenn du den Prompt änderst, lass den Test laufen. Das ist der Beginn von Professionalität.

Schritt 3: Bounded Autonomy & Struktur

Es ist ok prototypisch mit einem großen Agenten zu starten, um die Validität des Konzeptes zu beweisen. Bewege dich dann aber systematisch weg von monolithischen „Super-Prompts“: Zerlege den Prozess in Workflows. Kapsle die AI-Tasks. Führe Versionierung für Prompts ein.

Schritt 4: das Flywheel schließen

Etabliere Prozesse, wie Feedback von Nutzern systematisch zurück in die Entwicklung fließt. Mach das Re-Optimieren von Prompts idealerweise zu einem Teil des CI/CD-Zyklus.

Wie gut fühlt es sich an, am Release-Abend von GPT-6 einen Parameter in einer Config anzupassen, eine Pipeline anzustoßen und auf Basis harter Daten eine informierte Entscheidung treffen zu können, ob sich eine Migration lohnt (und diese direkt mit einer weiteren Pipeline zu vollenden)? Migration auf eine neue Modellgeneration mit zwei Klicks am Abend des Releases. Wer hier steht, hat es geschafft und kann Agentic AI im Unternehmen mit Selbstvertrauen skalieren.

Fazit: die Fragen, die du stellen musst

Wenn du vermeiden willst, weiter nur Demos zu bauen, stelle diese Fragen:

1. Woher wissen wir, dass der AI-Agent reif ist? (Evaluierung)
2. Wie stellen wir sicher, dass ein Update morgen nicht alles von gestern kaputt macht? (Regression Testing & Versioning)
3. Was passiert im Worst Case? (Guardrails & Bounded Autonomy)
4. Wie wird das System mit der Zeit besser und vermeidet frühere Fehler? (Data Flywheel)

Sichere Agenten sind die Pflicht, zuverlässige, operationalisierbare Agenten sind die Kür – aber genau dort wird in den nächsten Jahren das Geld verdient.