KI-Agenten erstellen ohne Entwickler: Was Baukästen leisten und wo es endet

Ja, du kannst heute einen KI-Agenten erstellen, ohne programmieren zu können. In den Baukästen der großen KI-Anbieter und in vielen Arbeitsplattformen beschreibst du in normaler Sprache, was der Agent tun soll. Du lädst ein paar Dokumente hoch und verbindest ihn mit Postfach oder CRM. Nach wenigen Minuten antwortet er auf deine Testfragen erstaunlich vernünftig. Dieser Teil ist wirklich einfach geworden.

Schwer wird es danach, und das hat wenig mit Technik zu tun. Der Agent kennt deine Firma nur so gut wie die Unterlagen, die du ihm gibst. Außerdem darf er alles, was das verbundene Konto darf. Ob er bei der hundertsten echten Anfrage noch richtig liegt, weißt du erst, wenn du es geprüft hast. Und wenn sich Preise oder Zuständigkeiten ändern, arbeitet er mit dem alten Stand weiter, bis jemand ihn anpasst.

Gartner erwartet, dass bis Ende 2027 über 40 Prozent der Projekte mit KI-Agenten wieder eingestellt werden. Als Gründe nennt Gartner steigende Kosten, unklaren Nutzen und unzureichende Risikokontrollen. Keiner dieser Gründe verschwindet, nur weil sich der Agent schneller zusammenklicken lässt. Wer einen Agenten baut, der in drei Monaten noch läuft, plant deshalb die Arbeit nach dem ersten Klick gleich mit.

Was ein Baukasten dir tatsächlich abnimmt

Technisch besteht ein KI-Agent aus wenigen Teilen. OpenAI nennt in seinem Leitfaden zum Bau von Agenten drei Bausteine: das Sprachmodell, das entscheidet, die Werkzeuge, mit denen der Agent Daten abruft oder etwas auslöst, und die Anweisungen, die sein Verhalten festlegen. Anthropic beschreibt Agenten in „Building effective agents“ ähnlich nüchtern. Gemeint ist ein Sprachmodell, das in einer Schleife Werkzeuge benutzt, sich das Ergebnis jedes Schritts ansieht und dann über den nächsten Schritt entscheidet.

Ein Baukasten verpackt genau diese Teile in eine Oberfläche. Das Modell wählst du aus einer Liste. Die Anweisungen schreibst du in ein Textfeld. Werkzeuge wie Websuche, Kalender oder CRM schaltest du per Klick dazu, und die Anmeldung beim jeweiligen System läuft über ein Fenster, in dem du den Zugriff bestätigst. Früher brauchte jeder dieser Schritte einen Entwickler. Heute erledigt sie die Plattform.

Was der Baukasten dir nicht abnimmt, sind die Entscheidungen, die in diesen Feldern stehen. Das Textfeld für die Anweisungen bleibt leer, bis du weißt, wie die Aufgabe in deinem Unternehmen läuft. Und der Knopf „Postfach verbinden“ fragt nicht, ob der Agent nur lesen oder auch senden soll. Diese Entscheidungen bestimmen, ob der Agent brauchbar ist. Die folgenden Schritte gehen sie der Reihe nach durch, plattformneutral, weil sie in jedem Werkzeug dieselben sind.

Schritt 1: Eine Aufgabe, deren Ergebnis du beurteilen kannst

Der häufigste Fehler steht ganz am Anfang. Viele bauen einen Agenten, der „im Vertrieb unterstützt“ oder „Fragen zur Firma beantwortet“. So ein Ziel ist zu breit, um es zu testen, und zu vage, um daraus Anweisungen zu schreiben. Ein guter erster Agent hat eine Aufgabe, bei der du nach dem Ergebnis eindeutig sagen kannst, ob es richtig war.

Ein Beispiel, das sich durch den Rest des Textes zieht, ist ein Agent für das Service-Postfach. Er liest eingehende Kundenanfragen, ordnet sie einer Kategorie zu und beantwortet Standardfragen zu Lieferstatus, Unterlagen und Öffnungszeiten selbst. Reklamationen legt er als Vorgang an und gibt sie an die zuständige Person weiter. Bei jeder dieser Tätigkeiten kannst du nachprüfen, ob er richtig lag.

Prüf außerdem, ob du überhaupt einen Agenten brauchst. Anthropic rät ausdrücklich, mit der einfachsten Lösung zu beginnen, und schreibt, dass für viele Anwendungen ein einzelner gut gebauter Aufruf eines Sprachmodells mit den passenden Unterlagen reicht. Wenn eine Aufgabe immer gleich abläuft, ist eine feste Automatisierung billiger und berechenbarer. Ein Agent lohnt sich laut OpenAI dort, wo Regeln an ihre Grenzen stoßen, also bei Einzelfallentscheidungen, bei Regelwerken, die keiner mehr pflegen mag, und bei viel Freitext wie E-Mails oder Dokumenten. Das Service-Postfach passt, weil jede Anfrage anders formuliert ist und trotzdem zu einer begrenzten Zahl von Fällen gehört.

