Bevor du einen KI-Agenten baust: die Entscheidungen, die später teuer werden

Warum du vor dem Bauen entscheiden musst - und nicht währenddessen

Wenn du heute «KI-Agenten bauen» googelst, findest du Hunderte von Tutorials, die dir in 20 Minuten zeigen, wie du einen Agenten mit LangChain, AutoGen oder CrewAI zum Laufen bringst. Das Problem ist nicht, dass diese Tutorials falsch sind. Das Problem ist, dass sie bei Schritt drei beginnen und Schritt eins und zwei überspringen - genau die Schritte, bei denen die entscheidenden Weichenstellungen passieren.

Ein KI-Agent ist kein Prototyp, den du nach zwei Wochen einfach wegwirfst. Er integriert sich in Prozesse, er bekommt Zugriff auf Systeme, und er entwickelt eine eigene Art, mit Ausnahmefällen umzugehen. Wenn du die falsche Architektur gewählt hast, wenn deine Datenstrategie nicht sitzt, wenn deine Metriken am Ziel vorbeimessen - dann merkst du das oft erst, wenn bereits echte Nutzer damit arbeiten. Und dann ist der Umbau teuer.

Das Stanford-Forschungsteam hat gemeinsam mit über 120.000 Entwicklern untersucht, wie KI-gestützte Produktivitätswerkzeuge tatsächlich wirken. Das Ergebnis ist nüchterner als die meisten Hochglanz-Berichte: Der Median liegt bei etwa 10 Prozent Produktivitätssteigerung - aber die Streuung ist enorm. Teams mit sauberer Codebasis und durchdachten KI-Praktiken erzielen überproportional hohe Gewinne, während Teams, die einfach mehr Token verbrauchen, teilweise sogar schlechtere Ergebnisse produzieren. Dieses Muster gilt nicht nur für Entwickler - es gilt für jeden, der einen KI-Agenten in seinen Betrieb einbettet.

Dieser Artikel geht nicht durch die Werkzeuge. Er geht durch die Entscheidungen - in der Reihenfolge, in der du sie treffen musst, bevor der erste Commit gemacht wird.

Aufgabe oder Agent? Die Entscheidung, die am häufigsten falsch getroffen wird

Bevor du einen KI-Agenten baust, musst du klären, ob du überhaupt einen brauchst. Das klingt trivial, ist es aber nicht. Der Begriff «Agent» wird heute für alles verwendet, was irgendwie mit einem Sprachmodell zusammenhängt - vom einfachen Textgenerator bis zum vollautonomen Mehrstufensystem.

Ein echter Agent trifft Entscheidungen über mehrere Schritte hinweg, nutzt Werkzeuge, verarbeitet Rückmeldungen und passt sein Verhalten an. Das macht ihn mächtig - aber auch komplex, fehleranfällig und schwer zu debuggen. Wenn deine Aufgabe eigentlich eine einfache Eingabe-Ausgabe-Transformation ist, dann brauchst du keinen Agenten. Du brauchst eine gut dokumentierte Prompt-Pipeline.

Wann ein Agent sinnvoll ist - und wann nicht

Die Entscheidung für einen Agenten ist also eine Investitionsentscheidung. Du kaufst dir Flexibilität und Autonomie - und zahlst dafür mit Komplexität, Wartungsaufwand und einem erhöhten Bedarf an Monitoring. Wenn die Aufgabe das nicht rechtfertigt, fang mit einer Pipeline an und skaliere zum Agenten, wenn der Bedarf tatsächlich entsteht.

Die Datenbasis, die alles trägt - oder alles zum Einsturz bringt

Wenn du einen KI-Agenten baust, der mit deinen Unternehmensdaten arbeitet - ob als RAG-System, als Datenanalyst oder als Prozessoptimierer - dann ist die Qualität dieser Daten die härteste Grenze, die dein Agent jemals überwinden wird. Kein Modell, kein Framework und kein cleveres Prompting kann strukturell schlechte oder inkonsistente Daten kompensieren.

Die Stanford-Studie mit 120.000 Entwicklern macht diesen Punkt sehr deutlich: Überproportionale Produktivitätssteigerungen entstehen dort, wo die zugrundeliegende Codebasis sauber ist - wo Konventionen eingehalten werden, Dokumentation vorhanden ist und die Struktur konsistent bleibt. Übertragen auf Agenten bedeutet das: Deine Datenstrategie muss vor der Agentenstrategie stehen.

Was «gute Datenbasis» konkret bedeutet

Gute Daten für einen KI-Agenten sind nicht einfach «viele Daten». Es geht um vier Dimensionen:

Architektur-Entscheidungen mit langer Halbwertszeit

