KI-Agenten erstellen ohne Entwickler: Schritt für Schritt

Die meisten KI-Agenten scheitern nicht an der Technik. Sie scheitern daran, dass niemand vorher aufgeschrieben hat, was der Agent eigentlich tun soll.

Ich baue seit knapp zwei Jahren Agenten für unsere eigenen Brands nano, mate und MUSTAX. Programmieren kann ich nicht besonders gut. Was ich kann: eine Aufgabe so klein schneiden, dass eine Maschine sie zuverlässig erledigt. Genau darum geht es hier. Sechs Schritte, zwei durchgerechnete Beispiele und eine Liste, wofür du besser keinen Agenten baust.

Wenn du noch nicht sicher bist, was ein Agent überhaupt von einem Chatbot unterscheidet: Das steht in Was ist ein KI-Agent. Hier setze ich voraus, dass du das grob kennst.

Schritt 1: Schneide die Aufgabe so eng wie möglich

Der häufigste Fehler ist der Wunsch nach einem Agenten, der "den Support macht". Das ist keine Aufgabe, das ist eine Abteilung.

Eine brauchbare Aufgabe erkennst du an drei Dingen. Sie hat einen klaren Auslöser. Sie hat ein klares Ergebnis. Und du kannst in einem Satz sagen, wann sie schiefgegangen ist.

Beispiel für schlecht geschnitten: "Beantworte Kundenanfragen."

Beispiel für gut geschnitten: "Wenn eine Mail nach dem Paketstatus fragt, hole den Tracking-Stand und schreibe eine Antwort mit echtem Liefertermin."

Der zweite Satz ist testbar. Der erste nicht.

Für den Zuschnitt nehme ich immer die letzten 50 echten Fälle. Nicht die, die ich mir vorstelle. Die, die wirklich reingekommen sind. Dann sortiere ich sie nach Häufigkeit. Der oberste Stapel ist dein erster Agent, alles andere kommt später oder nie.

Bei uns war dieser oberste Stapel die Frage "Wo ist mein Paket". Sie macht rund 40 Prozent aller Support-Anfragen aus. Ein Agent, der nur diesen einen Fall kann, nimmt dir also schon fast die Hälfte der Arbeit ab.

Schritt 2: Lege fest, welche Daten der Agent sehen darf

Ein Agent ist nur so gut wie sein Zugang zu deinen Systemen. Und nur so sicher wie die Grenzen dieses Zugangs.

Schreib zwei Listen auf, bevor du irgendetwas verbindest:

• Lesen darf er: Bestellungen, Tracking-Status, Produktdaten, Versandrichtlinien, FAQ-Texte.
• Schreiben darf er: einen Antwortentwurf, einen internen Vermerk. Sonst nichts.

Diese Trennung ist der wichtigste Sicherheitsgurt im ganzen Projekt. Ein Agent, der nur lesen und Entwürfe schreiben kann, richtet im schlimmsten Fall Verwirrung an. Ein Agent mit Schreibrechten auf Erstattungen richtet im schlimmsten Fall Schaden an.

Praktisch heißt das: eigener API-Zugang für den Agenten, nicht dein Admin-Login. In Shopify legst du dafür eine eigene App an und gibst ihr genau die Rechte aus deiner Leseliste. Dauert zwanzig Minuten und erspart dir später eine sehr unangenehme Stunde.

Schritt 3: Gib ihm Werkzeuge, nicht Wissen

Das ist der Punkt, an dem die meisten Selbstbau-Versuche kippen. Man schreibt dem Modell die Versandbedingungen in den Prompt, also in die Anweisung, und wundert sich, dass es zwei Wochen später falsche Fristen nennt.

Die Regel: Alles, was sich ändern kann, gehört hinter ein Werkzeug und nicht in die Anweisung.

Ein Werkzeug ist ein Aufruf, den der Agent selbst auslösen kann. "Hole Bestellung nach Bestellnummer." "Hole Tracking-Status nach Sendungsnummer." "Schlag den Text der Retourenrichtlinie nach." Der Agent entscheidet, welches er braucht, und bekommt die Antwort frisch aus dem System.

In n8n baust du solche Werkzeuge als eigene Knoten und hängst sie an den Agenten-Knoten. Wenn du n8n noch nie angefasst hast, geh vorher einmal durch deinen ersten n8n-Workflow. Der Agent ist danach nur noch ein weiterer Baustein.

In der Anweisung selbst steht nur, was sich nie ändert: die Rolle, der Ton, die Grenzen. Bei uns sind das ungefähr 30 Zeilen. Wer 300 Zeilen Prompt braucht, hat meistens ein Werkzeug vergessen.

Schritt 4: Schreib die Testfälle, bevor du den Agenten baust

Das fühlt sich falsch herum an und ist trotzdem die Abkürzung.

Nimm zehn bis fünfzehn echte Fälle aus Schritt 1 und schreib zu jedem auf, was die richtige Antwort wäre. Drei Sorten müssen dabei sein:

• Der Normalfall. Paket unterwegs, Termin bekannt.
• Der Randfall. Zwei offene Bestellungen, Kundin nennt keine Nummer.
• Der Fall, der eskalieren muss. Paket seit zehn Tagen ohne Bewegung, Kunde ist wütend.

Diese Liste ist deine Abnahme. Der Agent ist fertig, wenn er alle Normalfälle richtig löst, alle Randfälle sauber nachfragt und alle Eskalationsfälle abgibt, statt zu improvisieren.

Ohne diese Liste passiert immer dasselbe: Du testest drei Fälle, es sieht gut aus, du schaltest live, und in Woche zwei antwortet der Agent einer Kundin mit dem Tracking-Stand einer fremden Bestellung.

Schritt 5: Baue die Freigabe ein, nicht davor