Schritt 2: Anweisungen aus euren bestehenden Abläufen

Die Anweisungen sind die Stellenbeschreibung des Agenten. Die meisten ersten Versionen sind zu kurz und zu allgemein, etwa „Du bist ein freundlicher Kundenservice-Agent“. Daraus kann das Modell nur raten, wie dein Unternehmen arbeitet, und es rät plausibel. Gerade das ist gefährlich, weil eine plausibel klingende falsche Antwort im Test kaum auffällt.

Besser fängst du mit dem an, was ihr schon habt. OpenAI empfiehlt, Anweisungen aus vorhandenen Arbeitsanweisungen, Gesprächsleitfäden und Richtlinien abzuleiten. Wenn euer Service ein Dokument hat, wie Reklamationen ablaufen, ist das die beste Vorlage. Wenn es dieses Dokument nicht gibt, ist das Schreiben der Anweisungen die Gelegenheit, den Ablauf zum ersten Mal aufzuschreiben. Viele Teams merken erst dabei, dass drei Kollegen dieselbe Anfrage auf drei Arten bearbeiten.

Gute Anweisungen beschreiben jeden Schritt als konkrete Handlung, etwa „Frag nach der Auftragsnummer, wenn sie fehlt“ oder „Leg bei Reklamationen einen Vorgang an und hänge die E-Mail an“. Sie regeln auch die Fälle neben dem Normalfall. Was tut der Agent, wenn eine Anfrage zwei Themen mischt? Was tut er, wenn der Kunde wütend ist oder eine Frage stellt, für die es keine Unterlage gibt? Wenn du diese Fälle nicht beschreibst, entscheidet das Modell jedes Mal neu, und zwar nicht immer gleich.

Schritt 3: Firmenkontext, der stimmt

Der Agent weiß über dein Unternehmen nur, was in seinen Anweisungen steht und was er in den hinterlegten Unterlagen findet. Die naheliegende Reaktion ist, möglichst viel hochzuladen, also das ganze Laufwerk mit allen Preislisten, Handbüchern und Präsentationen der letzten Jahre. Das verschlechtert die Antworten oft, weil sich in solchen Sammlungen alte und neue Fassungen widersprechen. Findet der Agent eine Preisliste von 2023 und eine von 2026, erkennt er nicht zuverlässig, welche gilt, und zitiert vielleicht die falsche mit voller Überzeugung.

Lädst du dagegen zu wenig hoch, füllt das Modell die Lücken mit allgemeinem Wissen. Dann klingt die Antwort richtig, passt aber nicht zu deinem Unternehmen, etwa bei Lieferzeiten, Rückgabefristen oder Zuständigkeiten. Beide Fehler vermeidest du, indem du für jedes Thema, das der Agent abdecken soll, genau eine aktuelle Quelle festlegst. Veraltete Fassungen nimmst du heraus. Und für jede Quelle steht fest, wer sie aktualisiert.

Für den Service-Agenten heißt das konkret: aktuelle Lieferbedingungen, die Reklamationsrichtlinie, eine Liste der Ansprechpartner pro Thema und eine Sammlung guter Antworten auf häufige Fragen, die echte Kollegen geschrieben haben. Das sind wenige Dokumente, aber sie stimmen. Der Aufwand liegt im Aussortieren und lohnt sich doppelt, weil auch neue Mitarbeiter von einer aufgeräumten Wissensbasis profitieren.

Schritt 4: Werkzeuge und Rechte

Wenn du einen Agenten mit einem System verbindest, bekommt er die Rechte des Kontos, über das die Verbindung läuft. Verbindest du ihn mit deinem eigenen Postfach, kann er grundsätzlich alles lesen und senden, was du lesen und senden kannst. Die OWASP-Sicherheitsliste für KI-Anwendungen führt dieses Problem als eigenes Risiko namens „Excessive Agency“. Sie nennt drei Ursachen: Ein Agent hat mehr Funktionen als nötig, weitergehende Berechtigungen als nötig oder darf folgenreiche Aktionen ohne Prüfung ausführen.

