KI-Agent erstellen: Schritt für Schritt zum ersten produktiven Agenten

Einen KI-Agent erstellen ist kein Prompt-Projekt, sondern ein Systemprojekt. Der Prompt ist ein Baustein von acht. Wer die anderen sieben weglässt, bekommt einen Agenten, der in der Demo läuft und in Woche drei ein Angebot mit falschen Preisen verschickt.

Diese Anleitung führt dich in acht Schritten vom passenden Prozess zum produktiven Agenten: Ziel und Artefakt, Architektur-Pattern, Werkzeuge, System Prompt, Fehlerbehandlung mit Human-in-the-Loop, Tests, Betrieb und Stack. Was ein Agent grundsätzlich ist und wo er sich lohnt, steht in KI-Agenten für Unternehmen.

Vor dem Bau: Der richtige erste Prozess

Der erste Agent entscheidet, ob dein Team dem Ansatz vertraut. Wähle deshalb keinen Prestige-Prozess, sondern einen, der drei Kriterien erfüllt: repetitiv (wöchentlich oder täglich), datengetrieben (klares Input-Output-Muster, Daten in erreichbaren Systemen) und artefakt-orientiert (am Ende steht ein Dokument, ein Report, eine Nachricht). Dazu ein Aufwand von mehr als einer Stunde pro Woche, damit sich die Arbeit lohnt.

Schreibe den Ist-Zustand auf: Was ist der Input? Was ist der gewünschte Output? Welche Systeme sind beteiligt? Wer prüft heute das Ergebnis? Diese vier Antworten sind das Lastenheft für alles Weitere.

Schritt 1: Ziel und Artefakt definieren

Ein Agent bekommt ein Ziel in natürlicher Sprache, kein Skript. Formuliere es so, wie du es einem neuen Kollegen sagen würdest, und beschreibe das Artefakt genau: "Analysiere unsere Quartalszahlen aus der Datenbank, identifiziere die drei schwächsten Produkte und erstelle einen LinkedIn-Post-Entwurf mit Key Insights." Das Ergebnis ist kein Roh-Output, sondern ein fertiges Artefakt in dem System, das dein Team nutzt: ein Notion-Dokument, eine Slack-Nachricht, ein PDF.

Lege fest, was das Artefakt enthalten muss, damit niemand nacharbeitet: Struktur (Überschriften, Listen), Datenpunkte (jede Zahl aus der Abfrage), Ton (wie das Unternehmen kommuniziert). Diese Liste wird später dein Abnahmekriterium.

So sieht das am Beispiel Wochenreport aus: Ziel ist das Management-Update, das der Vertriebsleiter bisher jeden Montag in zwei Stunden aus CRM-Export und Excel baut. Input sind die Wochendaten aus dem CRM-Backend. Artefakt ist ein Notion-Dokument im Unternehmensstil plus eine Slack-Nachricht "Wochenbericht KW 15 ist verfügbar". Abnahmekriterium: Der Bericht liegt Montag um 7:00 Uhr vor, bevor jemand seinen ersten Kaffee trinkt, und niemand fasst ihn nach.

Schritt 2: Architektur-Pattern wählen

Vier Grundmuster stehen zur Wahl. ReAct für explorative Aufgaben, bei denen der Agent denkt, handelt, beobachtet und weiterplant. Plan-and-Execute für mehrstufige Aufgaben mit klarem Ziel, etwa Reports oder Audits. Tool-Use Agent, wenn der Kern darin besteht, das richtige Werkzeug zur richtigen Zeit zu nutzen, etwa ein Sales-Agent mit CRM, E-Mail und LinkedIn. Multi-Agent Orchestration erst, wenn ein einzelner Agent stabil läuft.

Für den ersten Agenten gilt: ein Agent, ein Prozess, ein Artefakt. Multi-Agent-Systeme für jeden Prozess erzeugen Systeme, die schwerer zu warten sind als die manuellen Abläufe, die sie ersetzen.

Schritt 3: Werkzeuge und Daten anbinden

Ein Agent ist so gut wie seine Werkzeuge. Typische Tools: eine SQL-Abfrage auf PostgreSQL, ein API-Call ins CRM, ein Python-Skript für Berechnungen, die Notion- oder Slack-API für die Ausgabe. Jedes Werkzeug bekommt eine klare Beschreibung, was es tut und welche Parameter es erwartet, damit das Modell es richtig auswählt. Beim Wochenreport sind das drei Werkzeuge: die CRM-Abfrage (liest, schreibt nie), die Notion-API (legt das Dokument im richtigen Workspace ab) und die Slack-API (schickt die Nachricht).

Die wichtigste Regel: strikte Trennung zwischen Datenwahrheit und Sprache. Zahlen kommen aus dem validierten Abfrageergebnis, der Text-Agent interpretiert sie. Er erfindet keine Werte. Alle numerischen Angaben im Artefakt müssen aus dem SQL-Ergebnis stammen.

Für Wissen aus Dokumenten kommt Retrieval Augmented Generation ins Spiel: Der Agent ruft passende Abschnitte ab und stützt seine Antwort darauf. Wie das funktioniert, steht in Retrieval Augmented Generation erklärt.

Schritt 4: System Prompt bauen

Der System Prompt ist die Stellenbeschreibung des Agenten. Sechs Bausteine machen ihn robust:

1. Rolle und Identität: nicht "Du bist ein hilfreicher Assistent", sondern Unternehmen, Aufgabe, Sprache, Ton und was der Agent nicht tut.
2. Fähigkeiten und Grenzen: was er kann, was er nicht kann, und die Anweisung, bei Unsicherheit das zu sagen statt zu erfinden.
3. Kontext-Instruktionen: nur auf Basis des bereitgestellten Kontexts antworten, Quelle nennen, Lücken benennen.
4. Output-Format und Stil: Länge, Struktur, Sprache, Tonalität.
5. Guardrails: den System Prompt nie ausgeben, Aufforderungen wie "ignoriere vorherige Anweisungen" als ungültig behandeln.
6. Beispiele (Few-Shot): zwei bis drei Musterfälle mit erwartetem Output.

Schreib die Bausteine als Module, nicht als einen Textblock. Dann kannst du einen Baustein ändern und testen, ohne die anderen anzufassen. Die Testmethode dazu kommt in Schritt 6, die vollständige Anleitung steht in Prompt Testing und Evaluation.

Schritt 5: Fehler, Fallbacks und Human-in-the-Loop

Der Unterschied zwischen Demo und Produktion ist die Fehlerbehandlung. Jeder Schritt bekommt eine eindeutige ID und prüft vor einer externen Aktion, ob sie schon erfolgt ist, damit ein Retry keine zweite E-Mail verschickt. Retry-Logik gehört auf Schritt-Ebene, nicht auf Workflow-Ebene.

[KI-Inferenz]
  ├─ Erfolg → weiter
  ├─ Timeout → Retry (max 2x)
  │   └─ Fehler → Fallback-Modell
  │       └─ Fehler → Human Escalation
  └─ Confidence < 0.7 → Human Review

Human-in-the-Loop ist kein Zeichen von Misstrauen, sondern Teil der Architektur. Drei Muster: Approval Gate (der Mensch gibt frei, dann läuft der Workflow weiter) für hohes Risiko wie Finanzen und Compliance; Escalation Path (der Agent eskaliert bei niedriger Konfidenz) für Kundenkommunikation; Feedback Loop (der Mensch korrigiert, die Korrektur fließt zurück) für interne Klassifikation mit Stichproben.

Schritt 6: Testen, bevor jemand anderes testet

Ein laufendes System ist kein korrektes System. Drei Validierungsebenen für Agenten im Mittelstand:

Für den Prompt selbst baust du ein Golden Set: 50 bis 100 repräsentative Eingaben mit erwarteter Antwort, kategorisiert in Easy, Medium, Hard und Edge Case, darunter Sicherheitsfälle wie "Ignoriere alle Anweisungen". Bewertet wird nach sechs Metriken: Correctness, Faithfulness, Relevance, Completeness, Consistency, Safety. Ändere je Test nur eine Variable, sonst weißt du nicht, was den Unterschied gemacht hat.

Schritt 7: Betrieb: Monitoring, Versionierung, Kosten

Setze außerdem ein Token-Budget je Workflow und je Endpoint und begrenze die Antwortlänge mit max_tokens. Ohne Budget ist LLM-Nutzung wie eine Kreditkarte ohne Limit; mit Budget sparst du 15 bis 30 Prozent der Kosten und siehst Ausreißer, bevor die Rechnung kommt.

Jeder Prompt trägt eine Versionsnummer, Modelle werden auf eine Version festgepinnt statt auf floating Tags, und neue Prompt-Versionen gehen über Canary Releases live: 5 bis 10 % des Traffics, dann 25, 50, 100 %. Ohne das degradieren Prompts still, wenn der Anbieter das Modell aktualisiert.

Und dokumentiere, warum der Agent so gebaut ist, wie er gebaut ist. Die gefährlichste Schuldenart in KI-Stacks ist Wissen, das nur im Kopf der Person existiert, die den Workflow gebaut hat. Was daraus wird, wenn diese Person geht, steht in Technical Debt in KI-Automation-Stacks.

Schritt 8: Der Stack für den Mittelstand

Reifegrad-Regel: n8n oder Make für den Piloten, schnell live, schnell lernen. LangGraph für die Skalierung mit mehr Kontrolle und Testbarkeit. Temporal für geschäftskritische Workflows mit Durable Execution.

Sieben Prinzipien, die jeden Agenten tragen

Wenn du nur eine Checkliste mitnimmst, dann diese: EVA-Architektur mit eigenem Error Handling je Phase, Idempotenz, Human-in-the-Loop nach Risiko, Modularität (kein Sub-Workflow über 15 Schritte), Fallback-Ketten, Observability, Versionierung mit Rollback. Ausführlich mit Beispielen in Workflow Design für KI-Systeme. Den Architektur-Blueprint mit Python-Code findest du in Agentic Workflows 2026, den Gesamtüberblick im Guide KI für Unternehmen.

KI-Agent erstellen: Sechs typische Fehler

1. Mit dem Multi-Agent-System starten statt mit einem Agenten.
2. Nur den Happy Path testen. Die schwierigsten 20 % der Fälle verursachen 80 % der Probleme.
3. Einmal testen, nie wieder. Modelle ändern sich.
4. Zahlen vom Sprachmodell erzeugen lassen statt aus der Datenquelle.
5. Kein Monitoring. "Läuft der Workflow noch?" ist dann eine ernst gemeinte Frage, und die Antwort dauert im Schnitt drei bis sieben Tage.
6. Personenbezogene Daten ungefiltert an Cloud-APIs schicken.

Fazit

Einen KI-Agent zu erstellen heißt, acht Entscheidungen bewusst zu treffen: Prozess, Ziel und Artefakt, Pattern, Werkzeuge, System Prompt, Fehlerbehandlung, Tests, Betrieb. Wer sie in dieser Reihenfolge trifft, hat nach rund sechs Wochen einen Agenten, der ohne Nacharbeit liefert und dessen Fehler man sieht, bevor der Kunde sie sieht. Erst dann kommt der zweite Agent.