KI-Agenten: Vom ersten Prototyp zum zuverlässigen Produktivbetrieb

Eine Demo zeigt meist den Idealweg: Eingabe kommt an, das Modell versteht die Aufgabe, ein Tool wird aufgerufen und das gewünschte Ergebnis erscheint. Genau dieser Happy Path sagt aber wenig darüber aus, ob ein KI-Agent auch hundert oder zehntausend reale Vorgänge zuverlässig bearbeiten kann.

Im Produktivbetrieb entstehen Situationen, die in Demos selten vorkommen: Eine API antwortet zu spät. Ein Datensatz fehlt. Zwei Systeme liefern widersprüchliche Werte. Ein Tool meldet Erfolg, obwohl die Folgeaktion fehlschlägt. Oder ein Nutzer fordert eine Aktion an, für die der Agent keine Berechtigung haben darf.

Genau deshalb betrachten wir in diesem Artikel nicht noch einmal die Grundfrage, was ein KI-Agent ist. Wenn Sie zunächst klären möchten, ob ein Agent für Ihren Prozess überhaupt sinnvoll ist, lesen Sie unseren Beitrag zu KI-Agenten für Unternehmen.

Für robuste Systeme hilft es, einen KI-Agenten nicht als einen großen autonomen Block zu betrachten. Sinnvoller ist eine Architektur aus klar getrennten Ebenen. Jede Ebene beantwortet eine andere Frage und kann unabhängig getestet werden.

Diese Trennung ist mehr als technische Ordnung. Sie verhindert, dass Modelllogik, Geschäftsregeln und echte Systemaktionen ineinander verschwimmen. Ein Modell darf beispielsweise vorschlagen, eine Rechnung zu versenden. Ob der Versand tatsächlich erlaubt ist, sollte jedoch eine separate Regel- und Berechtigungsschicht entscheiden.

Ein typischer produktiver Ablauf beginnt mit einer Anfrage oder einem Ereignis. Zuerst werden Identität, Berechtigungen und Eingangsdaten geprüft. Erst danach erhält das Modell den Kontext, den es für seine Entscheidung benötigt.

• 1. Eingang validieren und Nutzer- oder Systemidentität bestimmen.
• 2. Relevanten Kontext aus freigegebenen Datenquellen laden.
• 3. Aufgabe klassifizieren und nächsten Schritt planen.
• 4. Passendes Tool mit strukturierten Parametern aufrufen.
• 5. Tool-Ergebnis gegen erwartete Bedingungen prüfen.
• 6. Zustand und Zwischenergebnis speichern.
• 7. Bei kritischen Aktionen eine Freigabe einholen.
• 8. Ergebnis zurückgeben und Lauf für Monitoring und Evals protokollieren.

RAG liefert dabei Wissen, das nicht zuverlässig im Modell selbst liegen sollte. State hält fest, was innerhalb eines laufenden Prozesses bereits passiert ist. Memory kann darüber hinaus Informationen über mehrere Interaktionen hinweg verfügbar machen. Diese Begriffe sollten technisch getrennt werden, weil sie unterschiedliche Risiken und Lebenszyklen besitzen.

MCP kann eine zusätzliche Integrationsschicht bilden. Der offene Standard verbindet KI-Anwendungen mit Tools und Datenquellen. Er ersetzt jedoch weder Berechtigungen noch Geschäftslogik: Auch ein sauber angebundenes Tool braucht weiterhin klare Regeln dafür, wer welche Aktion unter welchen Bedingungen auslösen darf.

Sauber strukturierte und maschinenlesbare Wissensbestände sind nicht nur für interne Agenten hilfreich. Dieselbe Grunddisziplin spielt auch bei Generative Engine Optimization eine Rolle. Webnity-X begleitet Unternehmen als GEO-Agentur dabei, Inhalte für klassische und generative Suchsysteme besser nutzbar zu machen.

Nehmen wir einen Agenten, der nach einer Prüfung automatisch eine Rechnung versendet. Er löst den Versand aus, erhält wegen eines Timeouts aber keine eindeutige Antwort. Ohne zusätzliche Logik weiß das System nicht, ob die Rechnung bereits verschickt wurde.

Ein blindes Retry kann dieselbe Rechnung ein zweites Mal senden. Ein sofortiger Abbruch kann dagegen einen tatsächlich fehlgeschlagenen Versand unbemerkt lassen. Genau für solche Situationen braucht ein Workflow eindeutige Vorgangs-IDs und idempotente Aktionen.

Retry ist nicht gleich Wiederholen

Ein Retry sollte nur erfolgen, wenn die Aktion technisch sicher wiederholbar ist. Bei reinen Lesezugriffen ist das oft unproblematisch. Bei E-Mails, Zahlungen, Bestellungen oder Datenänderungen muss vor einem erneuten Tool-Aufruf geprüft werden, ob der erste Vorgang bereits einen Seiteneffekt erzeugt hat.

Fallbacks brauchen einen definierten Endpunkt

Wenn ein primäres Tool ausfällt, kann ein alternativer Datenweg sinnvoll sein. Ein Fallback darf aber nicht stillschweigend die fachliche Bedeutung verändern. Kann der Agent einen Vorgang nicht zuverlässig abschließen, muss der Prozess kontrolliert pausieren oder an einen Menschen übergeben werden.