Es gibt Entscheidungen, die du nach dem Livegang mit einem Konfigurationswechsel anpassen kannst. Und es gibt Entscheidungen, bei denen eine Änderung bedeutet, dass du den Agenten zu großen Teilen neu baust. Letztere musst du vor dem ersten Commit treffen.

1. Speichermodell: Was erinnert sich dein Agent?

Agenten können auf verschiedene Arten «Gedächtnis» haben: kurzfristiges Kontext-Gedächtnis innerhalb einer Sitzung, langfristiges Nutzergedächtnis über Sitzungen hinweg, und externes Wissensgedächtnis über Datenbanken und Vektorspeicher. Die Wahl des Speichermodells beeinflusst, wie dein Agent Kontext aufbaut, wie er personalisiert und wie er mit widersprüchlichen Informationen umgeht. Sie beeinflusst außerdem die Kosten - mehr Kontext bedeutet mehr Token, mehr Token bedeutet höhere Betriebskosten.

2. Werkzeugstrategie: Was darf der Agent tun?

Die Werkzeuge, die du einem Agenten gibst, definieren seinen Handlungsraum. Mehr Werkzeuge bedeuten mehr Fähigkeiten - aber auch mehr Möglichkeiten für Fehler, mehr Angriffsfläche und eine komplexere Entscheidungslogik. Die Frage ist nicht «Was könnte der Agent brauchen?», sondern «Was braucht er nachweislich für diese Aufgabe?»

Plane außerdem von Anfang an, welche Aktionen eine menschliche Bestätigung erfordern. Ein Agent, der E-Mails versenden, Bestellungen auslösen oder Datenbankeinträge löschen kann, muss klare Eskalationsregeln haben. Diese Regeln nachträglich einzubauen ist möglich - aber meistens bedeutet es, dass du die Zustandsmaschine des Agenten umschreiben musst.

3. Modellbindung: Wie abhängig machst du dich?

Wenn dein Agent tief an ein spezifisches Modell oder einen spezifischen Anbieter gebunden ist - durch spezifische Prompt-Formate, durch proprietäre Funktionen oder durch direkte API-Abhängigkeiten ohne Abstraktionsschicht - dann bezahlst du dafür spätestens beim nächsten Pricing-Update oder bei der nächsten Modelldeprecation. Eine Abstraktionsschicht zwischen deinem Agenten und dem Modell ist kein Nice-to-have, sondern ein architektonisches Muss.

Messung und ROI: Was du misst, das steuerst du

Die Stanford-Studie zeigt einen gefährlichen Messfall sehr deutlich: Ein Team von 350 Personen wertete steigende PR-Zahlen (Pull Requests) als Zeichen für Produktivitätssteigerung - ohne dabei zu messen, ob die Qualität dieser PRs stieg oder sank. Das Ergebnis war eine trügerische Erfolgsmeldung bei gleichzeitig sinkender Code-Qualität. Dieser «Measurement Trap» genannte Effekt ist kein Entwickler-spezifisches Problem. Er taucht überall auf, wo KI-Systeme eingesetzt werden.

Für KI-Agenten bedeutet das: Du musst vor dem Livegang entscheiden, was Erfolg konkret bedeutet. Nicht in abstrakten Begriffen wie «Effizienzsteigerung» oder «bessere Nutzererfahrung», sondern in messbaren, qualifizierten Indikatoren.

Zwei Ebenen der Messung

Unterscheide zwischen Prozessmetriken und Ergebnismetriken. Prozessmetriken messen, was der Agent tut - Anfragen pro Stunde, Werkzeugaufrufe, durchschnittliche Antwortzeit. Ergebnismetriken messen, was für das Unternehmen passiert - Bearbeitungszeit pro Fall, Fehlerrate bei Ausgaben, Nutzerzufriedenheit, tatsächlich eingesparte Arbeitszeit.

Prozessmetriken sind einfacher zu erfassen und verführen deshalb dazu, als Erfolgsmaß verwendet zu werden. Ergebnismetriken sind schwerer zu erheben, aber sie sind die einzigen, die dir sagen, ob dein Agent tatsächlich einen Unterschied macht. Plane beide ein - und gib den Ergebnismetriken die höhere Priorität in deinem Reporting.

Die teuersten Fehlerquellen - und wie du sie vermeidest

Nach dem, was wir in der Praxis mit KI-Agenten für Unternehmen sehen, gibt es eine handvoll Fehler, die systematisch immer wieder gemacht werden - und die immer dann besonders teuer werden, wenn sie erst nach dem Launch auffallen.

Fehler 1: Kein Fallback für Grenzfälle

