Sie brauchen keinen KI-Spezialisten fuer einen KI-Agenten. Sie brauchen ein KI-orchestriertes Entwicklungsteam

Aktuell klingt es, als seien KI-Agenten und Retrieval-Augmented Generation (RAG) eine neue Disziplin, die nur wenigen KI-Spezialisten vorbehalten ist. Das stimmt nicht. Ein aktuelles Projekt innerhalb von GoTeams‘ eigener Presales-Plattform, Partner Portal, zeigt das deutlich: Ein Entwicklungsteam wollte ein einziges, unspektakulaeres Problem loesen, und am Ende stand etwas, das technisch als KI-Agent gilt, ohne dass das je das Ziel war.

1. Der Engpass war nie die KI. Es war das Lesen, in grossem Umfang, von Menschen.

Partner Portal bildet den gesamten Presales-Prozess von GoTeams ab. Neue Kundenorganisationen werden onboardet, ihre Ansprechpartner laden Anforderungsdokumente und Meeting-Notizen hoch, und Admins lesen jedes einzelne davon manuell, um Angebote zu kalkulieren. Das ist der eigentliche Engpass: Lesen, in grossem Umfang, von Menschen, jedes Mal aufs Neue.

Der Ansatz, den das Team entwickelte, hiess nicht „eine RAG-Pipeline aufsetzen“. Er war kleiner: Ein Admin sollte eine Frage eintippen koennen, statt sich durch fuenf Dokumente zu arbeiten, um eine Antwort zu finden. Das war der gesamte Anspruch, und es ist eine nuetzliche Erinnerung fuer jedes Team, das ein KI-orchestriertes Entwicklungsteam gegenueber einem generischen „KI-Projekt“ abwaegt: Der Auftrag sollte beim Engpass beginnen, nicht beim Architekturdiagramm.

2. Semantische Suche ist keine Magie. Sie ordnet Bedeutung zu, nicht Wortlaut.

RAG gilt als komplexe Technologie. Auf den Kern reduziert, macht es eine Sache: Es ordnet zu, was ein Nutzer meint, nicht die exakten Woerter, die er eingegeben hat, und uebergibt einem Sprachmodell dann die passenden Textabschnitte zur Beantwortung. Wer klassisch nach „Social Login“ sucht, findet nichts, wenn ein Dokument nur „Anmeldung mit Google“ schreibt, weil die Woerter nicht uebereinstimmen. RAG findet die Stelle trotzdem, weil es Bedeutung sucht, nicht Rechtschreibung. Alles andere in einem RAG-System ist reine Infrastruktur.

Fuer den Partner-Portal-Build bestand diese Infrastruktur aus dem gewohnten Stack des Teams: Node.js und Postgres, ein paar Bibliotheken zum Extrahieren von Text aus Word-Dokumenten und Tabellen, ein lokales Embedding-Modell ueber Ollama, und LanceDB als kleine Vektordatenbank zum Speichern und Durchsuchen der Ergebnisse. Nichts davon erforderte ein neues Team. Das Team rechnete mit einem Wochenendprojekt.

Es wurde kein Wochenendprojekt.

3. Jede echte Frage brachte den ersten Entwurf auf eine neue Art zum Scheitern

Der erste echte Test fragte, welches Projekt eine Login-Anforderung enthaelt. Das System antwortete selbstbewusst und falsch, weil das Dokument mit der eigentlichen Login-Anforderung den Projektnamen nie erwaehnte. Dokumente stellen sich nicht selbst vor. Der Projektname stand nur in der Datenbank, also fand das Modell „Login“ korrekt, hatte aber nichts Brauchbares dazu zu sagen, wessen Login gemeint war.

Die Loesung war nicht raffiniert. Es war derselbe Handgriff, den jeder Backend-Entwickler schon hundertmal mit Fremdschluesseln gemacht hat: Jeden Textabschnitt bei der Aufnahme mit seiner Projekt-ID versehen, dann den echten Projektnamen nachschlagen, bevor die Antwort auf dem Bildschirm erscheint.

Die naechsten Fehler folgten demselben Muster. Eine Zusammenfassungsanfrage lieferte nur einen einzelnen Satz statt eines Ueberblicks, weil die Suche den einen naechstgelegenen Treffer griff, statt ein ganzes Projekt zu erfassen. Bei einem Vergleich zweier Projekte uebertoente der Inhalt eines Projekts den des anderen, weil das System keinen Begriff von „fair“ kannte. Keiner dieser Fehler war ein grundlegendes architektonisches Versagen. Jeder war eine Luecke, die noch nicht bedacht worden war, geschlossen mit der einfachsten Loesung, die tatsaechlich funktionierte.

