Den ersten KI-Agenten im Unternehmen aufbauen — ein praxiserprobter Leitfaden

Die meisten Unternehmen, mit denen wir sprechen, wollen einen KI-Agenten. Fragt man, was der Agent konkret tut, bekommt man Antworten wie „er schafft alles", „er kommuniziert mit Lieferanten, verfolgt Rechnungen und plant Schichten". Genau darin liegt das Problem. Ein Agent, der alles macht, macht meistens nichts zuverlässig.

Dieser Artikel ist ein praktischer Leitfaden — keine Theorie, sondern ein Entscheidungsrahmen, den wir bei realen Einsätzen erprobt haben. Wir führen Sie von der Auswahl des ersten Use-Cases über die Definition von Tools, Guardrails und Evaluation bis hin zur schrittweisen Erweiterung des Agenten. Und wir sagen Ihnen auch, was Sie am Anfang besser vermeiden sollten.

Schritt 1: Wählen Sie einen engen, klar abgegrenzten Use-Case

Der häufigste Grund für das Scheitern des ersten Agenten ist kein technischer. Es ist ein zu breiter Scope.

Ein guter erster Use-Case erfüllt diese Kriterien:

• Klarer Ein- und Ausgang — der Agent bekommt etwas Konkretes und liefert etwas Konkretes zurück (nicht „verarbeitet eine E-Mail")
• Überprüfbarkeit des Ergebnisses — Sie oder das System können feststellen, ob der Agent das Richtige getan hat
• Abgegrenzte Tools — maximal 3–5 Tools, nicht „Zugriff auf alle Systeme"
• Tolerierbare Fehlerquote — wenn der Agent einen Fehler macht, können Sie ihn abfangen, bevor er sich auswirkt

Beispiele, die in der Praxis als erste Projekte funktionieren: Ein Agent, der jeden Morgen neue Reklamationen aus dem Helpdesk zieht, sie kategorisiert und eine Zusammenfassung in Excel oder eine Tabelle schreibt; ein Agent, der neue Bestellungen im System prüft und vorgeschriebene API-Schritte ausführt, wenn eine Bestellung definierte Bedingungen erfüllt; ein Agent, der auf Anfrage relevante Dokumentation aus der internen Bibliothek per RAG über industrielle Dokumentation abruft und eine Antwort formuliert.

Nicht empfehlenswert als erstes Projekt: ein Agent mit gleichzeitigem Zugriff auf mehrere Abteilungen, ein Agent, der ohne Aufsicht E-Mails versendet oder Rechnungen ausstellt, oder ein Agent, bei dem unklar ist, wie der Erfolg gemessen werden soll.

Schritt 2: Definieren Sie Tools — nicht „was der Agent kann", sondern „was der Agent darf"

Tools sind das Herzstück des Agenten. Ein Agent ohne Tools ist nur ein Chatbot; ein Agent mit zu weit gefassten Tools ist ein Sicherheitsrisiko.

Bei der Definition von Tools denken Sie in zwei Schritten:

Was braucht der Agent physisch? - Lesen (Datenbank, API, Dateien, Vektor-DB) - Schreiben (Datensatz aktualisieren, Nachricht senden, in System schreiben) - Berechnen oder transformieren (Format konvertieren, zusammenfassen, klassifizieren)

Was bekommt der Agent die Erlaubnis zu tun? Dies ist der kritische Schritt, der übersprungen wird. Jedes Tool braucht einen expliziten Scope: Der Agent darf Einträge aus Tabelle X lesen, aber nicht löschen. Er darf API-Endpoint Y mit einem Read-only-Schlüssel aufrufen. Er darf in Abschnitt Z schreiben, aber keine historischen Einträge ändern.

Eine gute Faustregel für den ersten Agenten: Write-Operationen nur über ein HITL-Gate — also mit menschlicher Freigabe vor der Ausführung. Human-in-the-Loop bei Agenten ist keine komplexe Architektur; in LangGraph ist es ein einziger interrupt()-Aufruf. Das erhöht die Latenz um die Zeit der menschlichen Reaktion, verhindert aber irreversible Fehler.

Das Schema jedes Tools muss maschinell validierbar sein. Wenn der Agent ein malformiertes JSON als Tool-Argument zurückgibt, müssen Sie das abfangen und wiederholen — nicht stillschweigend ignorieren. Das ist kein Edge Case; in der Produktion ist das eine häufige Fehlerquelle.

Schritt 3: Wählen Sie eine einfache Architektur

Für den ersten Agenten empfehlen wir die ReAct-Schleife — Reason, Act, Observe in einem einfachen Graphen. Der Grund ist schlicht: Es ist die am besten debuggbare Architektur.

Wer den Artikel Architekturen von KI-Agenten gelesen hat, weiß, dass es ausgefeiltere Muster gibt (Plan-and-Execute, Reflexion, Multi-Agent). Diese sind valide — aber nicht für das erste Projekt. Jeder zusätzliche Schritt ist eine weitere potenzielle Fehlerquelle und eine weitere Schicht, in der man nicht sieht, was passiert.

Konkret empfohlener Stack:

• Framework: LangGraph — graphbasiert, expliziter Zustand, eingebautes Checkpointing; produktionserprobt für Enterprise-Einsätze
• Modell: Beginnen Sie mit einem günstigen, schnellen Modell (Haiku-Tier, Flash-Tier oder lokales Modell via Ollama); Frontier-Modelle (Opus, GPT) aktivieren Sie erst, wenn die Grundlogik funktioniert
• Speicher: Kurzfristiger Kontext im Graphzustand; für längere Horizonte eine Vektor-DB — aber nur, wenn der erste Use-Case das wirklich erfordert

Ein häufiger Fehler am Anfang: Das leistungsstärkste und teuerste Modell wählen, weil man „die besten Ergebnisse will", und sich dann wundern, warum die Kosten untragbar sind. Das Modell lässt sich leicht austauschen. Architektur und Tools sind weit schwieriger zu ändern.

Ein praktisches Detail: Legen Sie eine maximale Anzahl von Schleifendurchläufen fest. Ein Agent ohne Limit kann bei unerwarteten Eingaben in eine Schleife geraten und über Nacht Tausende von Tokens verbrauchen. Ein Wert von 10–15 Schritten pro Aufgabe ist ein vernünftiger Einstieg für die meisten Use-Cases.

Schritt 4: Guardrails — nicht als Filter, sondern als Architektur

Guardrails für KI-Agenten ist ein Thema, das beim ersten Projekt unterschätzt wird und später schmerzhaft nachgeholt werden muss.

Guardrails sind nicht nur ein Ausgangsfilter („prüfe, ob die Antwort nichts Schädliches enthält"). Guardrails sind eine mehrschichtige Architektur:

1. 1.Eingangsvalidierung — was gelangt in den Agenten? Ist das das Format, das der Agent erwartet? Enthält die Eingabe potenziell gefährliche Anweisungen?
2. 2.Intent Classification — wenn der Agent Freitext von Benutzern erhält, muss die Absicht vor der Übergabe an die Agentenschleife klassifiziert werden
3. 3.Tool Permission Scope — wie oben beschrieben: jedes Tool hat Berechtigungen
4. 4.HITL-Gate für Write-Operationen — kritische Aktionen erfordern menschliche Bestätigung
5. 5.Ausgangsfilter — semantische Prüfung der Antwort vor dem Senden

Für den ersten Agenten in einer internen Umgebung (nicht externen Benutzern ausgesetzt) reicht es, mit Punkten 3 und 4 zu beginnen. Eingangsvalidierung und Intent Classification sind unerlässlich, wenn der Agent Eingaben von externen oder unbekannten Quellen erhält.

Prompt Injection — also ein Angriff, bei dem gefährliche Inhalte in der Eingabe den Agenten dazu bringen, etwas anderes zu tun als vorgesehen — ist laut OWASP LLM Top 10 die häufigste Sicherheitsbedrohung bei KI-Anwendungen. Wenn Ihr Agent externe Inhalte lädt (E-Mails, Webseiten, Kundendateien), müssen Sie dieses Risiko aktiv einkalkulieren.

Schritt 5: Observability — ohne sie lassen Sie den Agenten nicht in die Produktion

Das ist eine Regel, von der wir nicht abrücken: Ein Agent ohne Observability ist kein Produktionsagent. Er ist ein Proof-of-Concept.

Was Sie über jeden Agentenlauf konkret wissen müssen:

• Was war der Ein- und Ausgang
• Wie viele Schleifendurchläufe haben stattgefunden
• Welche Tools wurden aufgerufen, mit welchen Argumenten, was haben sie zurückgegeben
• Wo ist ein Fehler aufgetreten (falls zutreffend) und warum hat der Agent eine bestimmte Aktion gewählt

Tools, die das bieten: Langfuse (framework-agnostisch, self-hostable), LangSmith (tiefe Integration mit LangGraph), Arize Phoenix (OpenTelemetry-basiert, erweiterte Eval-Metriken). Observability von KI-Agenten ist heute ein ausgereifter Bereich — es gibt keinen Grund, das von Grund auf selbst zu bauen.

Konkreter Nutzen in der Praxis: Bei einem Einsatz für einen Kunden aus der Logistik haben wir über Traces festgestellt, dass der Agent 94 % der Fälle korrekt kategorisierte, bei einer Kategorie aber konsistent ein Tool mit einem fehlerhaften Argument aufrief. Ohne Observability hätten wir das erst nach Dutzenden fehlerhafter Einträge im System bemerkt.

Schritt 6: Eval — woher wissen Sie, dass der Agent richtig funktioniert?

Eval (Evaluierung) ist der Schritt, der beim ersten Projekt am häufigsten übersprungen wird. Die Folge: Man weiß nicht, ob eine Änderung am Prompt, am Modell oder an den Tools die Dinge verbessert oder verschlechtert hat.

Für den ersten Agenten reicht ein einfacher Eval-Harness:

• Erstellen Sie 20–50 Testfälle mit definiertem Eingang und erwartetem Ausgang oder erwarteter Aktion
• Führen Sie den Agenten nach jeder größeren Änderung über diese Fälle aus
• Verfolgen Sie mindestens zwei Metriken: Task Completion Rate (hat der Agent die Aufgabe abgeschlossen?) und Tool Call Accuracy (hat der Agent die richtigen Tools mit den richtigen Argumenten aufgerufen?)

Sie müssen nicht sofort ein komplexes Eval-Framework einsetzen. Ein Skript, das den Agenten über den Testset laufen lässt und ein Ergebnis ausgibt, ist besser als gar kein Eval. Wenn das System wächst, wird die Evaluierung von RAG- und LLM-Anwendungen ausgefeilter — aber die Grundlage bleibt dieselbe: einen Referenzset haben und dagegen messen.

Was beim ersten Agenten zu vermeiden ist

Aus Erfahrungen aus Einsätzen — hier sind die häufigsten Fehler, die Projekte verzögern oder stoppen:

Zu viele Tools von Anfang an. Jedes Tool ist eine weitere Fehlerquelle. Beginnen Sie mit drei, erweitern Sie auf Basis tatsächlichen Bedarfs.

Kein HITL für Write-Operationen. Der erste Write, den der Agent falsch ausführt, ohne dass er abgefangen werden kann, beendet meistens das Projekt. Fügen Sie eine Freigabe hinzu — Sie können sie später entfernen, wenn Sie Vertrauen in die Zuverlässigkeit gewonnen haben.

Multi-Agent-System als erster Schritt. Multi-Agent-Systeme in der Praxis sind sinnvoll, wenn ein Agent nicht ausreicht. Aber wenn wir noch nicht wissen, was ein Agent falsch macht, vergrößert das Hinzufügen weiterer Agenten die Verwirrung — es reduziert sie nicht.

Das Modell als Hauptvariable. Wir haben es mehrfach gehört: „Wir probieren GPT-5, das löst bestimmt die Probleme." In der Praxis kommen die meisten Probleme aus einer schlechten Tool-Definition, fehlender Validierung oder unklarem Scope — nicht aus der Modellqualität. Lösen Sie die Architektur, nicht das Modell.

Keine maximalen Limits. Ein Agent ohne Limit für die Anzahl der Schritte, ohne Timeout und ohne Cost-Alert kann über Nacht Tausende von Aufrufen generieren. Setzen Sie Limits vom ersten Tag an.

Schrittweise Erweiterung: vom Prototyp zur Produktion

Der erste funktionsfähige Agent ist ein Prototyp. Der Weg in die Produktion erfordert mehrere explizite Schritte:

1. 1.Eval über Testset — mindestens 20–50 Fälle, Task Completion Rate > 85 % als Mindestbedingung
2. 2.Shadow Mode — der Agent läuft parallel zum bestehenden Prozess, greift aber nicht ein; Sie vergleichen die Ausgaben
3. 3.HITL für alle Write-Operationen — in der ersten Produktionsphase genehmigt ein Mensch jede Aktion
4. 4.Observability live — Traces müssen vom ersten Tag in der Produktion verfügbar sein
5. 5.Schrittweise Reduzierung von HITL — nach 2–4 Wochen mit guten Metriken können Sie HITL für risikoarme Aktionen entfernen

Die Erweiterung des Scope (neue Tools, neue Use-Cases) ist immer eine Iteration desselben Zyklus: definieren, im Shadow Mode testen, schrittweise einführen, Metriken beobachten.

Häufige Fragen

Welches Modell für den ersten Agenten wählen?

Beginnen Sie mit einem günstigen, schnellen Modell — Haiku- oder Flash-Tier, oder ein lokales Open-Weight-Modell wie Ollama mit Qwen oder Llama. Frontier-Modelle (Opus, GPT) aktivieren Sie erst, wenn die Grundlogik funktioniert und Sie genau wissen, wo das Modell nicht ausreicht. Das Modell lässt sich leicht austauschen; die Architektur nicht.

Wie viele Tools kann der erste Agent haben?

Wir empfehlen maximal 3–5 Tools in der ersten Version. Jedes Tool ist eine weitere Fehlerquelle und eine weitere Sache, die getestet werden muss. Besser drei gut getestete Tools als zehn mit unklaren Grenzen.

Muss ich LangGraph oder ein anderes Framework verwenden?

Es ist keine Pflicht. Eigener Code bietet volle Kontrolle und manchmal weniger Abstraktion, als benötigt wird. Der Grund, warum wir LangGraph für erste Produktionseinsätze empfehlen, ist das eingebaute Checkpointing, HITL interrupt() und gute Traces — diese Dinge baut man sich sonst von Grund auf selbst.

Wann ergibt der Wechsel zu einer Multi-Agent-Architektur Sinn?

Wenn ein einzelner Agent konsistent nicht mitkommt — typischerweise wegen eines zu großen Aufgaben-Scope oder des Bedarfs an Parallelverarbeitung. Wenn ein Agent sequenziell 15 Schritte ausführt, von denen einige parallel laufen könnten, ist es Zeit für einen Multi-Agent-Ansatz. Aber das ist das zweite oder dritte Projekt, nicht das erste.

Wie schätzt man die Produktionskosten eines Agenten?

Die entscheidende Variable ist nicht nur der Modellpreis, sondern auch die Anzahl der Schleifendurchläufe pro Aufgabe und die Retry-Rate. Wenn der Agent im Durchschnitt 5 Schritte ausführt und die Retry-Rate 12 % beträgt, ist die tatsächliche Anzahl der Aufrufe um 12 % höher — und bei mehrstufigen Pipelines multipliziert sich dieser Overhead weiter. Einen detaillierteren Rahmen zur Kostenschätzung finden Sie im Artikel Kosten eines KI-Agenten in der Produktion.

*MP Industrial Solutions hilft Unternehmen dabei, den ersten KI-Agenten zu definieren, zu entwerfen und einzuführen — von der Auswahl des Use-Cases über die technische Architektur bis hin zum Produktionseinsatz mit Observability und Guardrails. Wenn Sie den ersten Schritt erwägen, besprechen wir Ihren konkreten Fall gerne in einem Erstgespräch.*