So bauen Sie einen produktionsreifen AI-Agenten

Was ein produktionsreifer AI-Agent tatsächlich ist

Ein Chatbot antwortet; ein Agent bringt es zu Ende. Diese Unterscheidung bestimmt alles Weitere:

• Ein Chatbot gibt Text zurück und überlässt die Arbeit einem Menschen.
• Ein Agent nimmt ein Ziel entgegen, schlussfolgert entlang Ihrer Geschäftsregeln, ruft Werkzeuge auf, schreibt das Ergebnis in Ihre führenden Systeme und bezieht einen Menschen nur an den Freigabepunkten ein, die Sie festlegen.
• Die Demo braucht ein Modell, einen Prompt und ein paar Werkzeuge. Auf dem Idealpfad und vor Publikum wirkt sie überzeugend.
• Der Produktivbetrieb braucht zusätzlich Leitplanken, Integrationen und eine Verbesserungsschleife — im Produktivbetrieb wohnen das kaputte PDF und die überraschende API-Änderung des Anbieters. Die Demo ist die einfachen 20 %. Dieser Artikel handelt von den anderen 80.

Um konkret zu bleiben, bauen wir einen Agenten durchgängig auf — einen hypothetischen Agenten für die Rechnungsverarbeitung für ein Finanzteam im Mittelstand:

• Alle folgenden Zahlen sind veranschaulichend, keine gemessenen Ergebnisse.
• Jedes B2B-Unternehmen betreibt diesen Prozess, und er beansprucht alle fünf Schichten.
• Derselbe Rahmen trägt einen Agenten für die Schadenbearbeitung, a Agenten für die Abrechnung im Gesundheitswesen oder einen Agenten für die Underwriting-Triage — nur Wissen, Regeln und Werkzeuge ändern sich.

Die AI-Agenten-Architektur in fünf Schichten

Lesen Sie Abb. 1 von oben nach unten. Das ist zugleich der Weg, den eine einzelne Anfrage nimmt:

• 01 · Kanäle. Wie Arbeit ankommt: E-Mail, Sprache, Chat, Dokumente. Der Agent holt die Arbeit dort ab, wo sie ohnehin landet, statt jemandem einen neuen Posteingang aufzuzwingen.
• 02 · Agenten-Kern. Eine Orchestrierungsschicht, die zwischen LLMs, Werkzeugen, Kurz- und Langzeitgedächtnis routet — und einem Agenten-Wiki: einer versionierten Wissensbasis mit Ihren Geschäftsregeln, die zur Laufzeit abgerufen wird.
• 03 · Produktivleitplanken. Prüfungen, die bei jeder Anfrage laufen, nicht in einer Testsuite: Leitplanken für Umfang und Richtlinie, Laufzeitprüfungen der Qualität und ein Gate mit Mensch im Prozess überall dort, wo eine Aktion Folgen hat.
• 04 · Ihre Systeme. Wo Aktionen landen: CRM, ERP, Schaden- oder Bestandsverwaltung, das Data Warehouse. Ergebnisse müssen diese Systeme erreichen, sonst wurde nichts automatisiert.
• 05 · Verbesserungsschleife. Jeder Modellaufruf, jeder Werkzeugaufruf, jedes Token und jeder Cent wird verfolgt. Jeder Lauf wird nach Abschluss gegen Ziele bewertet, die vor dem Start festgelegt wurden. Die Korrekturen fließen als bessere Regeln, Prompts und Wiki-Seiten in den Kern zurück.

Die sieben Bauschritte unten gehen diese Schichten der Reihe nach durch. Schritte 1 bis 3 bauen das, was Ihre Demo vermutlich schon hat. Schritte 4 bis 7 sind die Produktivschichten — und wenn Sie bereits einen Agenten betreiben, liegen dort Ihre Lücken.

Schritt für Schritt gebaut

Schritt 1 · Schicht 01 · KanäleDie Arbeit dort abholen, wo sie landet

Die Arbeit unseres Rechnungsagenten kommt auf drei Wegen an: Lieferanten-E-Mails mit PDF-Anhang, ein Portal-Upload und ein monatlicher Maschine-zu-Maschine-Datenstrom (EDI) eines großen Lieferanten. Die Entwurfsregel lautet: am Rand normalisieren:

• Unabhängig vom Kanal wird alles zum selben internen Envelope, bevor der Kern es sieht — Quelle, Zeitstempel, Rohdaten, extrahierte Anhänge.
• Eigenheiten eines Kanals, die an der Grenze behandelt werden, sickern nie in die Agentenlogik durch.

Schritt 2 · Schicht 02 · OrchestrierungStruktur vor Intelligenz

Widerstehen Sie dem einen Mega-Prompt. Unser Rechnungsagent besteht aus vier kleinen Agenten hinter einem Koordinator:

• Router. Um was für ein Dokument handelt es sich?
• Extraktor. Kopfdaten, Positionen und Summen herausziehen.
• Abgleicher. Die Bestellung finden, gegen die diese Rechnung abrechnet, und prüfen, ob beide innerhalb der Toleranz übereinstimmen.
• Ausnahmebehandlung. Entscheiden, was ein Mensch sehen muss.

Jeder hat eigene Anweisungen, Werkzeuge und Fehlerbilder, die sich isoliert testen lassen. Die eigentliche Aufgabe der Orchestrierungsschicht ist aber der Zustand:

• Ist das ERP zwei Minuten lang nicht erreichbar, setzt ein produktiver Lauf einen Checkpoint und nimmt die Arbeit wieder auf, statt von vorn zu beginnen.
• Der Haken, der fast jeden erwischt: Beim Wiederaufnehmen wird der fehlgeschlagene Schritt erneut ausgeführt — der Schreibvorgang darin muss also idempotent sein (Schritt 5 zeigt, wie).
• Checkpointing verhindert die Doppelarbeit; Idempotenz verhindert die Doppelbuchung. Sie brauchen beides, aus unterschiedlichen Gründen.
• Wählen Sie das Modell je Aufgabe. Extraktion braucht nicht Ihr teuerstes Modell; das Durchdenken einer Ausnahme vermutlich schon.

Schritt 3 · Schicht 02 · WissenGedächtnis und das Agenten-Wiki

Zwei Dinge werden „Gedächtnis“ genannt, und ein drittes ist von beiden getrennt:

• Kurzzeitgedächtnis. Laufzustand: was extrahiert wurde, welche Werkzeuge aufgerufen wurden.
• Langzeitgedächtnis. Wissen über Läufe hinweg: Dieser Lieferant schickt das PDF immer einen Tag nach Warenanlieferung, bei jenem Lieferanten stimmen die Positionstexte nie mit dem Wortlaut der Bestellung überein.
• Das Agenten-Wiki. Eine menschenlesbare, versionierte Wissensbasis Ihrer Geschäftsregeln — Seiten wie „Abgleichstoleranz: Preis innerhalb von 2 % oder ₹500, Menge exakt“ und „Frachtkosten: gegen die Rahmenbestellung abgleichen, die Fracht abdeckt“ (eine Rahmenbestellung ist ein laufender Sammelauftrag für wiederkehrende Kosten).
• Warum Klartext. Unter Versionskontrolle kann die Leitung der Finanzabteilung sie lesen, korrigieren und genau sehen, was sich geändert hat. Aus der Nachvollziehbarkeit entsteht ihr Vertrauen.

Das Wiki wird von einem LLM indexiert, und der Zeitpunkt ist entscheidend:

• Zur Entwurfszeit. Ein Modell liest jede Seite und schreibt den Index: Zusammenfassungen, Querverweise, Hinweise für den Abruf.
• Zur Laufzeit. Der Agent ruft über diesen Index ab, nicht über den Rohtext. Embeddings können Teil des Index sein, sie sind aber nicht der Index.
• Wenn sich eine Regel ändert. Der Index wird neu gebaut, damit das Wiki die einzige Quelle der Wahrheit bleibt und der Abruf günstig bleibt.

Schritt 4 · Schicht 03 · ProduktivleitplankenPrüfungen bei jeder Anfrage

Die erste Schicht, die Ihrer Demo mit ziemlicher Sicherheit fehlt — und die darüber entscheidet, ob der Agent echten Verkehr übersteht. Drei Leitplanken, alle im laufenden Betrieb:

• Leitplanken begrenzen, was der Agent überhaupt tun darf: welche Lieferanten, welche Beträge, was vollständig außerhalb des Rahmens liegt. Eine Rechnung eines unbekannten Lieferanten wird nie automatisch gebucht, Punkt.
• Laufzeitprüfungen messen die Qualität während des Laufs: Extraktionssicherheit, ob jeder extrahierte Wert tatsächlich im Quelldokument vorkommt, Latenz- und Kostenbudgets. Ein Lauf, der unter dem Zielwert liegt, läuft nicht weiter — er fällt in die Warteschlange für Menschen zurück.
• Das Gate mit Mensch im Prozess ist eine Entwurfsentscheidung und sitzt dort, wo Konsequenzen entstehen. Unser Agent bucht Rechnungen innerhalb der Toleranz unterhalb eines Schwellenwerts automatisch (die Obergrenze für automatische Buchung) und stellt den Rest mit seiner Begründung in die Warteschlange: der gefundene Abgleich, die angewandte Regel, die berechnete Sicherheit. Die prüfende Person gibt in Sekunden frei, weil der Agent das Lesen bereits erledigt hat.

Eine ehrliche Feinheit: Prüfungen im laufenden Betrieb kosten Latenz und Tokens. Backoffice-Arbeit wie die Rechnungsverarbeitung läuft asynchron und kann sich deshalb aufwendige Prüfungen bei jedem Lauf leisten. Ein latenzempfindlicher Agent prüft inline nur günstig und deterministisch und verschiebt teure Bewertung in die Schleife nach dem Lauf.

Schritt 5 · Schicht 04 · Ihre SystemeWo Aktionen landen

Die Ausgabe des Agenten ist ein Schreibvorgang, keine Nachricht: eine gebuchte Rechnung im ERP (dem führenden System für Geld und Betrieb), ein aktualisierter Lieferantensatz, eine Eingangsbestätigung per E-Mail. An der Integration sterben Agentenprojekte still — sie verdient klassische Engineering-Disziplin:

• Machen Sie jeden Schreibvorgang idempotent. Idempotenzschlüssel des Anbieters, wo die API sie unterstützt; Deduplizierung über eine externe ID oder Abfrage vor der Buchung, wo sie es nicht tut — denn die meisten ERP-APIs nehmen keinen Schlüssel entgegen.
• Machen Sie jeden Fehler laut sichtbar. Ein Werkzeug, das stumm fehlschlägt, ist die gefährlichste Komponente im ganzen System.
• Vergeben Sie Zugangsdaten je Werkzeug. Prinzip der minimalen Rechte.

Schritt 6 · Schicht 05 · ObservabilityWas Sie nicht erneut abspielen können, können Sie nicht betreiben

Jeder Modellaufruf, Werkzeugaufruf, Abruf, jede Tokenzahl und jeder Cent — pro Lauf, abfragbar:

• Der Nutzen zeigt sich beim ersten Mal, wenn der Agent etwas Überraschendes tut. Der Unterschied zwischen fünf Minuten Diagnose und einer verlorenen Woche liegt darin, ob Sie den genauen Lauf erneut abspielen können — was abgerufen wurde, was das Modell gesehen hat, was das Werkzeug zurückgab, was es gekostet hat.
• Kostenbeobachtung dient zugleich als Frühwarnsystem. Eine Prompt-Regression, die den Tokenverbrauch verdoppelt, zeigt sich am ersten Tag in den Traces — nicht erst auf der Rechnung am Monatsende.

Schritt 7 · Schicht 05 · VerbesserungsschleifeDer Teil, der sich aufsummiert

Nach jedem Lauf passieren drei Dinge:

• Bewertet gegen Ziele, die Sie vor dem Start zugesagt haben: Extraktionsgenauigkeit, Präzision der automatischen Buchung, Kosten je Rechnung, Quote manueller Eingriffe.
• Diagnostiziert aus Traces statt aus Anekdoten.
• Zurückgespielt als konkretes Artefakt — eine verschärfte Wiki-Regel, ein Prompt in neuer Version, ein angehobener Zielwert einer Prüfung, ein fehlgeschlagener Fall als Regressionstest festgepinnt, damit er nicht unbemerkt zurückkehrt.

Um beim Namen genau zu sein:

• Dies ist eine Verbesserungsschleife, angetrieben von bewerteter Erfahrung, nicht bestärkendes Lernen im Sinne des maschinellen Lernens. Keine Gewichte ändern sich.
• Was sich ändert, sind Wissen, Regeln und Prompts des Agenten — wöchentlich und belegt.
• Betreiben Sie die Schleife, dann sollte der Agent, den Ihr Team in Woche vier nutzt, messbar besser sein als der, der in Woche eins ausgeliefert wurde.
• Lassen Sie sie weg, wird der Agent still schlechter, während seine Eingaben abdriften.

Multi-Agenten-Systeme: wenn ein Agent nicht reicht

Der ehrliche Standard ist ein Agent. Wenn ein einzelner Agent mit drei Werkzeugen die Aufgabe zuverlässig erledigt, liefern Sie den aus. Teilen Sie auf, wenn ein Prompt anfängt, mehrere Aufgaben zu erledigen — Sie werden den Moment erkennen:

• Die Anweisungen werden widersprüchlich: „sei gründlich“ für die Extraktion, „sei entschlossen“ für die Verteilung.
• Die Werkzeuge werden mehr, als ein Kontext gut verkraftet.
• Ein Fehler in einem Zuständigkeitsbereich reißt die anderen mit.

Das Muster, das im Produktivbetrieb funktioniert, ist ein Koordinator plus Spezialisten — genau die Form, die unser Rechnungsagent bereits hat. Der Koordinator besitzt Zustand und Reihenfolge; jeder Spezialist besitzt eine Kompetenz. Drei Regeln halten das beherrschbar:

• Jede Übergabe ist typisiert und wird verfolgt, damit nichts als vages Bauchgefühl zwischen Agenten wandert.
• Der Zustand lebt im Zustandsobjekt des Orchestrierungs-Frameworks, nicht im Kontextfenster irgendeines Agenten.
• Jeder Spezialist lässt sich für sich bewerten und verbessern.

Behandeln Sie den Multi-Agenten-Entwurf als ganz normale technische Zerlegung.

Was im Produktivbetrieb tatsächlich bricht

Das sind die vier Grenzflächen, die wir unter Druck setzen, wenn wir einen Agenten bewerten — sie erklären die meisten Ausfälle nach dem Start, und keine davon zeigt sich in einer Demo. Eine Demo verarbeitet eine Anfrage.

• Werkzeugaufrufe. Fehlerhafte Aufrufe bei ungewöhnlichen Eingaben; Integrationen und MCP-Server, die stumm fehlschlagen, sodass der Agent auf einem Scheinerfolg weiterarbeitet. Die Rechnungsvariante: Das ERP läuft in eine Zeitüberschreitung, der erneute Versuch hat keine Deduplizierung, die Rechnung wird zweimal gebucht und ein Lieferant doppelt bezahlt.
• Kompatibilität von Modell und API. Modelle und APIs der Anbieter ändern sich unter Ihnen, und das Verhalten verschiebt sich ohne eine einzige Codeänderung auf Ihrer Seite. Pinnen Sie Versionen, prüfen Sie die Kompatibilität vor jedem Upgrade und folgen Sie im Produktivbetrieb nie automatisch „latest“. Planen Sie außerdem Budget für erzwungene Migrationen ein, denn Anbieter stellen gepinnte Snapshots nach eigenem Zeitplan ab.
• Orchestrierungszustand. Funktioniert bei einer Anfrage, driftet bei fünfzig gleichzeitigen: Wettlaufsituationen, verlorene Checkpoints, Läufe, die am falschen Schritt wieder aufsetzen. An dieser Schicht scheitert der Weg vom Piloten zum Produkt.
• Abruf und Tracing. Der Agent antwortet selbstbewusst aus einer veralteten Wiki-Seite, und ohne Traces kann niemand rekonstruieren, welches Wissen er gesehen hat. Abruffehler sehen genau wie Modellfehler aus — bis man den Trace liest.

Die Reihenfolge dieses Artikels ist die Verteidigung. Die Leitplanken fangen das Erste ab, Versionspinning und Prüfungen das Zweite, echte Orchestrierung das Dritte und die Verbesserungsschleife das Vierte. Wir führen strukturierte Produktionsreife-Assessments genau gegen diese vier Grenzflächen durch.

Bewerten Sie Ihren Agenten anhand dieser Checkliste

FAQ