Dann tauchte eine andere Art von Frage auf: Wie viele Dokumente hat dieses Projekt, oder welche Projekte haben ihren Fragebogen noch nicht ausgefuellt. Diese Fragen haben nichts mit einer Dokumentensuche zu tun. Es sind Fakten, die als Zeilen in Postgres liegen. Kein noch so gutes Embedding-Modell haette eine Frage beantworten koennen, deren echte Antwort eine Tabellenzeile war.

4. Die eine Entscheidung, die aus einem Suchwerkzeug einen Agenten macht

Hier liegt der Wendepunkt, und die einzige wirklich architektonische Entscheidung in diesem Projekt: Bevor ueberhaupt gesucht wird, wird klassifiziert, um welche Art von Frage es sich handelt und wo die Antwort tatsaechlich liegt. Das Team fuegte einen vorgeschalteten Schritt hinzu, der die Frage liest, entscheidet, wohin sie gehoert, und dann entweder die Datenbank abfragt, die Dokumente durchsucht oder beides tut: Datenbank fuer die Identitaet, Dokumente fuer den Inhalt.

Legt man das offen, ist es exakt die Grundform eines KI-Agenten: etwas, das die Absicht bestimmt, die richtige Quelle waehlt, danach handelt und seine Antwort mit echten Belegen statt mit Vermutungen untermauert. Das Team hatte einen gebaut. Niemand nannte es beim Bauen so, weil das Ziel nie „einen Agenten bauen“ war. Genau das ist auch die eigene KI-Haltung von GoTeams: KI beschleunigt Dokumentation, Tests und Boilerplate-Code, aber die Uebersetzung einer Geschaeftsfrage in die richtige Datenquelle ist technisches Urteilsvermoegen, keine unbeaufsichtigte Modellentscheidung.

5. Orchestrierung ist das Muster, nicht die Ausnahme

Das ist kein Einzelfall. GoTeams hat Zennify gebaut, eine Callcenter-Plattform, die zu einem skalierbaren Framework fuer KI-Assistenten ausgebaut wurde und heute LLM-Orchestrierung, Sprachdienste und die Twilio-Integration fuer Kunden wie PMI, Nestle, FlixBus und Illy Cafe uebernimmt. Dasselbe Prinzip zeigt sich dort: Das Modell ist eine Komponente in einem System, das steuert, prueft und strukturiert, was bei ihm ankommt, keine Blackbox, die alles allein bewaeltigen soll. Ein 17-koepfiges GoTeams-Team hat es gebaut und betreibt es.

Das Muster haelt, weil der schwierige Teil beim Bau eines KI-Agenten selten der Modellaufruf selbst ist. Es ist die Technik drumherum: Intent-Klassifizierung, Datenrouting, Retrieval-Qualitaet und Fehlerbehandlung fuer die Faelle, in denen das Modell danebenliegt. Genau das leistet ein KI-orchestriertes Entwicklungsteam standardmaessig, bei jedem Projekt, unabhaengig davon, ob im Auftrag das Wort „KI“ vorkommt.

6. Warum das Ihr Entwicklungsteam nicht einschuechtern sollte

Nichts an einem RAG-System oder einem Agenten ist neu. Semantische Suche gibt es seit Jahrzehnten. Dokumente in Abschnitte zu zerlegen und zu entscheiden, welche Quelle welche Frage beantwortet, ist Softwareentwicklung. Die meisten Entwickler haben schon einmal eine Art Routing-Schicht oder Entscheidungsbaum geschrieben, ganz ohne KI-Bezug. Die einzige wirklich neue Komponente der letzten Jahre ist das Sprachmodell selbst, das an der Stelle sitzt, an der es die abgerufenen Informationen liest und die Antwort in normaler Sprache formuliert.