Daraus folgen drei einfache Regeln. Gib dem Agenten nur die Werkzeuge, die seine Aufgabe braucht. Wo Lesen reicht, gib nur Lesezugriff, denn ein Agent, der Mails zusammenfassen soll, braucht keine Sendefunktion. Und lass die Zugriffsrechte im angebundenen System durchsetzen statt in den Anweisungen. Ein Satz wie „Lösche niemals Kundendaten“ hilft wenig, wenn das Konto löschen darf, weil das Modell Anweisungen nicht zuverlässig befolgt. OWASP empfiehlt deshalb, die Berechtigung dort zu prüfen, wo die Aktion ausgeführt wird.

Warum das wichtig ist, erklärt der Entwickler Simon Willison mit einer Kombination, die er die „tödliche Dreierkombination“ nennt. Gefährlich wird ein Agent, wenn er Zugriff auf private Daten hat, Inhalte von Fremden liest und nach außen kommunizieren kann. Sprachmodelle folgen Anweisungen, die in Texten stehen, und sie können nicht zuverlässig unterscheiden, ob eine Anweisung von dir kommt oder in einer eingehenden E-Mail steht. Ein Angreifer kann dem Agenten also eine Mail schreiben, die ihn auffordert, interne Unterlagen an eine fremde Adresse zu schicken. Willison stellt fest, dass sich diese Art von Angriff bis heute nicht vollständig verhindern lässt.

Ein Service-Agent erfüllt alle drei Bedingungen, denn er liest Mails von Fremden, kennt Kundendaten und antwortet nach außen. Das spricht nicht gegen ihn, aber es bestimmt, wie du ihn einrichtest. Er darf Kunden auf ihre eigene Anfrage antworten und Vorgänge anlegen. Interne Dokumente an beliebige Adressen verschicken darf er nicht, und das System verhindert es auch technisch. Damit erledigt der Agent den Großteil seiner Arbeit selbst. Eine Freigabe durch einen Menschen brauchen nur die wenigen Aktionen mit echtem Risiko, etwa eine Gutschrift über einem festgelegten Betrag oder eine verbindliche Zusage zu Liefertermin oder Preis. OpenAI nennt in seinem Leitfaden genau solche Fälle: Stornierungen, größere Erstattungen und Zahlungen.

Schritt 5: Tests mit echten Fällen

Ein Agent, der auf fünf selbst ausgedachte Testfragen gut antwortet, hat noch nichts bewiesen. Du kennst die Antworten auf deine Testfragen und formulierst sie unbewusst so, dass er sie gut versteht. Echte Kunden schreiben anders. Sie mischen drei Anliegen in einer Mail, vergessen die Auftragsnummer, antworten auf eine alte Nachricht oder schreiben auf Englisch.

Nimm deshalb echte Fälle aus den letzten Monaten. Für den Service-Agenten heißt das: Zieh ein paar Dutzend Anfragen aus dem Postfach, darunter die einfachen Standardfälle und bewusst die schwierigen, die bei euch für Diskussionen gesorgt haben. Leg vor dem Test für jeden Fall fest, was die richtige Reaktion wäre, also welche Kategorie, welche Antwort und welche Weitergabe. Sonst bewertest du die Ergebnisse nach Gefühl, und ein gut formulierter Text wirkt richtiger, als er ist. Nimm auch eine Mail in die Sammlung auf, die versucht, dem Agenten Anweisungen unterzuschieben, damit du siehst, ob deine Rechte aus Schritt 4 halten.

Diese Sammlung ist mehr wert als der erste Testlauf. Sprachmodelle antworten auf dieselbe Eingabe nicht jedes Mal gleich, und eine Änderung an den Anweisungen, die einen Fall repariert, kann einen anderen verschlechtern. Wenn du nach jeder Änderung alle Fälle erneut durchlaufen lässt, siehst du das, bevor es ein Kunde merkt. Anthropic schreibt, der Schlüssel zum Erfolg liege darin, die Leistung zu messen und auf dieser Grundlage nachzubessern, und empfiehlt für Agenten ausgiebige Tests in einer abgeschotteten Umgebung. Für dich bedeutet das, dass der Agent zuerst auf Kopien oder in einem Testpostfach arbeitet, bevor er echte Kunden anschreibt.

Schritt 6: Jemand, der den Agenten pflegt

Ein Agent arbeitet mit dem Stand, den er bei der Einrichtung bekommen hat. Euer Unternehmen ändert sich aber laufend. Preise steigen, ein Kollege wechselt die Abteilung, die Reklamationsrichtlinie bekommt eine neue Frist, und das CRM erhält ein neues Pflichtfeld. Jede dieser Änderungen macht einen Teil der Anweisungen oder Unterlagen falsch, ohne dass der Agent eine Fehlermeldung zeigt. Er antwortet weiter höflich und flüssig, nur eben mit veralteten Angaben.