Der erste Betrieb läuft nie ohne Mensch. Bei uns gab es drei Stufen, und ich empfehle jedem denselben Weg.

Der Sprung von Stufe 1 auf 2 kommt erst, wenn du eine Woche lang keinen Entwurf mehr korrigieren musstest. Nicht früher. Und die Eskalationsregeln bleiben hart: Erstattungen, Adressänderungen und alles Emotionale gehen bei uns bis heute an Menschen.

Schritt 6: Betrieb ist der eigentliche Aufwand

Ein Agent ist kein Projekt mit Enddatum. Er ist ein Mitarbeiter, der nie von selbst sagt, dass etwas nicht mehr stimmt.

Drei Dinge brauchst du dauerhaft:

• Ein Protokoll. Jeder Durchlauf mit Eingabe, genutzten Werkzeugen und Ausgabe. Ohne das kannst du Fehler nicht nachvollziehen.
• Eine wöchentliche Stichprobe. Zehn Fälle lesen, zehn Minuten. Wir machen das freitags.
• Ein Notaus. Ein Schalter, der den Agenten sofort auf Entwurfsmodus zurückstellt. Du brauchst ihn selten und dann sehr dringend.

Was der laufende Betrieb kostet, hängt vor allem an den Modell-Aufrufen. Eine Rechnung mit allen Posten steht in Was Automatisierung wirklich kostet.

Beispiel 1: Der Paketstatus-Agent bei nano

Aufgabe: Anfragen nach dem Lieferstatus beantworten.

Auslöser ist eine eingehende Support-Mail, die als Statusfrage erkannt wurde. Die Vorsortierung macht ein einfacher Klassifizierer davor, kein Agent. Warum wir das trennen, steht in Support-Mails mit KI vorsortieren.

Werkzeuge: Bestellung suchen, Tracking-Status holen, Versandrichtlinie nachschlagen.

Ablauf: Der Agent sucht die Bestellung über Mailadresse oder Bestellnummer. Findet er zwei offene Bestellungen, fragt er nach, statt zu raten. Er holt den Tracking-Stand, vergleicht ihn mit dem versprochenen Termin und schreibt die Antwort.

Eskalation: Steht die Sendung seit mehr als sieben Tagen still, antwortet er nicht. Er legt den Fall mit Vermerk vor.

Aufwand: knapp drei Tage Aufbau, davon ein halber Tag für die Testfälle. Ergebnis: Diese eine Anfrageart läuft heute ohne uns. Zusammen mit den anderen automatisierten Fällen beantwortet die KI rund 65 Prozent unserer Support-Anfragen.

Beispiel 2: Der Reporting-Agent bei MUSTAX

Aufgabe: Die Montagszahlen zusammenstellen und Auffälligkeiten benennen.

Werkzeuge: Umsatz je Kanal abfragen, Retourenquote abfragen, Lagerbestand abfragen, Vorwoche abrufen.

Ablauf: Der Agent holt die Zahlen, vergleicht mit der Vorwoche und schreibt einen kurzen Text. Kein Dashboard. Fünf Sätze plus eine Tabelle. Was auffällt, benennt er zuerst.

Grenze: Er darf keine Ursache behaupten. Er schreibt "Retourenquote bei Modell A von 8 auf 14 Prozent gestiegen", nicht "wegen der neuen Größenangabe". Ursachen erfindet ein Sprachmodell nämlich gerne und überzeugend.

Das Reporting hat bei MUSTAX früher 2 Tage gekostet. Heute sind es 2 Stunden, und die zwei Stunden sind das Lesen und Entscheiden, nicht das Zusammensuchen.

Wofür ein Agent die falsche Wahl ist

Das ist der Abschnitt, den ich mir vor zwei Jahren gewünscht hätte.

• Für feste Wenn-dann-Ketten. Bestellung kommt rein, Label wird erzeugt, Kunde bekommt Mail. Da ist ein Agent langsamer, teurer und schlechter nachvollziehbar als ein normaler Workflow. Unsere Bestellabwicklung läuft bewusst ohne Agenten.
• Für Geld ohne Kontrolle. Erstattungen, Gutschriften, Zahlungsfreigaben. Technisch ginge es. Aber du haftest am Ende.
• Für seltene Aufgaben. Was zweimal im Quartal vorkommt, lohnt weder Aufbau noch Pflege.
• Für Prozesse, die du selbst nicht beschreiben kannst. Wenn drei Leute im Team drei verschiedene Antworten geben, wie der Fall zu lösen ist, dann ist der Prozess das Problem, nicht die fehlende KI.
• Für alles, wo eine falsche Antwort teuer ist und nicht auffällt. Ein Workflow scheitert laut. Ein Agent scheitert manchmal leise und höflich.

Die Entscheidung zwischen Agent, Chatbot und Workflow haben wir ausführlich in KI-Agent, Chatbot oder Workflow aufgeschrieben.

Fazit

Ein KI-Agent ohne Entwickler ist machbar. Der Aufwand liegt aber nicht dort, wo du ihn vermutest.

Der Bau in n8n dauert einen bis drei Tage. Der Zuschnitt der Aufgabe, die Testfälle und die Freigabestufen dauern länger und entscheiden, ob das Ding taugt. Wer diese Reihenfolge dreht, baut schnell etwas, das beeindruckend aussieht und im Betrieb nicht hält.

Fang mit einer Anfrageart an. Nimm die häufigste. Lass ihn zwei Wochen nur Entwürfe schreiben. Danach weißt du mehr über deine eigenen Prozesse als aus jedem Workshop.

Falls du unsicher bist, ob deine Aufgabe überhaupt ein Agent sein sollte: Schreib uns bei Flowhouse. Wir sagen dir auch, wenn ein simpler Workflow reicht.