Das ist der gesamte neue Teil. Text in Abschnitte zerlegen, Embeddings aufbauen, entscheiden, wo gesucht wird, und Absichten klassifizieren, das stand bereits im Werkzeugkasten der Softwareentwicklung, bevor jemand die Begriffe „RAG“ oder „Agent“ dafuer verwendete. Das umzusetzen erfordert keine neue Spezialisierung. Es erfordert denselben Debugging-Instinkt, den ein starkes Entwicklungsteam bereits mitbringt, angewendet auf ein System, in dem ein Sprachmodell ein weiteres Werkzeug im Kasten ist, nicht der ganze Kasten. Das ist das Argument fuer ein KI-orchestriertes Entwicklungsteam gegenueber einem eigenstaendigen „KI-Team“: Die KI-Komponente ist ein kleiner Teil dessen, was tatsaechlich gebaut und betrieben werden muss.

Häufig gestellte Fragen

Was ist ein KI-orchestriertes Entwicklungsteam?

Ein KI-orchestriertes Entwicklungsteam ist ein Entwicklungsteam, das KI gezielt einsetzt, fuer Dokumentation, Tests und Boilerplate-Code, waehrend Architektur, Geschaeftslogik und Qualitaetsentscheidungen unter fachkundiger menschlicher Kontrolle bleiben. GoTeams arbeitet nach diesem Modell mit 4.000+ geprueften Fachkraeften und einer Teambindungsquote von 98%, sodass dieselben Entwickler, die eine KI-Funktion planen, auch im Betrieb dafuer verantwortlich bleiben.

Brauche ich eine RAG-Pipeline, um einen KI-Agenten zu bauen?

Nicht immer, und nicht zuerst. Eine RAG-Pipeline (Retrieval-Augmented Generation) ist sinnvoll, wenn eine KI-Funktion Fragen aus unstrukturierten Dokumenten beantworten muss. Wenn die eigentlichen Fragen faktische Abfragen gegen eine Datenbank sind, loest eine RAG-Pipeline das falsche Problem. Im Partner-Portal-Projekt wurde Retrieval-Augmented Generation erst hinzugefuegt, nachdem klar war, welche Fragen das tatsaechlich benoetigten.

Warum scheitern RAG-basierte KI-Funktionen im Betrieb, obwohl die Demo funktioniert?

Meist, weil das System nicht erkennt, um welche Art von Frage es sich handelt. Eine Demo prueft die Faelle, die der Entwickler bedacht hat. Im Betrieb kommen Fragen, die Datenbankfakten, Dokumentensuche oder beides brauchen, und ein System ohne vorgeschaltete Intent-Klassifizierung sucht dann, wo es eigentlich eine Datenbank haette abfragen muessen, und liefert eine selbstbewusste, falsche Antwort statt der richtigen.

Was unterscheidet einen KI-Agenten von einem Chatbot mit Suchfunktion?

Ein Agent bestimmt, was eine Anfrage braucht, waehlt zwischen mehreren Quellen die passende aus, handelt danach und stuetzt die Antwort mit den gefundenen Belegen. Ein Chatbot mit Suchfunktion leistet nur den letzten Schritt. Die Intent-Klassifizierung und das Routing davor sind der Unterschied, und das ist klassische Softwareentwicklung, keine neue KI-Disziplin.

Was braucht es, um einen KI-Agenten ohne KI-Spezialisten zu bauen?

Es braucht ein Entwicklungsteam, das bereits weiss, wie man schwierige Probleme debuggt: Schemadesign, Routing-Logik und den Umgang mit Randfaellen. GoTeams arbeitet genau nach diesem Prinzip. Die KI-orchestrierten Entwicklungsteams von GoTeams sind innerhalb von 30 Tagen einsatzbereit, verglichen mit dem typischen internen Einstellungszyklus von 4 bis 9 Monaten im DACH-Raum, weil die benoetigten Faehigkeiten bereits vorhandene Entwicklungsfaehigkeiten sind, ergaenzt um ein Sprachmodell als weitere Komponente.

Das Fazit

Wenn ein Unternehmen nur einen einfachen Chatbot fuer eine FAQ-Seite braucht, reicht ein Standardtool. Aber ein KI-Agent, der echte Fragen gegen echte Geschaeftsdaten beantwortet, verlangt dieselbe technische Disziplin wie jedes andere Produktivsystem: Schemadesign, Routing-Logik und den Umgang mit Faellen, die am ersten Tag niemand vorhergesehen hat. Genau dafuer sind die KI-orchestrierten Entwicklungsteams von GoTeams gebaut, einsatzbereit in unter 30 Tagen, mit denselben Entwicklern, die das System geplant haben, auch nach dem Launch verantwortlich.