Human-in-the-Loop bedeutet dabei nicht, dass ein Mensch jeden Schritt bestätigen muss. Entscheidend ist die Position der Freigabe. Sie sollte dort sitzen, wo eine falsche Entscheidung relevante Folgen hätte: vor einer Zahlung, vor dem Versand sensibler Informationen oder vor einer irreversiblen Änderung.

Guardrails ergänzen diese Freigaben. Sie können Eingaben prüfen, Tool-Parameter begrenzen, unerlaubte Ziele blockieren oder Ausgaben validieren. Berechtigungen sollten zusätzlich technisch auf das Minimum reduziert werden. Ein Agent, der Termine lesen muss, braucht nicht automatisch das Recht, Kalender vollständig zu löschen.

Bei besonders sensiblen Prozessen sollten Regeln außerhalb des Modells durchgesetzt werden. Das Sprachmodell kann eine Aktion vorschlagen, aber eine deterministische Policy entscheidet, ob sie erlaubt ist. Damit bleibt die Sicherheitsgrenze auch dann bestehen, wenn das Modell eine unerwartete Entscheidung trifft.

Klassisches Monitoring beantwortet Fragen wie: Läuft der Dienst? Antwortet die API? Wie hoch ist die Latenz? Bei agentischen Systemen reicht das nicht. Ein technisch erfolgreicher Lauf kann fachlich trotzdem falsch sein.

Deshalb braucht es Observability auf mehreren Ebenen. Modellaufrufe, Tool-Aufrufe, Übergaben, Guardrails und Fehler sollten nachvollziehbar sein. Gleichzeitig benötigt das System Evals, die bewerten, ob das Ergebnis den fachlichen Anforderungen entspricht.

Besonders wichtig ist die Bezugsgröße. Eine niedrige Fehlerquote klingt gut, kann bei einem seltenen, aber teuren Fehler trotzdem unakzeptabel sein. Deshalb sollten technische Kennzahlen immer mit dem Geschäftsrisiko des jeweiligen Prozesses verbunden werden.

Bei Prototypen stehen meist Modellpreise im Mittelpunkt. Im Produktivbetrieb verschiebt sich die Rechnung. Ein günstiger Modellaufruf bringt wenig, wenn derselbe Vorgang wegen schlechter Tool-Auswahl dreimal wiederholt wird oder regelmäßig manuelle Nacharbeit erzeugt.

Die sinnvollste Kennzahl ist deshalb häufig Cost per Successful Run. Sie verbindet die technische Architektur direkt mit dem Prozesswert. Sinkende Tokenkosten sind nur dann ein Fortschritt, wenn Erfolgsquote, Qualität und Nacharbeit mindestens stabil bleiben.

Auch Ausfälle gehören in die Rechnung. Wenn ein Agent einen Kernprozess automatisiert, entstehen durch Fehlentscheidungen, Wartezeiten oder manuelle Rückabwicklung reale Betriebskosten. Diese Risiken sollten bereits in der Wirtschaftlichkeitsrechnung berücksichtigt werden.

• 1. Einen klar abgegrenzten Prozess und das gewünschte Geschäftsergebnis definieren.
• 2. Baseline aus dem heutigen manuellen oder automatisierten Prozess messen.
• 3. Repräsentative Testfälle und Evals aufbauen, bevor Autonomie erhöht wird.
• 4. Datenquellen, Tools und Berechtigungen nach dem Least-Privilege-Prinzip anbinden.
• 5. Fehlerpfade, Retry, Idempotenz, Limits und Eskalationen vor dem Live-Betrieb testen.
• 6. Zunächst im Shadow Mode oder mit niedriger Autonomie reale Fälle beobachten.
• 7. Autonomie und Fallzahl nur erhöhen, wenn Erfolgsquote, Kosten und Risiken innerhalb definierter Grenzen bleiben.

Der wichtigste Unterschied zu einer klassischen Demo ist die Reihenfolge: Nicht zuerst maximale Autonomie bauen und anschließend versuchen, sie zu kontrollieren. Besser ist es, Messung und Sicherheitsgrenzen zuerst zu etablieren und die Autonomie innerhalb dieses Rahmens schrittweise zu erhöhen.

Das erleichtert auch die Skalierung. Wenn Zustände, Tool-Schnittstellen, Evals und Berechtigungen sauber getrennt sind, lässt sich ein funktionierender Workflow auf weitere Teams oder Prozesse übertragen, ohne jedes Mal ein neues unkontrolliertes System zu bauen.

Agentische Systeme eröffnen Unternehmen neue Möglichkeiten, weil sie nicht nur Informationen erzeugen, sondern mit realen Systemen interagieren können. Genau dadurch steigt aber auch die Verantwortung der Architektur.

Ein guter produktiver Agent kennt nicht nur seinen nächsten Schritt. Das Gesamtsystem kennt auch seine Grenzen: welche Daten genutzt werden dürfen, welche Tools verfügbar sind, wann ein Lauf wiederholt werden kann, wann ein Mensch übernehmen muss und anhand welcher Kennzahlen Erfolg bewertet wird.

Wer diese Betriebsebene von Anfang an mitplant, muss Autonomie später nicht durch immer neue Notlösungen einfangen. Guardrails, Evals, Berechtigungen und Monitoring werden dann nicht nachträglich ergänzt, sondern sind Teil des Produkts.

Wenn Sie einen bestehenden Prozess mit KI automatisieren oder einen Prototyp in einen belastbaren Unternehmensprozess überführen möchten, entwickelt Webnity-X individuelle KI-Lösungen und Integrationen entlang Ihrer Daten, Systeme und Anforderungen.