Deshalb braucht jeder Agent eine Person, die für ihn zuständig ist. Das muss niemand aus der IT sein. Am besten passt jemand, der die Aufgabe selbst kennt, beim Service-Agenten also die Teamleitung im Service. Diese Person liest regelmäßig Stichproben aus den Protokollen und nimmt Hinweise von Kollegen auf, wenn der Agent danebenliegt. Bei jeder Änderung im Ablauf passt sie Anweisungen und Unterlagen an und lässt danach die Testfälle aus Schritt 5 erneut durchlaufen.

Das setzt voraus, dass der Agent nachvollziehbar arbeitet. OWASP empfiehlt, die Aktivitäten eines Agenten zu protokollieren und zu überwachen und die Zahl seiner Aktionen pro Zeitraum zu begrenzen, damit ein Fehler auffällt, bevor er großen Schaden anrichtet. Prüf vor der Wahl eines Werkzeugs, ob du sehen kannst, was der Agent wann getan hat. Ohne dieses Protokoll kann die zuständige Person nur raten, warum eine Antwort falsch war.

Auch der Anbieter verändert den Agenten. Modelle werden aktualisiert oder abgelöst, und ein neues Modell kann dieselben Anweisungen anders auslegen. Mit einer Testsammlung prüfst du nach einem Modellwechsel in kurzer Zeit, ob noch alles stimmt. Ohne sie merkst du es erst an Beschwerden.

Wo der Baukasten endet

Ein Baukasten trägt weit, solange deine Systeme eine fertige Anbindung haben und die Aufgabe in einen Agenten passt. An Grenzen stößt er in drei Lagen.

Die erste Grenze sind Systeme ohne fertige Anbindung. Wenn eure Warenwirtschaft oder ein Branchenprogramm keine Schnittstelle hat, die der Baukasten kennt, kommt der Agent nicht an die Daten. Gartner weist darauf hin, dass die Anbindung von Agenten an Altsysteme technisch aufwendig sein kann und oft teure Anpassungen braucht. Hier brauchst du jemanden, der eine Schnittstelle baut, oder du wählst eine Aufgabe, die ohne dieses System auskommt.

Die zweite Grenze ist zu viel Logik in einem Agenten. Wenn die Anweisungen immer länger werden und aus vielen Wenn-dann-Verzweigungen bestehen, folgt das Modell ihnen schlechter. OpenAI empfiehlt, zuerst einen einzelnen Agenten so weit wie möglich auszubauen und ihn erst aufzuteilen, wenn er komplizierte Anweisungen nicht mehr befolgt oder regelmäßig das falsche Werkzeug wählt. Laut dem Leitfaden kommt es dabei weniger auf die Zahl der Werkzeuge an als darauf, wie ähnlich sie sich sind. Manche Agenten bewältigen mehr als 15 klar getrennte Werkzeuge, andere scheitern schon an weniger als 10, die sich überschneiden. Mehrere Agenten, die sich Aufgaben übergeben, lassen sich in vielen Plattformen ebenfalls ohne Code einrichten, aber Tests und Pflege werden dadurch aufwendiger.

Die dritte Grenze sind Anforderungen, die über die Einstellungen des Baukastens hinausgehen. Dazu gehören feinere Rechte, als die Plattform anbietet, ein vorgeschriebener Verarbeitungsort für Daten oder eine Prüfung jeder Aktion nach euren eigenen Regeln. Ob ein Werkzeug das kann, klärst du vor dem Bau und nicht, nachdem der Agent schon mit Kunden spricht.

Woran du nach drei Monaten erkennst, ob es funktioniert

Ein Agent, der wirklich läuft, fällt im Alltag kaum auf. Das Service-Team öffnet das Postfach und findet die Standardanfragen beantwortet und die Reklamationen als Vorgänge mit Anhang vor. Kollegen melden Fehler an die zuständige Person, weil klar ist, wer das ist. Die Testsammlung ist gewachsen, weil jeder neue Fehler als weiterer Fall hineinkommt. Und wenn sich die Reklamationsfrist ändert, ist das eine Aufgabe von zwanzig Minuten und kein Projekt.

Ein Agent, der scheitert, scheitert meistens leise. Die Kollegen prüfen jede seiner Antworten nach, weil sie ihm nicht trauen, und arbeiten irgendwann wieder am Agenten vorbei. Am Klicken liegt das selten. Meistens fehlte der Firmenkontext, die Rechte waren zu breit für ein ruhiges Gefühl oder es gab keine Tests und niemanden, der sich zuständig fühlte. Diese Punkte kannst du vor dem ersten Klick klären. Ein guter nächster Schritt ist deshalb, die eine Aufgabe auszuwählen, ein paar Dutzend echte Fälle dazu zu sammeln und die Person zu benennen, die den Agenten pflegen wird. Danach dauert der Bau wieder nur Minuten.