Was passiert, wenn der Agent eine Anfrage nicht verarbeiten kann? Wenn das Modell Unsinn zurückgibt, wenn ein Werkzeug antwortet nicht, wenn der Nutzer etwas fragt, das außerhalb des Kompetenzbereichs liegt? Wer diese Szenarien vor dem Bau nicht durchdenkt, hat nach dem Livegang einen Agenten, der bei Grenzfällen still scheitert - oder schlimmer noch, selbstsicher falsche Antworten produziert.

Fehler 2: Kein Observability-Konzept

Du kannst einen Agenten nicht betreiben, ohne zu wissen, was er intern tut. Welche Werkzeuge ruft er in welcher Reihenfolge auf? Warum hat er eine bestimmte Entscheidung getroffen? Wo entstehen Kosten? Ohne Logging und Tracing auf der Agentenebene - nicht nur auf der HTTP-Ebene - bist du blind. Dieses Observability-Konzept muss von Tag eins an mitgeplant werden, weil es die Architektur beeinflusst.

Fehler 3: Unterschätzte Promptpflege

System-Prompts und Werkzeug-Beschreibungen sind kein einmaliger Aufwand. Sie sind lebende Dokumente, die sich mit dem Modell, mit den Anforderungen und mit dem Nutzerverhalten weiterentwickeln. Teams, die das nicht einplanen, stellen nach drei Monaten fest, dass ihr Agent merkwürdig reagiert - weil das Modell ein Update bekam, aber der Prompt nicht.

Fehler 4: Fehlende Sicherheitsgrenzen

Ein Agent, der Systeme aufrufen kann, ist ein potenzieller Angriffsvektor. Prompt-Injection-Angriffe, bei denen externe Inhalte den Agenten zu unerwünschten Aktionen verleiten, sind keine Theorie - sie sind dokumentierte, reale Bedrohungen. Eingabevalidierung, Output-Filtering und ein klares Berechtigungsmodell sind Pflicht, nicht Option.

Entscheidungs-Matrix für die Praxis

Bevor du einen KI-Agenten baust, solltest du diese Entscheidungen in genau dieser Reihenfolge getroffen haben. Jede baut auf der vorherigen auf, und eine übersprungene Entscheidung wird dich später einholen.

Die vollständige Entscheidungs-Checkliste mit konkreten Fragen zu jeder dieser acht Phasen kannst du weiter unten herunterladen. Sie ist so aufgebaut, dass du sie in einem Workshop-Format mit deinem Team durcharbeiten kannst - bevor auch nur das erste Framework installiert wird.

Integration in den laufenden Betrieb: was die Theorie verschweigt

Ein KI-Agent, der in der Sandbox funktioniert, ist noch kein operativer KI-Agent. Die Lücke zwischen «läuft im Test» und «läuft zuverlässig in Produktion» ist eine der am häufigsten unterschätzten Herausforderungen beim Bau von Agentensystemen.

Menschliche Übergaben planen

Kein Agent erledigt 100 Prozent aller Fälle fehlerfrei. Die Frage ist nicht, ob dein Agent Fälle an Menschen übergeben wird, sondern wie und wann. Diese Übergabe muss so gestaltet sein, dass der Mensch den Kontext schnell verstehen und sauber weiterarbeiten kann. Das bedeutet: Der Agent muss seinen Bearbeitungsstand dokumentieren, und das Interface muss diese Dokumentation zugänglich machen.

Change Management ist kein Bonus

Technisch erfolgreiche Agentenimplementierungen scheitern regelmäßig an der menschlichen Seite: Mitarbeitende, die dem System nicht vertrauen, es umgehen oder es für Aufgaben einsetzen, für die es nicht gebaut wurde. Die Einführung eines Agenten ist kein IT-Rollout - es ist eine Prozessveränderung. Kommunikation, Training und klare Verantwortlichkeiten müssen mitgeplant werden.

Kostenmodell von Anfang an durchrechnen

KI-Agenten haben variable Betriebskosten, die mit der Nutzung skalieren. Token-Kosten, API-Aufrufkosten, Vektordatenbank-Kosten, Rechenkosten für Embedding-Generierung - all das summiert sich. Wer das Kostenmodell nicht vor dem Launch durchrechnet, erlebt manchmal unangenehme Überraschungen bei der ersten Monatsabrechnung. Definiere Kostengrenzen und plane Alerting ein.

Checkliste vor dem Start: die neun Fragen, die du beantworten können musst

Wenn du diese neun Fragen klar und konkret beantworten kannst, bist du bereit, mit dem Bau zu beginnen. Wenn nicht, weißt du jetzt, wo du noch Hausaufgaben hast.

Die vollständige Entscheidungs-Checkliste - mit Unterfragen, Bewertungskriterien und einem Priorisierungsrahmen für jede dieser neun Kategorien - findest du im Download unten.

Fragen aus der Praxis